Hi
MR>> While I understand more can be done with respect to stateless
MR>> and also the view pooling you mentioned my goal was to limit
MR>> the changes required to a minimum while still satisfying the
MR>> wishes of our community as expressed by the specification
MR>> issue.
I know there are people that wants something like this included in
JSF spec, in fact I have spent a lot of time thinking and experimenting
over this feature. But my concern is more about the justification of
the idea itself.
Is the inclusion of "transient" attribute on f:view significant from
performance perspective?
No. The impact over performance is marginal, compared with other
things that JSF does like render the view or build the view.
Is there any other reason why include "transient" attribute on f:view
could be a good idea?
Suggestions are welcome.
MR>> @ViewScoped
MR>> With respect to @ViewScoped I don't think it's appropriate to
MR>> make @ViewScoped work with this limited proposal since, by
MR>> definition, the developer is agreeing to a stateless view.
The point is it should be clear if @ViewScope works or not, but I
suppose it should be, because if the user dont want to use it, he/she
will just use other scope, right?. It is not difficult to imagine an user
trying to use @ViewScope over a stateless view.
MR>> Poolable views
MR>> While I like to be able to see this to become part of the
MR>> specification I think to tackle this now is too large of an
MR>> undertaking with too many unknowns.
The point of spent months on a working prototype was precisely to see
the feasibility of the idea and the required changes on the spec to
make it work. My intention at start was try to add it as a
specific feature for MyFaces Core, but at the end the only way to
introduce it is in the spec. In this moment we are not talking
about something that needs to be done, it is something that has a
working prototype and that it has a clear list of changes that can
be done inside the spec. I know time's up for JSF 2.2 spec, but anyway
given the discussion about add "transient" attribute to f:view tag,
I felt the need to share this work at EG level. Maybe someday this
can be included ... or maybe we can convince some third party library
to include and in that way put this on MyFaces ....
MR>> I hope you can sign off on the limited scope so we can get it
MR>> as it stands into the 2.2 release, and then we will address the
MR>> other changes in the next release.
My only objection about this is the problem with @ViewScope. If you guys
want to do, that's ok. Does it make any difference? I don't think so,
unless with the data I have gathered from MyFaces. Will I recommend it?
No, it is better keep things simple and let JSF deal with stateless/stateful
logic.
regards,
Leonardo Uribe
2013/2/26 Frank Caputo <frank_at_frankcaputo.de>:
> Hi Neil,
>
> Am 25.02.2013 um 22:10 schrieb Neil Griffin <neil.griffin_at_portletfaces.org>:
>
> +1 for JSF 2.2 because it using it in it's current form with JSF 2.1 creates
> warnings in IDEs, and I wouldn't want to see these warnings persist until we
> get JSF 2.3 out the door.
>
> Details: The feature relies on getTransient/setTransient from
> UIComponentBase [1] but there is no "transient" attribute defined in the
> Facelet taglib.xml file, and no such documented property in the VDLDocs for
> f:view [2] -- that's what causes IDEs to report warnings in XHTML files.
>
> By adding this for JSF 2.2, we can change the VDLDocs (technically part of
> the Spec right?) so that they reflect the transient attribute.
>
>
> We should have the transient attribute for all components, because it is
> already there under the hood. The same applies for rendered.
>
> Ciao Frank
>
>
> [1]
> http://javaserverfaces.java.net/nonav/docs/2.1/javadocs/javax/faces/component/UIComponentBase.html
> [2]
> http://javaserverfaces.java.net/nonav/docs/2.1/vdldocs/facelets/f/view.html
>
> On Feb 25, 2013, at 3:37 PM, Edward Burns <edward.burns_at_oracle.com> wrote:
>
> Hello Volunteers,
>
> You may have seen Manfred Riem's blog entry about stateless JSF. [1] I
> wonder what you think about adding this for 2.2? Here are the spec
> changes we would need for this minimal, yet effective approach.
>
> * Expose existing transient attribute on UIComponent on VDLDoc for
> <f:view>.
>
> The text of the attribute will be based on UIComponent.isTransient():
>
> If true, the component (and therefore the children of the component)
> must not participate in state saving or restoring.
>
> * In section 7.7.2.8 ViewDeclarationLanguage.restoreView(), change the
> text to be the following.
>
> The JSP implementation must:
>
> [include the existing text of the section.]
>
> The Facelet implementation must:
>
> Call ResponseStateManager.isStateless(). If true, take the
> following action (I will put this in English rather than code).
>
> ViewDeclarationLanguage vdl =
> vdlFactory.getViewDeclarationLanguage(viewId);
> viewRoot = vdl.createView(context, viewId);
> @@ -543,9 +547,9 @@
> ViewDeclarationLanguage vdl =
> vdlFactory.getViewDeclarationLanguage(viewId);
> viewRoot = vdl.getViewMetadata(context,
> viewId).createMetadataView(context);
> context.setViewRoot(viewRoot);
>
> and return, otherwise [...include existing text of the section].
>
> * In ResponseStateManager.writeState(), if the UIViewRoot is transient,
> take impl specific action to make it so the call to
> ResponseStateManager.isStateless() during the the next call, from
> ViewDeclarationLanguage.restoreView(), returns true.
>
> * Spec for new method ResponseStateManager.isStateless(). If the
> preceding writeState() was stateless, return true. If the preceding
> writeState() was statefull return false, otherwise throw
> IllegalStateException.
>
> Thanks,
>
> Ed
>
>
> [1]
> http://weblogs.java.net/blog/mriem/archive/2013/02/08/jsf-going-stateless
>
> --
>
>
>