I'm not sure how this would be done. It would seem that a lot of potential
conflicts or clashes could occur with current functionality. In the
example:
@PageScope
private Customer customer;
This would presume that something is stored in the form itself and
submitted on postback. Something like this probably:
<input type="hidden" name="customer" value="<some bunch of encrypted
serialized hex>" />
Ok, good so far, but what if this is an edit screen for a customer? So we
have other fields on the screen like this:
<stripes:text name="customer.name"/>
On the final post, which one wins? Does the serialized object bind first
and then the individual fields bind/overwrite? How would validation work?
Can they be required? Should objects on the page be able to interact with
this object? ${viewState.customer}? There's a lot of unanswered questions
and potential issues. Iwao actually has a decent starting point for a
solution to this using a Formatter and TypeConverter -- I'm not sure much
else would be necessary.
I'm also trying to understand the reasons for this ask. As for keeping the
session small, you can still do that without having to resort to putting
serialized objects in your pages. In most cases, the session is merely
used as a holder of objects for the lifecycle of the request/response. As
for someone opening more than one browser to the same page, if you use the
request scope, I would think collisions would be prevented. Or am I
missing something here?
-- Rick
On Tue, Apr 3, 2012 at 7:26 AM, Chut Yee <yeec...@gmail.com> wrote:
>
> Hi Mike,
>
> Below are a couple of reasons:
> 1) I want to keep the session small.
> 2) If the user opens more than one browser windows/tabs working on the same
> page, they will interfere with each other if objects are stored in session.
>
> Regarding security issue - encryption will handle it. Even currently
> Stripes is
> already writing some state variables to the browser in encrypted form.
>
> Regards,
> Chut
>
>
>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
