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