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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
