struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <ahardy.str...@cyberspaceroad.com>
Subject Re: Fundamental flaw in Model-Driven?
Date Sat, 26 Apr 2008 09:42:33 GMT
Jeromy Evans on 26/04/08 04:51, wrote:
> Eric D Nielsen wrote:
>> I've been investigating some interesting behavior regarding model-driven
>> actions and found a past thread that covers the situation from late last
>> year:
>>
>> http://www.nabble.com/ModelDriven-CRUD-validation-failure-still-causes-JPA-update-td12987242.html

>> ...
>>
>> It would seem to be a way forward exists, however. Model Driven can be
>> tweaked as follows:
>>   The model driven interceptor would need to
>> a) capture the raw request parameters into some storage
>> b) skip the second params interceptor
>> c) create a copy of the getModel object  (to ensure its detached from any
>> persistence session -- need to make sure this works for other common
>> persistence engines)
>> d) run params/validation on this copy
>> e) if no validation errors, run params on the orginal (still attached 
>> to the
>> persistence session), and proceed as normal
>> f) if validation errors, intercept calls to the getters for values in 
>> the raw
>> request for redisplay -- need to worry about XSS issues here
>>
>> There's a lot of moving pieces, and I'm sure I'm missing some even more
>> subtle interactions. However I do think something needs to be done. I'm 
>> interesting in tackling this, and am hoping for some feedback on the above
>> outline of required changes.
>>   
> Hi Eric,
> I haven't had an opportunity to absorb your suggestion properly yet but 
> thought I'd mention I agree with your line of thinking that the 
> validation mechanism in particular needs to be improved. However, this 
> is a general problem that also applies to rich clients; that is 
> responsibility for rolling back changes to a model, and various patterns 
> have developed over the years.  A temporary copy is a simple 
> implementation, however within a JPA-environment automatically creating 
> a clone is often infeasible or undesirable. For example, if it's 
> attached to a session, this process may cause hydration of the entire 
> object graph. Unless the framework is provided hints, it won't know what 
> to safely/efficiently clone.
> 
> Having the framework maintain dirty flags or proxy for the model also 
> seems ineffective as the JPA provider performs the exact same task, only 
> better.
> 
> The option to write straight to the model (or DTO) and performing 
> validation of the model (or DTO) is a distinguishing feature of Struts 
> 2, but also the source of such complications. Anyway, I don't have a 
> solution, but I do intend to start resolving the numerous validation 
> issues in JIRA in the near future and this one is the list.

I also stumbled across this problem.

One solution could be to use a TypeConverter to instantiate new, unmanaged 
entities during the ParamsInterceptor invocation.

Such a TypeConverter could pass back instantiated, blank entities (with nothing 
but the ID) for ParamsInterceptor to collate, and against which 
ValidationInterceptor can operate. E.g. for param 'bean=69', the type converter 
instantiates Bean and calls setId(69)

Once Validation succeeds, ModelDriven and ParamsInterceptor should be invoked 
again to update the managed entities.

The unmanaged entities would just disappear out of scope and be garbage collected.

Such a strategy would require modification to ParamsInterceptor to tell it to 
use the initial TypeConverter on the first call, but not on the second. Whether 
the algorithm that controls that is accessible for modification in the 
ParamsInterceptor or whether it is out-of-reach in OGNL somewhere, I'm not sure.


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


Mime
View raw message