>From: Martin Marinschek <[EMAIL PROTECTED]>
>
> Hi Jacob,
>
> yes, but I'm talking about being able to pass _some_ state here. So
> you don't go fully stateless, you have the ability to reduce the state
> to a size where it is usable with GET-Requests.
>
>
> Hi Jacob,
>
> yes, but I'm talking about being able to pass _some_ state here. So
> you don't go fully stateless, you have the ability to reduce the state
> to a size where it is usable with GET-Requests.
>
I agree with you Martin. Why not burn\generate a token that has
special meaning to the life cycle from the component API that could be
added as query parameter? It would be a special pass that would
allow a GET request to continue on. This would assume that
you already had state server side where the token was generated.
Why should JSF be discounted for companies that have strict accessibility
standards prohibiting _javascript_ for navigation?
> And I want to use MyFaces t:saveState feature for providing this
> ability. Together with an error to tell you if your state has grown
> too large, this is something that might be usable in many cases where
> full state just doesn't work.
>
> regards,
>
> Martin
>
> On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>wrote:
> > If you want to go minimal/stateless with JSF, it's somewhat do-able. I was
> able to take a sandbox of Facelets and simply:
> >
> > 1) Always write an empty hidden input param for 'javax.faces.ViewState' to get
> the succeeding request to expect a Restored View
> >
> > 2) Within ViewHandler.restoreView(..) call createView(..) and actually
> populate it before the decode phase so parameters/state can be operated on.
> >
> > 3) On render, don't bother saving state, but pass the view-root for
&g t; re-building to update the tree state for rendering again.
> >
> > I was able to get things using UIData, like the notorious Hangman demo working
> with the above implementation. It would break, of course, for components that
> expected retained state across calls, but the declarative nature of component
> use and the proper view/model separation via EL makes this very practical.
> >
> > Basically, all components have a request-scoped lifecycle instead of a session
> one as they exist now. Performance wise, there wasn't much change (20-30ms
> better w/ request-scoped).
> >
> > -- Jacob
> >
> > >
> > >As Ed noted, saving everything into the GET request does not work
> > >because of URL size limitations. Old stagers within the MyFaces
> > >community might remember the so called "minimizing state" feature in
> > >early MyFaces 0.x versions. The goal was to provide a JSF
> > >implementation that works without _javascript_ AND without Servlet
> > >sessions.
> > >Well, as you know, we gave up the idea of saving everything to the
> > >URL. It's simply unsolvable AFAICT.
> > >
> > >What Martin proposes is a rather simple solution that - of course -
> > >breaks normal JSF lifecycle, but could be a good solution for the
> > >ordinary webapp. Most bookmarkable pages are those that you can reach
> > >via a navigation menu or alike. Not much state information needed in
> > >most of these cases. What important information do we need when a user
> > >comes back to a "menu linked" page via bookmark?
> > >- the logged in user: we get him from the JASS authentication if we are lucky
> > >- some kind of id (product id or things li ke that): it's part of the
> > >URL if we use the bookmarkable feature of the t:safeState tag
> > >- more?
> > >
> > >This is no all-out-of-the-box solution, but I think it's worth playing
> > >around a little bit with this solution.
> > >
> > >+1 for Martins proposal - give it a shot
> > >
> > >Manfred
> > >
> > >
> > >
> > >
> > >2006/1/27, Ed Burns <[EMAIL PROTECTED]>:
> > >> Gruß Gott,
> > >>
> > >> >>>>> On Fri, 27 Jan 2006 10:43:23 +0100, Werner Punz <[EMAIL PROTECTED]>said:
> > >>
> > >> WP> +1000 for a get....
> > >> WP> Martin Marinschek schrieb:
> > >>
> > >> MM> I'm having ideas again. Must come from too much work with JSF ;)
> > &g t;> MM>
> > >> MM> My idea:
> > >> MM>
> > >> MM> Bookmarking is a problem with JSF, right? Except you use h:outputLink,
> > >> MM> but then there's this slight problem with not being in the action
> > >> MM> system anymore ;)
> > >> MM>
> > >> MM> Now, what do I want to be able to see in my history or to bookmark? I
> > >> MM> want to bookmark simple pages, where state is not so important at all.
> > >> MM> Or only a small portion of the state is important...
> > >> MM>
> > >> MM> Those simple pages I usually refer to with an "action" attribute that
> > >> MM> is put (as a string) directly on the
> > >> MM>
> & gt; >> MM>
> > >> MM> Why not render out this action attribute as a parameter to the URL of
> > >> MM> the link optionally, not submitting a form and loosing all JSF state,
> > >> MM> but having a bookmarkable link?
> > >> MM>
> > >> MM> The developer can decide then:
> > >> MM> - do I need this link to be bookmarked
> > >> MM> - do I want this link to use the plain old JSF posting system with
> > >> MM> state-saving.
> > >>
> > >> Right, I've thought about this problem for the Sun impl, and we even
> > >> have an issue on our issue tracker for it:
> > >>
> > >> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=72
> > >>
> > >> MM> Enhancement: we could additionally render out params to this li nk as -
> > >> MM> yes, right, params to the URL. So people can optionally build there
> > >> MM> web-apps just like they were used to when JSF wasn't around.
> > >>
> > >> MM> Good idea - bad idea - better idea ;) ?
> > >>
> > >> But I can't see how to do it in a general way while supporting both
> > >> client and server side state saving modes. This is due, of course,
> > >> to the restriction on size of the GET request.
> > >>
> > >> Another problem, when using the server side mode, is what to do when the
> > >> session expires.
> > >>
> > >> Any solution that doesn't deal with these cases is a less than full
> > >> solution.
> > >>
> > >> I was thinking of decorating the state manager to somehow write out
& gt; > >> bookmarked pages to the filesystem so they can survive session
> > >> expiration, but then, what do you do about failover?
> > >>
> > >> Ed
> > >>
> > >> --
> > >> | [EMAIL PROTECTED] | {home: 407 869 9587, office: 408 884 9519 OR x31640}
> > >> | homepage: | http://purl.oclc.org/NET/edburns/
> > >> | aim: edburns0sunw | iim: [EMAIL PROTECTED]
> > >>
> > >>
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
> ability. Together with an error to tell you if your state has grown
> too large, this is something that might be usable in many cases where
> full state just doesn't work.
>
> regards,
>
> Martin
>
> On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>wrote:
> > If you want to go minimal/stateless with JSF, it's somewhat do-able. I was
> able to take a sandbox of Facelets and simply:
> >
> > 1) Always write an empty hidden input param for 'javax.faces.ViewState' to get
> the succeeding request to expect a Restored View
> >
> > 2) Within ViewHandler.restoreView(..) call createView(..) and actually
> populate it before the decode phase so parameters/state can be operated on.
> >
> > 3) On render, don't bother saving state, but pass the view-root for
&g t; re-building to update the tree state for rendering again.
> >
> > I was able to get things using UIData, like the notorious Hangman demo working
> with the above implementation. It would break, of course, for components that
> expected retained state across calls, but the declarative nature of component
> use and the proper view/model separation via EL makes this very practical.
> >
> > Basically, all components have a request-scoped lifecycle instead of a session
> one as they exist now. Performance wise, there wasn't much change (20-30ms
> better w/ request-scoped).
> >
> > -- Jacob
> >
> > >
> > >As Ed noted, saving everything into the GET request does not work
> > >because of URL size limitations. Old stagers within the MyFaces
> > >community might remember the so called "minimizing state" feature in
> > >early MyFaces 0.x versions. The goal was to provide a JSF
> > >implementation that works without _javascript_ AND without Servlet
> > >sessions.
> > >Well, as you know, we gave up the idea of saving everything to the
> > >URL. It's simply unsolvable AFAICT.
> > >
> > >What Martin proposes is a rather simple solution that - of course -
> > >breaks normal JSF lifecycle, but could be a good solution for the
> > >ordinary webapp. Most bookmarkable pages are those that you can reach
> > >via a navigation menu or alike. Not much state information needed in
> > >most of these cases. What important information do we need when a user
> > >comes back to a "menu linked" page via bookmark?
> > >- the logged in user: we get him from the JASS authentication if we are lucky
> > >- some kind of id (product id or things li ke that): it's part of the
> > >URL if we use the bookmarkable feature of the t:safeState tag
> > >- more?
> > >
> > >This is no all-out-of-the-box solution, but I think it's worth playing
> > >around a little bit with this solution.
> > >
> > >+1 for Martins proposal - give it a shot
> > >
> > >Manfred
> > >
> > >
> > >
> > >
> > >2006/1/27, Ed Burns <[EMAIL PROTECTED]>:
> > >> Gruß Gott,
> > >>
> > >> >>>>> On Fri, 27 Jan 2006 10:43:23 +0100, Werner Punz <[EMAIL PROTECTED]>said:
> > >>
> > >> WP> +1000 for a get....
> > >> WP> Martin Marinschek schrieb:
> > >>
> > >> MM> I'm having ideas again. Must come from too much work with JSF ;)
> > &g t;> MM>
> > >> MM> My idea:
> > >> MM>
> > >> MM> Bookmarking is a problem with JSF, right? Except you use h:outputLink,
> > >> MM> but then there's this slight problem with not being in the action
> > >> MM> system anymore ;)
> > >> MM>
> > >> MM> Now, what do I want to be able to see in my history or to bookmark? I
> > >> MM> want to bookmark simple pages, where state is not so important at all.
> > >> MM> Or only a small portion of the state is important...
> > >> MM>
> > >> MM> Those simple pages I usually refer to with an "action" attribute that
> > >> MM> is put (as a string) directly on the
> > >> MM>
> & gt; >> MM>
> > >> MM> Why not render out this action attribute as a parameter to the URL of
> > >> MM> the link optionally, not submitting a form and loosing all JSF state,
> > >> MM> but having a bookmarkable link?
> > >> MM>
> > >> MM> The developer can decide then:
> > >> MM> - do I need this link to be bookmarked
> > >> MM> - do I want this link to use the plain old JSF posting system with
> > >> MM> state-saving.
> > >>
> > >> Right, I've thought about this problem for the Sun impl, and we even
> > >> have an issue on our issue tracker for it:
> > >>
> > >> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=72
> > >>
> > >> MM> Enhancement: we could additionally render out params to this li nk as -
> > >> MM> yes, right, params to the URL. So people can optionally build there
> > >> MM> web-apps just like they were used to when JSF wasn't around.
> > >>
> > >> MM> Good idea - bad idea - better idea ;) ?
> > >>
> > >> But I can't see how to do it in a general way while supporting both
> > >> client and server side state saving modes. This is due, of course,
> > >> to the restriction on size of the GET request.
> > >>
> > >> Another problem, when using the server side mode, is what to do when the
> > >> session expires.
> > >>
> > >> Any solution that doesn't deal with these cases is a less than full
> > >> solution.
> > >>
> > >> I was thinking of decorating the state manager to somehow write out
& gt; > >> bookmarked pages to the filesystem so they can survive session
> > >> expiration, but then, what do you do about failover?
> > >>
> > >> Ed
> > >>
> > >> --
> > >> | [EMAIL PROTECTED] | {home: 407 869 9587, office: 408 884 9519 OR x31640}
> > >> | homepage: | http://purl.oclc.org/NET/edburns/
> > >> | aim: edburns0sunw | iim: [EMAIL PROTECTED]
> > >>
> > >>
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
