|
osdir.com mailing list archive |
|
Subject: Re: Generate (REALLY) Dynamic Form - msg#00050List: java.facelets.userHi 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 Thread at a glance:
Previous Message by Date: click to view message previewRe: Facelets in portletGot it working by downloading the distribution from java.net instead of using the Netbeans plugin and copying the FaceletPortletViewHandler classOn Thu, Jun 26, 2008 at 1:31 PM, Jose Noheda <jose.noheda@xxxxxxxxx> wrote: Hi,I'm trying to deploy a JSF+Facelets+Portlet to OpenPortal Portlet Container (Glassfish v2) using the OpenPortal JSF portlet bridge. Unfortunately I'm getting: Error Rendering View[/welcome.xhtml] java.lang.ClassCastException: com.sun.portal.portletcontainer.portlet.impl.RenderResponseImpl cannot be cast to javax.servlet.ServletResponse at com.sun.facelets.FaceletViewHandler.createResponseWriter(FaceletViewHandler.java:370) at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:571)The configuration is pretty basic (it's our first test):<faces-config version="1.2" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd"> <application> <view-handler>com.sun.facelets.FaceletViewHandler</view-handler> </application></faces-config><portlet> <description>JSF Porlet Facelets Hello World</description> <portlet-name>faceletsPortletHello</portlet-name> <display-name>JSF Porlet Facelets Hello World</display-name> <portlet-class>com.sun.faces.portlet.FacesPortlet</portlet-class> <init-param> <description>Portlet init view page</description> <name>com.sun.faces.portlet.INIT_VIEW</name> <value>/welcome.jsf</value> </init-param> <supports> <mime-type>text/html</mime-type> <portlet-mode>VIEW</portlet-mode> </supports> <portlet-info> <title>JSF Facelets Portlet</title> <short-title>FaceletsPortletHello</short-title> </portlet-info></portlet>And here's the page:<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html" xmlns:p="http://java.sun.com/jsf/portlet/components"> <body> <ui:define name="title"> <p:portletPage> <h:outputText value="JavaServer Faces" /> </p:portletPage> </ui:define> </body></html>Can anyone help with this?Regards Next Message by Date: click to view message previewRE: Generate (REALLY) Dynamic FormHi.. Perhaps you can use the same techniques in http://jira.springframework.org/browse/SWF-660 In this case there are 2 jsf lifecycles that are run.. One for the page you are on and another for the included page section boundaried by a specialized component... This way the components included by the specialized component can change as the page is re-rendered. There are some shortcomings with this as it stands since the view right now is tied to the tagId of the component and the facelet page being included... i.e: UIViewRoot restoredViewRoot = (UIViewRoot) requestContext.getExternalContext().getSessionMap().get(TMPSTORE_VIEW_RO OT+viewToRender.getViewId()+originalParentComponent.getTagId()); In your case you'd have to have some sort of sequencing scenario which would allow JSF to know when you want to consider the new set of components a new view... DISCLAIMER... Solution although it works is not production ready.. I'm waiting for the JSF experts to chime in here and really review how stuff like this should be done... -----Original Message----- From: Ken.Paulsen@xxxxxxx [mailto:Ken.Paulsen@xxxxxxx] Sent: Thursday, June 26, 2008 12:28 PM To: users@xxxxxxxxxxxxxxxxxxxxx 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: 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxxxxxxx This message is a PRIVATE communication. If you are not the intended recipient, please do not read, copy or use it and do not disclose it to others. Please notify the sender of the delivery error by replying to this message and then delete from your system. Thank you. Previous Message by Thread: click to view message previewRe: Generate (REALLY) Dynamic FormIt 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 Next Message by Thread: click to view message previewRE: Generate (REALLY) Dynamic FormHi.. Perhaps you can use the same techniques in http://jira.springframework.org/browse/SWF-660 In this case there are 2 jsf lifecycles that are run.. One for the page you are on and another for the included page section boundaried by a specialized component... This way the components included by the specialized component can change as the page is re-rendered. There are some shortcomings with this as it stands since the view right now is tied to the tagId of the component and the facelet page being included... i.e: UIViewRoot restoredViewRoot = (UIViewRoot) requestContext.getExternalContext().getSessionMap().get(TMPSTORE_VIEW_RO OT+viewToRender.getViewId()+originalParentComponent.getTagId()); In your case you'd have to have some sort of sequencing scenario which would allow JSF to know when you want to consider the new set of components a new view... DISCLAIMER... Solution although it works is not production ready.. I'm waiting for the JSF experts to chime in here and really review how stuff like this should be done... -----Original Message----- From: Ken.Paulsen@xxxxxxx [mailto:Ken.Paulsen@xxxxxxx] Sent: Thursday, June 26, 2008 12:28 PM To: users@xxxxxxxxxxxxxxxxxxxxx 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: 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxxxxxxx This message is a PRIVATE communication. If you are not the intended recipient, please do not read, copy or use it and do not disclose it to others. Please notify the sender of the delivery error by replying to this message and then delete from your system. Thank you. Loading Comments...
|
|
