Chase on 26/04/08 20:29, wrote:
Adam Hardy wrote:
Chase on 26/04/08 11:16, wrote:
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 really like that second solution to the problem where you would use a dynamic
entity wrapper to cache the incoming HTTP version of the data (we had something
a little like that on our last project).
My reaction would be to refuse to accept the problem:
- in the example with minPrice vs maxPrice, on grounds of KISS, I would simply
put the original values in hidden fields rather than try validations relying on
retrieval from the database. For security, to stop the client being able to
cheat by manipulating the hidden fields with some Firefox plug-in, you would
also verify such business rules in the entity manager as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
