Craig McClanahan wrote:
>
>
> On 12/3/06, *Simon Kitching* <simon.kitching@rhe.co.nz
> <mailto:simon.kitching@rhe.co.nz>> wrote:
>
> Hi Koshi,
>
> Generally, having the component tree vary dynamically is not done with
> JSF. If you want a choice of two different components, then typically
> you define both of them in the page, then use the "rendered"
> property to
> ensure that only the one you want is output.
>
> There is certainly no JSF tag in standard JSF or Tomahawk that allows a
> random component to be inserted into the tree. I don't initially see why
> it wouldn't be possible to do this, but it certainly isn't common JSF
> practice AFAIK.
>
>
> I don't know about your definition of "common", but the fact that you
> *can* construct component trees dynamically is one of the most powerful
> features of JSF. Consider, for example, the "shale-sql-browser" example
> app[1] in Shale, which performs SQL queries, then looks at the JDBC
> metadata that is returned, and builds dynamically the column components
> inside a table component. It's really easy to do (and this is all
> standard JSF stuff, not dependent on Shale).
Thanks for the correction Craig; I should have been more careful in my
use of "common". And I should not have said dynamic components are
"generally..not done with JSF"; it's just that in the current project
I'm working on, people have several times struck problems with issues
related to component-bindings and their initial attempt to work around
it has often included attempts to dynamically modify the component tree
when simpler alternatives were available.
For simple cases, however, don't you think that using the "rendered"
property to select one of a small set of components to render would be
appropriate, rather than dynamic component creation? JSF supports
"templating" of presentation (jsp, facelets, clay, etc) in order to push
most of the layout issues out of java code...
>
>
> If you *did* want to create such a component, I can imagine one that has
> a single child; on encodeBegin it evaluates its value expression, sets
> that component as its child then passes on the encodeBegin call. All
> other component methods would get delegated down to the child as normal.
>
>
> It's easier to compose the component tree in an action event handler ...
> saves all the extra effort needed to define and register a component.
>
Yes, following a postback a managed bean action method can access a
component on the page (using binding or lookup) then explicitly add
children to it to create dynamically-generated page sections.
How would you recommend an app do this on first render of a page (eg
"when user setting is X, add this component else add that component")?
Perhaps in a binding setter method?
Regards,
Simon
|