Re: Generate (REALLY) Dynamic Form

Hi Jacob,

It's great to hear from you, I hope everything is going well!

I agree in order to provide best practices, these hooks are needed.  
Without them in JSF 1.2, people are inventing their own ways to do this 
(shale has its events, JSFTemplating has its own, people use 
constructors, bindings, action methods, and as suggested in this thread: 
people create their own renderer which dynamically adds children each 
request :( ).  I also agree on striving for state-saving optimization, 
which may lead to the trade-off of disallowing tree manipulation after a 
certain phase -- this hasn't been resolved in the 2.0 EG yet. 

I'm not sure about the template being authoritative after initial tree 
creation, though.  For state-saving it simplifies some use cases, but it 
restricts dynamic pages.  Another view on "component X defined in a 
template" is that the template drives creation (acts as a component tree 
factory), and then is not used anymore.  This allows for maximum 
flexibility, but may make state saving more difficult to optimize.  This 
is something the 2.0 EG needs to work out and to set guidelines for 
2.0.  1.2 allows for complete flexibility... although you could argue 
that is because this area was underspecified, I suppose.  When we get to 
this topic (soon), it would be great if you had some time to provide EG 
input. ;)

Do you have any suggestions for some of the Ajax use cases which 
manipulate the page by adding/removing components?  Say I have a tree 
component consiting of TreeNodes which dynamically get added/removed, or 
a graphic editing widget than can add/remove/modify graphic widget 
children (add text, lines, ciricles, etc).  Or many other simpler use 
cases -- our admin console in GlassFish, for example, adds breadcrumb 
links dynamically based on the highlighted tree selection.  Do you 
suggest a special "ajax-aware" component is required which knows how to 
maintain its own dynamic state allowing it to "write its own rules" wrt 
to state saving to accommodate this more dynamic use case?  Or is there 
some better answer for JSF 2.0?

Thanks for you time!

Ken Paulsen


Jacob Hookom wrote:
> It depends on the phase-- one of the first issues discussed in the JSF 
> 2.0 spec was that you should not manipulate the component tree beyond 
> a certain point in the lifecycle-- like during or after rendering-- 
> and that JSF today doesn't provide or outline specific hooks for 
> allowing an end developer to provide programmatic manipulation.
>
> What if I register a validator during the Update phase or add some 
> input components then-- is the state of my tree guaranteed in 
> successive declarations?
>
> If I have component X defined in a template, it's under ownership of 
> that template for dictating child content and other behavior.  That's 
> your set of instructions for producing a component [tree].  What's 
> actually needed in the spec is post component tree creation or post 
> component creation hooks, providing the ability to then modify the 
> component [tree] returned from the instructions outlined in the template.
>
> Ken Paulsen wrote:
> > Hello everyone, I just joined this email list.  For those that don't 
> > know me, I'm Ken Paulsen and I started JSFTemplating, which also 
> > supports most of the Facelets syntax (although with a completely 
> > independent implementation).  Enough about me...
> >
> > I was pointed to this thread, which I have now caught up on.  If I 
> > understand what it being stated, I am very concerned.  Is it accurate 
> > that Java code that manipulates the UIComponent tree does not work?  
> > For example:
> >
> >    someComponent.getChildren().add(newComponent);
> >
> > Or does it partially work?  What are the limitations?  I am 
> > particularly interested in knowing this as the Facelets syntax (and 
> > perhaps large portions of the impl) will be part of JSF 2.0.  This 
> > type of limitation, if it exists, is unacceptable in a core JSF 
> > implementation (although perhaps reasonable for a custom ViewHandler).
> >
> > Thanks,
> >
> > Ken Paulsen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxxxxxxx
> > ------------------------------------------------------------------------
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.1/1519 - 
> > Release Date: 6/25/2008 4:13 PM
> >   
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxxxxxxx