You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Carlos Pita (JIRA)" <ji...@apache.org> on 2007/09/20 21:45:33 UTC
[jira] Created: (WICKET-992) Field validating behavior
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.
[jira] Updated: (WICKET-992) Field validating behavior
Posted by "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.
[jira] Updated: (WICKET-992) Field validating behavior
Posted by "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-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.
[jira] Updated: (WICKET-992) Field validating behavior
Posted by "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-rc3)
1.3.0-final
> 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
> Assignee: Igor Vaynberg
> Priority: Minor
> Fix For: 1.3.0-final
>
>
> 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.
[jira] Resolved: (WICKET-992) Field validating behavior
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg resolved WICKET-992.
----------------------------------
Resolution: Fixed
Assignee: Igor Vaynberg
added overridable boolean getUpdateModel() to ajaxformcomponentupdatingbehavior
> 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
> Assignee: Igor Vaynberg
> 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.
[jira] Updated: (WICKET-992) Field validating behavior
Posted by "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:
--------------------------------------
Affects Version/s: (was: 1.3.0-beta4)
> 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
>
> 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.