[
https://issues.apache.org/jira/browse/WICKET-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Bille Jensen updated WICKET-992:
--------------------------------------
Fix Version/s: (was: 1.3.0-rc2)
1.3.0-rc3
> 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
> Reporter: Carlos Pita
> Priority: Minor
> Fix For: 1.3.0-rc3
>
>
> 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.
