[jsr-314-open] So what's left for 2.0?

[Pete Muir]

On 12 Mar 2009, at 17:20, Ed Burns wrote:

>>>>>> On Wed, 11 Mar 2009 17:09:25 -0400, Gavin King <gavin at HIBERNATE.ORG
>>>>>> > said:
>
> 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.
>
>>>>>> On Wed, 11 Mar 2009 17:06:52 -0400, Gavin King <gavin at HIBERNATE.ORG
>>>>>> > said:
>
> GK> What is the real status on state saving. IMO, the ability to write
> GK> "stateless" components is a critical feature for JSF2.

What we have is the ability to write stateless components, what we
don't have is the enhanced delta-state-saving, based on work in
Trindidad which is more performant.

>
>
> 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
> P.S.
>
> 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 at sun.com  | office: 408 884 9519 OR x31640
> | homepage:         | http://ridingthecrest.com/

--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete