[jira] Updated: (WICKET-992) Field validating behavior

["Frank Bille Jensen (JIRA)" <ji...@apache.org>]

     [ 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.