Hi Jacob, Seam's state-saving method is server-side, right? The conversation will be stored on the server? Is that a persistent storage - in the sense of a database, or a volatile storage - in the sense of a server session (ok, I know, server side sessions can be persisted, too;) ?
option 1) So if you write the state-id down to the client and the conversation goes out of scope on the server, the reference would be lost, right? option 2) if the server-side state is something actually being persisted, then if you really persist every state any user had interacting with your system, you'll need some really cool hardware stuff for your webapp... and bookmarkable means you'll need to save the state for a really looooooooong time ;) See, my 2c, the thing is that we need client-side state saving here. We won't be able to store the million states we might get from our user-requests neither into the server memory nor a database. We need client-side state saving it (and if you want it bookmarkable, also URL based client-side state), and we need to restrict the size of the state to something usable. And this is where t:saveState comes in handy. So what I propose is a mixture: you have server-side (or form based client-side state saving) for the normal, highly stateful webapp stuff you do, and use client-side state saving in the URL for everything that is publicly accessible, needs to be bookmarked and has a very small state-footprint. regards, Martin On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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, [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 > >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 <[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] > >> >> > >> >> > >> > > > > > >-- > > > >http://www.irian.at > > > >Your JSF powerhouse - > >JSF Consulting, Development and > >Courses in English and German > > > >Professional Support for Apache MyFaces > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
