Subject: 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: [email protected]
For additional commands, e-mail: [email protected]
[email protected]-------


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: [email protected]
For additional commands, e-mail: [email protected]





Programming list archiving by: Enterprise Git Hosting