ModelDriven vs OGNL assignment?

[Gary Affonso <gl...@greywether.com>]

In our previous WebWork app we were not using ModelDriven and just 
relying on OGNL assignment...

* We ensure our action provides a getter for the domain object

   private Account account;
   public Account getAccount();

* We ensure html fieldnames include both the domain object name and the 
property

   <input type="hidden" name="account.accountName" value="foo" />

And that does it.  Direct model injection.  Easy.

So my question is this...

Is there any benefit in dealing with the added complexity of 
ModelDriven?  It's one more interceptor, and it's one more thing the 
action has to implement.  Neither are terribly burdensome but it's more 
work than just doing OGNL assignment and I'm wondering why one might go 
that way.

Is it a security thing?  I know there are security issues around OGNL 
resolution (or there were).  Does ModelDriven do a better job of locking 
down what properties are injectable from HTML?

I was hoping, that ModelDriven might be a more elegant way to handle 
associations in the targeted domain object.  Since 
ModelDrivenInterceptor comes after the ParameterInterceptor, your form 
can declare the ID for the associated object and then in your getModel() 
method (called after parameter resolution) you've got the opportunity to 
resolve those IDs into real object associations before handing off the 
model.

But after thinking about it, this isn't any more elegant than how we do 
it now.  We basically do the same thing (IDs in the HTML), we just 
resolve the associations after the model's other properties are injected 
(instead of before).  So that's apparently not of much advantage.

What am I missing?  Why would I use ModelDriven instead?

Thanks!

- Gary

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: ModelDriven vs OGNL assignment?

[Gary Affonso <gl...@greywether.com>]

Dave Newton wrote:
> --- Gary Affonso <gl...@greywether.com> wrote:
>> And that does it.  Direct model injection.  Easy.
> 
> Technically, no, it's indirected by one level.
> 
> *All* ModelDriven does is push the model on to the
> stack so it's available at the top level. AFAIK
> there's no compelling reason to do that other than
> saving some very minor typing (and, perhaps, clarity?)
> on the display side.

Thanks for the info.  I personally find ModelDriven *less* clear in the 
view layer.  With ModelDriven you get something like...

   <input type="hidden" name="firstName" value="foo" />

instead of...

   <input type="hidden" name="postalAddress.firstName" value="foo" />

I *like* that the model-object name is in the view along with the 
property name, I find it more explicit and clear.  Maybe that's just me, 
though.

I had heard talk at one point that there was a plan to address the 
security shortcomings of letting the view directly inject into the 
Action.  I was thinking ModelDriven was where that security check 
happened.  Apparently not.

Anybody know if/how security is handled for OGNL expressions contained 
within the names of post/get data?  They're obviously getting evaluated 
(thus the security issue), I thought I had seen a post go by talking 
about how that evaluation was being made safe(r).

Thanks!

- Gary

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: ModelDriven vs OGNL assignment?

[Dave Newton <ne...@yahoo.com>]

--- Gary Affonso <gl...@greywether.com> wrote:
> And that does it.  Direct model injection.  Easy.

Technically, no, it's indirected by one level.

*All* ModelDriven does is push the model on to the
stack so it's available at the top level. AFAIK
there's no compelling reason to do that other than
saving some very minor typing (and, perhaps, clarity?)
on the display side.

OTOH, ScopedModelDriven does a bit more automagically.

d.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org