struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: Fundamental flaw in Model-Driven?
Date Wed, 30 Apr 2008 22:42:23 GMT
Adam Hardy on 26/04/08 10:42, wrote:
> 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:

>>> ...
>>> 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.

I am pulling in what I wrote earlier because I should correct what I said about 
letting entities slip out of scope. Following this situation:

- Model-driven builds the model
- conversion to type and setting incoming HTTP param into Model
- validation occurs and fails

the problem was spurious JPA updates - which can be avoided by putting an 
interceptor in between the Validation and the Workflow interceptors: all it 
should do is call EntityManager.clear().

if (validationAwareAction.hasErrors()) getEntityManager().clear();

Using the JPA extended persistence context (not EJB), the clear() will eliminate 
any changes to the model before JPA comes to flush to the db. I assume it would 
work in an EJB container too.

Does that fit your situation, Eric?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message