myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ja...@hookom.net
Subject RE: Re: Re: Bookmarking, History and JSF
Date Fri, 27 Jan 2006 16:55:29 GMT
Yeah, that's correct, who says ViewState actually has to be your component model? :-)

I've thought about progressing the stateless JSF solution to instead just write Seam's converstation
ID as the ViewState (a numeric long) to match up to model state.  This kind of solution makes
a lot more sense than retaining the component model between requests.  It would be similar
to t:saveState, but is a little more natural for the view/model separation.

-- Jacob

>
>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.
>
>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, jacob@hookom.net <jacob@hookom.net> 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 
>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 like 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 <ed.burns@sun.com>:
>> >> Gruß Gott,
>> >>
>> >> >>>>> On Fri, 27 Jan 2006 10:43:23 +0100, Werner Punz <werpu@gmx.at>

>said:
>> >>
>> >> WP> +1000 for a get....
>> >> WP> Martin Marinschek schrieb:
>> >>
>> >> MM> I'm having ideas again. Must come from too much work with JSF ;)
>> >> 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 <h:commandLink /> or
>> >> MM> <h:commandButton/> tag, right?
>> >> 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 link
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
>> >> bookmarked pages to the filesystem so they can survive session
>> >> expiration, but then, what do you do about failover?
>> >>
>> >> Ed
>> >>
>> >> --
>> >> | ed.burns@sun.com  | {home: 407 869 9587, office: 408 884 9519 OR 
>x31640}
>> >> | homepage:         | http://purl.oclc.org/NET/edburns/
>> >> | aim: edburns0sunw | iim: ed.burns@sun.com
>> >>
>> >>
>>
>
>
>--
>
>http://www.irian.at
>
>Your JSF powerhouse -
>JSF Consulting, Development and
>Courses in English and German
>
>Professional Support for Apache MyFaces

Mime
View raw message