[ 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-rc1) 1.3.0-rc2 > 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-rc2 > > > 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.