This is just a guess but you might try using the tomahawk form component too. There might be some component coupling that is assumed in the library.
>
>
> -----Original Message-----
> From: Richard Eggert [mailto:
reggert@...]
> Sent: Friday, April 11, 2008 7:33 AM
> To:
user@...
> Subject: RE: [Shale Clay]
>
> Yes. Basically, you would have to define a component that inherits from
> h:dataTable, and give it child elements that inherit from h:column.
> Each of those child elements would then contain children that make up
> the content of your columns.
>
> Rich Eggert
> Member of Technical Staff
> Proteus Technologies, LLC
>
http://www.proteus-technologies.com>
>
>
> -----Original Message-----
> From: Zheng, Xiahong [mailto:
Xiahong.Zheng@...]
> Sent: Fri 4/11/2008 12:08 AM
> To:
user@...
> Subject: RE: [Shale Clay]
>
> Thanks a lot Rich. I was able to use your first example without having
> any white space issue even if I reformatted it a bit. If I want to use
> the second solution, how would I define the behavior of the dataTable?
> Would it still need to inherit dataTable for the looping capability
> since the number of rows are dynamic?
>
> -----Original Message-----
> From: Richard Eggert [mailto:
reggert@...]
> Sent: Thursday, April 10, 2008 5:12 PM
> To:
user@...
> Subject: RE: [Shale Clay]
>
> My experience with dataTables and clay has been that they don't get
> along very well, at least in the case of HTML templates (XML templates
> are another story). This is mainly because h:dataTable has a
> drastically different structure from HTML tables. h:dataTable expects
> to have h:columns as its immediate child (with optional tags for header
> and footer rows nested within each column), whereas HTML TABLE tags
> expect to have TR (row) tags as its children (or TR tags nested within a
> TBODY), with the column (TD) tags nested within each row. Essentially,
> from the point of view of an h:dataTable, a column contains rows, but in
> an HTML TABLE, a row contains columns, which makes mapping between the
> two extremely difficult. It can be done, but it involves making a lot
> of dummy jsfid="void" tags and using SPAN tags to cause elements that
> wouldn't be visible in the mockup to be rendered at runtime.
>
> e.g.,
>
> <table jsfid="h:dataTable" var="foo" value="#{bar.list}"
> ><tr jsfid="void" allowBody="false">
> <th>Mock Heading</th>
> </tr><tr jsfid="void"
> ><td jsfid="h:column">
> #{foo.name}
> <span jsfid="h:outputText" value="Real Heading"
> facetName="header"></span>
> </td>
> </tr>
> </table>
>
> Note that the lack of whitespace around the TR elements is intentional
> to avoid (blank) text elements winding up as children of the h:dataTable
> component (which is very nasty and breaks everything!).
>
> As you can see, writing an HTML template for a dataTable gets extremely
> ugly very quickly. For this reason, I don't recommend doing it unless
> you REALLY want to be able to view the mockup in a browser before
> deploying it. You're better off defining the template in XML and just
> referring to it in the parent template, e.g.,
>
> <table jsfid="my:customtable" allowBody="false">
> Table goes here.
> </table>
>
>
> What we really need is a new JSF component that provides the same
> capabilities as dataTable but is structured more like HTML TABLE tags.
>
>
>
> Rich Eggert
> Member of Technical Staff
> Proteus Technologies, LLC
>
http://www.proteus-technologies.com>
>
>
> -----Original Message-----
> From: Zheng, Xiahong [mailto:
Xiahong.Zheng@...]
> Sent: Thu 4/10/2008 2:22 PM
> To:
user@...
> Subject: FW: [Shale Clay]
>
> I couldn't seem to understand by looking at the clay usecase example.
> Can somebody post a simple example of using clay to generate a dynamic
> data table, the equivalent of the JSF h:dataTable tag?
>
>
>
>
>
>