Field validating behavior
-------------------------
Key: WICKET-992
URL: https://issues.apache.org/jira/browse/WICKET-992
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.3.0-beta3, 1.3.0-beta4
Reporter: Carlos Pita
Priority: Minor
Suppose you need to edit a persistent entity progressively ajax-validating it
field-by-field (so ajaxformvalidatingbehavior is out of case here). If you use
ajaxformcomponentupdatingbehavior you have a number of alternatives:
1) Tolerate partial updating if you use tx-per-request.
2) Use a read-only tx for the presentation layer so partial changes won't be
committed to the db.
3) Make your entity serializable, detach it from persistent session and store
it into the wicket session as a form (java)field.
4) Clone you entity after loading it, then update and discard the clone,
leaving the original entity unmodified.
5) Create a dto and edit it instead of the original entity. Then merge the
changes into the entity when the form is finally submitted.
It's often the case that partial updating can't be tolerated as suggested in 1.
Also, 1,2 and 4 suffer from unnecessary overhead because they all hit the db
when the only requirement is validating a field (binding is superfluous, this
is clear from the fact that changes are discarded at the final of the request
in 2 and 4). 3 suffers from its own overhead too: wicket session space, and
also forces you to make your classes serializable, which can be somewhat of a
headache when entities are big and composed of a number of embedded components
and also undesirable because silent storage into the wicket session could occur
later when it isn't really intended; as a rule of thumb i prefer to avoid
serialization for big entities when possible. 5 implies redundant code and
work, in general practice I find it more cumbersome and not really better than
3.
The only step in ajaxformcomponentupdatingbehavior workflow that requires model
object access is the line formComponent.updateModel(). Except for this the
behavior perfectly fits as a validating behavior. I could copy past everything
into a new class of mine and remove the offending line but I feel that a flag
that avoids the updating step or another hook or point of extension in order to
achieve a validation-only behavior can be of more general use and also
orthogonal in the sense that wicket already has validation-only functionality
at the form level. Or ajaxformcomponentupdatingbehavior could extend a
ajaxformcomponent*validating*behavior adding the updating step.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
