Hi,

For binding Stripes always binds shortest parameters first.
So if you have these two bindings:
<stripes:hidden name="customer"/>
<stripes:hidden name="customer.name"/>
"customer" will always be bound before "customer.name".

This makes sense to me.

Christian

De : Rick Grashel [mailto:rgras...@gmail.com]
Envoyé : April-03-12 8:52 AM
À : Stripes Users List
Objet : Re: [Stripes-users] Proposal: Page Scope

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<http://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<mailto: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<mailto: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

Reply via email to