|
»
»
»
« Return to Thread: Fundamental flaw in Model-Driven?
Re: Fundamental flaw in Model-Driven?
by Chase-16
::
Rate this Message:
Could you do what you propose with a custom interceptor stack? Make your
first call to getModel() return a serialized copy of the model object
and the second call return the managed instance. Internally the action
would maintain the reference to the managed instance from the time of
the first getModel() or prepare() call.
<interceptor-stack name="JPAparamsPrepareParamsStack">
<interceptor-ref name="exception"/>
<interceptor-ref name="alias"/>
<interceptor-ref name="servletConfig"/>
<interceptor-ref name="params"/>
<interceptor-ref name="prepare"/>
<interceptor-ref name="modelDriven"/>
<interceptor-ref name="params"/>
<interceptor-ref name="fileUpload"/>
<interceptor-ref name="checkbox"/>
<interceptor-ref name="staticParams"/>
<interceptor-ref name="conversionError"/>
<interceptor-ref name="validation">
<interceptor-ref name="i18n"/>
<interceptor-ref name="workflow">
<param name="excludeMethods">input,back,cancel</param>
</interceptor-ref>
<interceptor-ref name="modelDriven"/>
<interceptor-ref name="params"/>
<interceptor-ref name="checkbox"/>
<interceptor-ref name="staticParams"/>
</interceptor-stack>
-Chase
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
>
> First I outline the problem, then a possible framework provided solution and a
> request for feedback before I start trying to generate a patch.
>
> In brief:
> Configuration:
> ModelDriven with validation is configured
> Hibernate/JPA is being used (OpenEntityManagerInView/OpenSessionInView is
> something of a red-herring)
>
> Sequence of Events:
> Model is loaded from DB
> Params (second params) inject parameters into the model
> Validation fails
> Input reached
> session.flush occurs (either from closing the session in OSIV pattern, OR from
> an implicit flush before an explicit query or a lazy-load query)
> dirty and invalid object written to the DB
>
> In the thread referenced, his solution was to preload all collections backing
> form elements -- thus avoiding the lazy-load queries after dirtying the object.
> (This is why I say a lot of the discussion in that thread about the flush in
> OEMIV is a red-herring. It could cause the problem, but wasn't the cause of
> the problem)
>
> A lot of the other workarounds suggested in the thread seem very unclean as its
> something that should be taken care of by the framework.
>
> To my eye, there is a fundamental flaw in Struts 2 validation (and type
> conversion). Under the model-driven paradigm, validation conditions need to be
> viewed as invariants, and either all fields should be set or none -- it should
> be atomic. There is also a violation of the SRP going on by making the model
> objects responsible for holding and redisplaying invalid values to the web
> form.
>
> 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.
>
> Thank you for reading,
> Eric Nielsen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
first call to getModel() return a serialized copy of the model object
and the second call return the managed instance. Internally the action
would maintain the reference to the managed instance from the time of
the first getModel() or prepare() call.
<interceptor-stack name="JPAparamsPrepareParamsStack">
<interceptor-ref name="exception"/>
<interceptor-ref name="alias"/>
<interceptor-ref name="servletConfig"/>
<interceptor-ref name="params"/>
<interceptor-ref name="prepare"/>
<interceptor-ref name="modelDriven"/>
<interceptor-ref name="params"/>
<interceptor-ref name="fileUpload"/>
<interceptor-ref name="checkbox"/>
<interceptor-ref name="staticParams"/>
<interceptor-ref name="conversionError"/>
<interceptor-ref name="validation">
<interceptor-ref name="i18n"/>
<interceptor-ref name="workflow">
<param name="excludeMethods">input,back,cancel</param>
</interceptor-ref>
<interceptor-ref name="modelDriven"/>
<interceptor-ref name="params"/>
<interceptor-ref name="checkbox"/>
<interceptor-ref name="staticParams"/>
</interceptor-stack>
-Chase
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
>
> First I outline the problem, then a possible framework provided solution and a
> request for feedback before I start trying to generate a patch.
>
> In brief:
> Configuration:
> ModelDriven with validation is configured
> Hibernate/JPA is being used (OpenEntityManagerInView/OpenSessionInView is
> something of a red-herring)
>
> Sequence of Events:
> Model is loaded from DB
> Params (second params) inject parameters into the model
> Validation fails
> Input reached
> session.flush occurs (either from closing the session in OSIV pattern, OR from
> an implicit flush before an explicit query or a lazy-load query)
> dirty and invalid object written to the DB
>
> In the thread referenced, his solution was to preload all collections backing
> form elements -- thus avoiding the lazy-load queries after dirtying the object.
> (This is why I say a lot of the discussion in that thread about the flush in
> OEMIV is a red-herring. It could cause the problem, but wasn't the cause of
> the problem)
>
> A lot of the other workarounds suggested in the thread seem very unclean as its
> something that should be taken care of by the framework.
>
> To my eye, there is a fundamental flaw in Struts 2 validation (and type
> conversion). Under the model-driven paradigm, validation conditions need to be
> viewed as invariants, and either all fields should be set or none -- it should
> be atomic. There is also a violation of the SRP going on by making the model
> objects responsible for holding and redisplaying invalid values to the web
> form.
>
> 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.
>
> Thank you for reading,
> Eric Nielsen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
« Return to Thread: Fundamental flaw in Model-Driven?
| Free Forum Powered by Nabble | Forum Help |