Hey Patrick,
> I'm writing an "Update Account" page where a user can set his email
> address and password, among other things. The first thing I tried was
> a @Before method that pulled in the current user and assigned it to
> the "account" field, hoping it happened before "account.email",
> "account.firstName", etc were applied. No such luck.
I think your first reaction was correct, you just didn't quite finish
the thought :) @Before takes a single parameter which is an array of
LifecycleStage (it's an enum), and it defaults to {EventHandling}.
You'd just want to specify it as @Before
(LifecycleStage.BindingAndValidation).
> The next thing I thought about trying was a nice type converter for
> all accounts. A hidden ID of could be used to specify the "account"
> parameter as a the current user's ID.
>
> This works but is very insecure. The simplistic way to handle this is
> to simply check the account ID against the current user ID before
> allowing anything to go further in my action bean. This works fine,
> but I'd really love to not have to specify the ID at all in my form.
> Rather, wouldn't it be nice if my type converter understood a value
> of "currentUser" and pulled that in? I had hoped it could work, but
> the TypeConverter interface doesn't supply the ActionBeanContext.
>
> So, two questions:
>
> 1) Is the hidden ID + ID check the common way to do this in stripes?
That's a good question. It's something I've been thinking about
more. In this case a @Before method will work reasonably well. But
take any example with more items (calendar entries, accounts, etc.)
where you reasonably need to stick an ID in the page, how do you stop
the user from cheating?
I'm really not sure what a good solution to this is. About the best
I've come up with (and it's not original) would be to hash URLs for
gets and store the list of hashes the use can request, and then for
POSTs use more server-side state management so that the ID is never
passed back and forth. But this is very heavyweight and would
require lots of changes.
> 2) Why can't the TypeConverter get the ActionBeanContext?
Well, when I wrote the interface I thought it would be a good idea to
have the whole type conversion system be state-independent so that
it's easier to test and more predictable. But if a compelling
argument can be made, I could see changing that.
-t
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
