myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nenz <>
Subject Re: Save / restore state of entire view?
Date Mon, 16 Oct 2006 14:21:20 GMT

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:
Sent from the MyFaces - Users mailing list archive at

View raw message