struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric D Nielsen <niels...@MIT.EDU>
Subject Fundamental flaw in Model-Driven?
Date Thu, 24 Apr 2008 15:43:07 GMT
I've been investigating some interesting behavior regarding model-driven actions
and found a past thread that covers the situation from late last year:

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

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:
For additional commands, e-mail:

View raw message