Ahh okay.. thanks for the details! Sounds like something, albeit more advanced, then what I was trying to do with a Phase listener approach maintaining session objects via viewIds and "rules" and destroying as necessary according to these parameters as well as using servlet filters for the rest of the cleanup I needed.
Worked very well for current view (ie.. page reloads) and simple 2 pages list / detail relationships... but for a true "process scope", I quickly realized this I may have bit off more then I could chew!! :) I'm going to give the samples a shot now and if they work well implement them on a more extreme level! Thank you very much! Werner Punz wrote: > > Nenz schrieb: >> Looks great! Just what I need. >> >> Finally something to help us abstract the joys of "process scope" in a >> web >> app. I truely believe we have taken the (stateless) protocol itself well >> beyond what it was originally intended to do, thus all the hacks we are >> having to do to get around a fundamental "flaw" as opposed to perhaps >> developing a new protocol itself (I know that's a much bigger >> conversation) >> >> Not knowing the inner workings of this other then it uses a filter, are >> there any differences between using server state saving / client state >> saving... the Sun RI vs MyFaces Impl? >> >> I guess the true question is ... on a high level.. how is this >> maintaining >> state... I'm assuming it's either swapping session or serializing objects >> in >> hidden form fields and using url parms to further maintain this info? >> >> Thanks! >> >> > Mario may correct me if I am wrong since I know the mechanisms only from > long Discussions I had with him, he basically was starting the thing > when I gave him the idea on a tag I once did which was a savestate > replacment which used the session directly instead of going the > savestate route. > And what he did was some genious kind of work indeed. > > What it does as I assume is saving the affected objects into the session > and using a servlet filter for the garbage collecting the objects. > > Hence pure client side savestating still will push those objects into > the session, as I assume, the rest of the functionality is built around > this idea. > > I dont know how far mario has driven the idea, from an earlier > discussion we had on this one, it was clear some generic orm sesssion > handler interface for orm mappers also must be integrated to ease the > burdens on the orm using people. I am not sure how far mario has driven > this by now. > > The whole thing was thought originally to replace the basic scope > mechanisms of seam which are excellent ideawise, but too strongly bound > to ejb3, with a tag based approach, which we both liked from savestate, > so that you neither have to deal with EJB3 on a server level nor with > xml configuration graves like other scope approaches follow. > > > -- View this message in context: http://www.nabble.com/Save---restore-state-of-entire-view--tf2443158.html#a6835446 Sent from the MyFaces - Users mailing list archive at Nabble.com.
