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 <[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 ;) > 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 > > -- > | [EMAIL PROTECTED] | {home: 407 869 9587, office: 408 884 9519 OR x31640} > | homepage: | http://purl.oclc.org/NET/edburns/ > | aim: edburns0sunw | iim: [EMAIL PROTECTED] > >
