struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chase <ch...@osdev.org>
Subject Re: Fundamental flaw in Model-Driven?
Date Sat, 26 Apr 2008 19:29:18 GMT
Adam Hardy wrote:
> Chase on 26/04/08 11:16, wrote:
>>
>>>
>>> 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.
>>>
>> If it was a blank (just id) entity then you'd lose the ability to 
>> validate "num1 > num2" where num1 was set by the params interceptor 
>> but num2 came from the database.
>
> Sorry Chase, can you elaborate a little? You're talking about one of 
> the S2 validations? I didn't see that in the list.
>

The number of params might be less than the number of properties in the 
entity. A benefit of using a managed object to perform validation is 
that the validation interceptor can compare the params AND the db 
populated properties. Imagine an objeiect with two properties, minPrice 
and maxPrice. If a form is submitted that modifies the minPrice don't 
you want to be able to validate it to make sure that it doesn't exceed 
the value of maxPrice?  But then you have the problem of the original 
poster which basically comes down to, if you give the params & 
validation interceptors a live managed entity then it might end up 
causing unwanted database updates. I'm just saying that I don't think 
the problem should be fixed in such a way as to lose the ability to 
validate params against the db values of other properties.

I think there are 3 possible ways to fix the problem.

1) Basically something along the lines of what the original poster 
stated, make a copy of the managed object to use for validation. The 
thread he linked to mentioned BeanUtils.copyProperties(tempBean, 
yourBean) but I  think Jeromy was right when he warned about possibly 
pulling in all related entities. I think serialization would be a better 
technique to copy the object (ObjectOutputStream -> Pipe -> 
ObjectInputStream).

2) Enhance the model driven and validation interceptors. Instead of 
pushing the result of getModel() directly on the stack the model driven 
interceptor could first wrap the entity in some type of dynamically 
generated EntityWrapper class and push the wrapper on the stack. The 
EntityWrapper would leverage the real entity object to read the existing 
db values but cache all property changes until some type of flush 
operation occurred. The validation interceptor, upon finishing 
validation with no action errors, would call the flush method on the 
wrapper which would cause all modified properties to be transfered to 
the managed entity.

3) This basically comes down to wanting everything to succeed or nothing 
to succeed (no partial completion). That's what transactions are for. 
Make versions of the interceptors that integrate with the transactions 
used by the persistence engines.

-Chase

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


Mime
View raw message