On 12/3/06, Simon Kitching <[EMAIL PROTECTED]> wrote:
Craig McClanahan wrote: > > > On 12/3/06, *Simon Kitching* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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 the set of components you might want to expose is deterministic (i.e. the choice is "show this set or not" versus "construct a set that corresponds to my data") this can work, although you have to be sensitive to how many components you have in the tree that are not being displayed, but still having to be processed through all the lifecycle phases. The only problems I've ever had with dynamic component trees relate to using JSF 1.1 and JSP together, because in that environment the component tree gets built dynamically (the first time only), and you can't make forward references. If you use Clay or Facelets with JSF 1.1, or use any view handler with JSF 1.2, you don't have to worry about that.
> > 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?
That's where I would use Shale :-). The prerender() method is the perfect place to put that kind of logic. Indeed, that's what the SQL browser does -- it performs the query and rebuilds the children of the table component in the prerender() method. Shale guarantees to call this on the first call or on a callback, so you don't have to do anything special. Without Shale, it is not uncommon to see this kind of thing done in the constructor of a managed bean, although this can cause you some grief because the bean itself hasn't been registered in request scope yet (while the constructor is running). Using binding setter methods can be problematic because you can't control the timing versus the creation of other components, and you can't necessarily be assured it will be called only once. Craig Regards,
Simon
