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

[Ed Burns]

>>>>> On Wed, 11 Mar 2009 17:09:25 -0400, Gavin King <gavin at HIBERNATEORG> 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 HIBERNATEORG> said:

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