AS> Can anyone clarify what the plan is for 2.0? EB> We had a plan, but it never was fully prototyped and the prototype EB> we did have was terribly de-stabilized by the lifecycle changes we EB> made to accomodate Andy's your concerns regarding the performance of EB> metadata gathering.  Therefore, I'm sorry to say it but we'll have EB> to push out State Saving enhancements to 2.1. GK> I don't understand this response. Technically, the prototype was based on the lifecycle design prior to the integration of the View Parameters feature. The changes to the lifecycle to integrate View Parameters into the spec have invalidated important assumptions made by the state saving prototype. Therefore, the prototype has to be reworked in light of the current lifecycle design. GK> Does this mean you are saying that a stateless lifecycle will be GK> impossible in JSF2? Impossible: certainly not. Easy: that's debatable. The easiest way for a user to achieve stateless JSF in 2.0 is to use only your <h:link> and <h:button> components for navigation and to mark every <f:view> as "transient". In this way, there will never be a POST to the server and there will never be any state saved or restored. I don't think such restrictions are to onerous. GK> What is the real status on state saving. IMO, the ability to write GK> "stateless" components is a critical feature for JSF2. It is certainly possible to write stateless components but not easy. See the P.S. for one way to do it. Here are my arguments for shipping 2.0 without this feature. 1. We've been working on this long enough, we have plenty of value in our other features, let's ship it. a. Economic arguments relating to Sun's cost for funding R&D budget also fit into this argument. b. We've been talking about this for the past *three* JavaOnes. I've been embarrased about not having it done for the past *two*. It's time to have it done. 2. It is possible, but not easy to do stateless components, see the PS. That's pretty much it. Ed P.S. An extension could be made that makes stateless components easy. Here's one way to do it, assuming it's acceptable to say to the user: "You want stateless? Don't use any UICommand components in your application." The basic idea is to leverage your view parameter feature to take responsibility for the ValueHolder nature of a UIComponent and let the UIComponent subclass only handle the "renderable" nature of a UIComponent. Consider these classes: public class ComponentBaseStateless extends UIComponentBase. public class ComponentBaseViewParameterHelper extends UIViewParameter. * make a Facelet tag for ComponentBaseViewParameter helper (no code required), let's call it <ex:statelessHelper>. * ComponentBaseStateless ensures its "transient" property is always true and can never be set to false. * make ComponentBaseStateless emit a javascript function that, when called, returns the name=value pair of the component. * make the the ComponentBaseStateless.encodeAll() find its corresponding ComponentBaseViewParameter instance and pull the value to render from there. * require the page author using the component to place an <ex:statelessHelper> in the <f:metadata> section with the same id as the component. Any validators, converters, etc that you would normally attach to the component directly, are attached within this <ex:statelessHelper>. * require the page author to use only <h:link> and <h:button> components and furthermore, require them to call the special javascript method to ensure that any name=value pairs in the page are included in the query string. -- | ed.burns(a)sun.com | office: 408 884 9519 OR x31640 | homepage: | http://ridingthecrest.com/