Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <45736565.6010001@rhe.co.nz>
Date: Mon, 04 Dec 2006 13:01:41 +1300
From: Simon Kitching <simon.kitching@rhe.co.nz>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: MyFaces Discussion <users@myfaces.apache.org>
Subject: Re: Newbie question: How to generate a jsf component dynamically
References: <7655989.post@talk.nabble.com> <45733197.5000309@rhe.co.nz>
 <f8b39ace0612031540g6527688w79e497538f757551@mail.gmail.com>
In-Reply-To: <f8b39ace0612031540g6527688w79e497538f757551@mail.gmail.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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