Scope-Problem: session is too long, scope is too short - best practice?

[Hendrik Neumann <he...@web.de>]

Hi guys,

I have the following problem: lets suppose I have a managed-bean which should 
be filled with content by the database if the user requests some certain 
informations and then the content of this bean should be rendered in the 
JSF-page. Then, after it is rendered (after the first request) the user can 
change these informations with forms and if the user clicks on the "save 
changed informations"-button the hole bean should be "updated" in the 
database. 

If I declare such a bean in the request-scope, the bean will be empty if the 
user clicks on the submit-button (except the changed values). So this will 
AFAIK not work. 

But if I choose "session-scope" the bean will never be killed as long as the 
user is logged in. This solution is very ugly and - more or less - a 
memory-leak because I have a lot of beans which should be first loaded with 
content and then manipulated (= 2x request-scope).

Is there a solution to set the scope to "request" but keeping this bean for 
two or more requests alive? Because session-scope is a unsatisfying option...

Greetings,
Hendrik

Re: Scope-Problem: session is too long, scope is too short - best practice?

[Hendrik Neumann <he...@web.de>]

Oh thanks Martin, this sounds interesting! I'll take a look at the 
saveState-Tags tomorrow!

Am Sonntag, 5. Juni 2005 21:40 schrieb Martin Marinschek:
> what about the x:saveState tags in MyFaces?
>
> I use these tags extensively to store only those beans I need exactly
> as long as they are needed...
>
> But also the request approach will work: not only the changed values
> are posted back to the server, but all values, so you get an
> initialized bean anyways.
>
> regards,
>
> Martin
>
> On 6/5/05, Hendrik Neumann <he...@web.de> wrote:
> > Hi guys,
> >
> > I have the following problem: lets suppose I have a managed-bean which
> > should be filled with content by the database if the user requests some
> > certain informations and then the content of this bean should be rendered
> > in the JSF-page. Then, after it is rendered (after the first request) the
> > user can change these informations with forms and if the user clicks on
> > the "save changed informations"-button the hole bean should be "updated"
> > in the database.
> >
> > If I declare such a bean in the request-scope, the bean will be empty if
> > the user clicks on the submit-button (except the changed values). So this
> > will AFAIK not work.
> >
> > But if I choose "session-scope" the bean will never be killed as long as
> > the user is logged in. This solution is very ugly and - more or less - a
> > memory-leak because I have a lot of beans which should be first loaded
> > with content and then manipulated (= 2x request-scope).
> >
> > Is there a solution to set the scope to "request" but keeping this bean
> > for two or more requests alive? Because session-scope is a unsatisfying
> > option...
> >
> > Greetings,
> > Hendrik

Re: Scope-Problem: session is too long, scope is too short - best practice?

[Werner Punz <we...@gmx.at>]

Werner Punz wrote:
> Some, but none of them is an easy plug and play thing.
> The scopes are one big hole in the current faces specs,
> as Martin has pointed out you can do it with x:saveState
> but then you need serialization.
> Another thing would be to remove the bean from the session as soon as 
> you hit the point where you know you dont need it anymore.
> 
> The closest thing to automation of point2 would be to check out shale
> and the dialogs system, which solves all these problems.
> 
> 
> 
Or to traverse the values via hidden fields...

Re: Scope-Problem: session is too long, scope is too short - best practice?

[Werner Punz <we...@gmx.at>]

Some, but none of them is an easy plug and play thing.
The scopes are one big hole in the current faces specs,
as Martin has pointed out you can do it with x:saveState
but then you need serialization.
Another thing would be to remove the bean from the session as soon as 
you hit the point where you know you dont need it anymore.

The closest thing to automation of point2 would be to check out shale
and the dialogs system, which solves all these problems.



Hendrik Neumann wrote:
> Hi guys,
> 
> I have the following problem: lets suppose I have a managed-bean which should 
> be filled with content by the database if the user requests some certain 
> informations and then the content of this bean should be rendered in the 
> JSF-page. Then, after it is rendered (after the first request) the user can 
> change these informations with forms and if the user clicks on the "save 
> changed informations"-button the hole bean should be "updated" in the 
> database. 
> 
> If I declare such a bean in the request-scope, the bean will be empty if the 
> user clicks on the submit-button (except the changed values). So this will 
> AFAIK not work. 
> 
> But if I choose "session-scope" the bean will never be killed as long as the 
> user is logged in. This solution is very ugly and - more or less - a 
> memory-leak because I have a lot of beans which should be first loaded with 
> content and then manipulated (= 2x request-scope).
> 
> Is there a solution to set the scope to "request" but keeping this bean for 
> two or more requests alive? Because session-scope is a unsatisfying option...
> 
> Greetings,
> Hendrik
> 

Re: Scope-Problem: session is too long, scope is too short - best practice?

[Martin Marinschek <ma...@gmail.com>]

what about the x:saveState tags in MyFaces?

I use these tags extensively to store only those beans I need exactly
as long as they are needed...

But also the request approach will work: not only the changed values
are posted back to the server, but all values, so you get an
initialized bean anyways.

regards,

Martin

On 6/5/05, Hendrik Neumann <he...@web.de> wrote:
> Hi guys,
> 
> I have the following problem: lets suppose I have a managed-bean which should
> be filled with content by the database if the user requests some certain
> informations and then the content of this bean should be rendered in the
> JSF-page. Then, after it is rendered (after the first request) the user can
> change these informations with forms and if the user clicks on the "save
> changed informations"-button the hole bean should be "updated" in the
> database.
> 
> If I declare such a bean in the request-scope, the bean will be empty if the
> user clicks on the submit-button (except the changed values). So this will
> AFAIK not work.
> 
> But if I choose "session-scope" the bean will never be killed as long as the
> user is logged in. This solution is very ugly and - more or less - a
> memory-leak because I have a lot of beans which should be first loaded with
> content and then manipulated (= 2x request-scope).
> 
> Is there a solution to set the scope to "request" but keeping this bean for
> two or more requests alive? Because session-scope is a unsatisfying option...
> 
> Greetings,
> Hendrik
>