You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Jens Breitenstein (JIRA)" <ji...@apache.org> on 2011/08/25 13:39:31 UTC
[jira] [Created] (TAP5-1618) Component events "onValidate /
onSuccess / onFailure"
Component events "onValidate / onSuccess / onFailure"
-----------------------------------------------------
Key: TAP5-1618
URL: https://issues.apache.org/jira/browse/TAP5-1618
Project: Tapestry 5
Issue Type: New Feature
Components: tapestry-core
Affects Versions: 5.3, 5.4
Reporter: Jens Breitenstein
Priority: Minor
Currently a compont is more or less something which just groups UI elements. Tapestry should give components a chance to take full responsibility for all UI elements it contains including setup, validation and storage. On the one hand we can pre-set values (like setting checkbox aso) via setupRender by reading a domain model but there is no way to store the values because a component is not getting events from the form. There are several methods like custom bindings, ComponentAction or calling component methods from the form (page class) to come around this issue, but this just looks like workarounds.
In case components would provide optional methods for onValidate / onSuccess / onFailure (and become part of the form's events) it's possible to write standalone components which read a domain model and reflect changes to a domain model and even do cross checks between fields. This would increase component reusability to my personal opinion and create more solid units. Furthermore it easily allows handling of data which is not stored as simple attributes (eg bitfield which is mapped to multiple checkboxes and needs conversion in setupRender / onSuccess).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1618) Component events "onValidate /
onSuccess / onFailure"
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093908#comment-13093908 ]
Howard M. Lewis Ship commented on TAP5-1618:
--------------------------------------------
I've been thinking that the ComponentAction stuff could be deprecated, and replaced with a way of requesting event firings (with an optional context).
> Component events "onValidate / onSuccess / onFailure"
> -----------------------------------------------------
>
> Key: TAP5-1618
> URL: https://issues.apache.org/jira/browse/TAP5-1618
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-core
> Affects Versions: 5.3, 5.4
> Reporter: Jens Breitenstein
> Priority: Minor
> Labels: components, events
>
> Currently a compont is more or less something which just groups UI elements. Tapestry should give components a chance to take full responsibility for all UI elements it contains including setup, validation and storage. On the one hand we can pre-set values (like setting checkbox aso) via setupRender by reading a domain model but there is no way to store the values because a component is not getting events from the form. There are several methods like custom bindings, ComponentAction or calling component methods from the form (page class) to come around this issue, but this just looks like workarounds.
> In case components would provide optional methods for onValidate / onSuccess / onFailure (and become part of the form's events) it's possible to write standalone components which read a domain model and reflect changes to a domain model and even do cross checks between fields. This would increase component reusability to my personal opinion and create more solid units. Furthermore it easily allows handling of data which is not stored as simple attributes (eg bitfield which is mapped to multiple checkboxes and needs conversion in setupRender / onSuccess).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1618) Component events "onValidate /
onSuccess / onFailure"
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093908#comment-13093908 ]
Howard M. Lewis Ship commented on TAP5-1618:
--------------------------------------------
I've been thinking that the ComponentAction stuff could be deprecated, and replaced with a way of requesting event firings (with an optional context).
> Component events "onValidate / onSuccess / onFailure"
> -----------------------------------------------------
>
> Key: TAP5-1618
> URL: https://issues.apache.org/jira/browse/TAP5-1618
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-core
> Affects Versions: 5.3, 5.4
> Reporter: Jens Breitenstein
> Priority: Minor
> Labels: components, events
>
> Currently a compont is more or less something which just groups UI elements. Tapestry should give components a chance to take full responsibility for all UI elements it contains including setup, validation and storage. On the one hand we can pre-set values (like setting checkbox aso) via setupRender by reading a domain model but there is no way to store the values because a component is not getting events from the form. There are several methods like custom bindings, ComponentAction or calling component methods from the form (page class) to come around this issue, but this just looks like workarounds.
> In case components would provide optional methods for onValidate / onSuccess / onFailure (and become part of the form's events) it's possible to write standalone components which read a domain model and reflect changes to a domain model and even do cross checks between fields. This would increase component reusability to my personal opinion and create more solid units. Furthermore it easily allows handling of data which is not stored as simple attributes (eg bitfield which is mapped to multiple checkboxes and needs conversion in setupRender / onSuccess).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1618) Component events "onValidate /
onSuccess / onFailure"
Posted by "Geoff Callender (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093749#comment-13093749 ]
Geoff Callender commented on TAP5-1618:
---------------------------------------
Something similar has occurred to me. The whole business of writing and storing ComponentActions does my head in - it's plumbing, and for the most part Tapestry is very good at hiding plumbing, but not when it comes to input components.
It seems that the source of the problem is that events bubble up from Form, not down. Of course, that shouldn't change. But what if, behind the scenes, something like FormSupport could trigger events in each component within the Form? Even if onValidate / onSuccess / onFailure is not feasible, maybe we could have something like these:
onPrepareForSubmissionFromFormSupport() {..}
onProcessSubmissionFromFormSupport() {..}
Maybe it's not possible, because I note that some components conditionally store certain ComponentActions during render - maybe that decision to store can only be made in beforeRender() or afterRender(). Or maybe that could be solved by enabling the conditioning value to be stored by the rendering phase methods and retrieved by the event handling methods? One suggestion in the user mailing list is @Persist("Form").
> Component events "onValidate / onSuccess / onFailure"
> -----------------------------------------------------
>
> Key: TAP5-1618
> URL: https://issues.apache.org/jira/browse/TAP5-1618
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-core
> Affects Versions: 5.3, 5.4
> Reporter: Jens Breitenstein
> Priority: Minor
> Labels: components, events
>
> Currently a compont is more or less something which just groups UI elements. Tapestry should give components a chance to take full responsibility for all UI elements it contains including setup, validation and storage. On the one hand we can pre-set values (like setting checkbox aso) via setupRender by reading a domain model but there is no way to store the values because a component is not getting events from the form. There are several methods like custom bindings, ComponentAction or calling component methods from the form (page class) to come around this issue, but this just looks like workarounds.
> In case components would provide optional methods for onValidate / onSuccess / onFailure (and become part of the form's events) it's possible to write standalone components which read a domain model and reflect changes to a domain model and even do cross checks between fields. This would increase component reusability to my personal opinion and create more solid units. Furthermore it easily allows handling of data which is not stored as simple attributes (eg bitfield which is mapped to multiple checkboxes and needs conversion in setupRender / onSuccess).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1618) Component events "onValidate /
onSuccess / onFailure"
Posted by "Geoff Callender (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093749#comment-13093749 ]
Geoff Callender commented on TAP5-1618:
---------------------------------------
Something similar has occurred to me. The whole business of writing and storing ComponentActions does my head in - it's plumbing, and for the most part Tapestry is very good at hiding plumbing, but not when it comes to input components.
It seems that the source of the problem is that events bubble up from Form, not down. Of course, that shouldn't change. But what if, behind the scenes, something like FormSupport could trigger events in each component within the Form? Even if onValidate / onSuccess / onFailure is not feasible, maybe we could have something like these:
onPrepareForSubmissionFromFormSupport() {..}
onProcessSubmissionFromFormSupport() {..}
Maybe it's not possible, because I note that some components conditionally store certain ComponentActions during render - maybe that decision to store can only be made in beforeRender() or afterRender(). Or maybe that could be solved by enabling the conditioning value to be stored by the rendering phase methods and retrieved by the event handling methods? One suggestion in the user mailing list is @Persist("Form").
> Component events "onValidate / onSuccess / onFailure"
> -----------------------------------------------------
>
> Key: TAP5-1618
> URL: https://issues.apache.org/jira/browse/TAP5-1618
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-core
> Affects Versions: 5.3, 5.4
> Reporter: Jens Breitenstein
> Priority: Minor
> Labels: components, events
>
> Currently a compont is more or less something which just groups UI elements. Tapestry should give components a chance to take full responsibility for all UI elements it contains including setup, validation and storage. On the one hand we can pre-set values (like setting checkbox aso) via setupRender by reading a domain model but there is no way to store the values because a component is not getting events from the form. There are several methods like custom bindings, ComponentAction or calling component methods from the form (page class) to come around this issue, but this just looks like workarounds.
> In case components would provide optional methods for onValidate / onSuccess / onFailure (and become part of the form's events) it's possible to write standalone components which read a domain model and reflect changes to a domain model and even do cross checks between fields. This would increase component reusability to my personal opinion and create more solid units. Furthermore it easily allows handling of data which is not stored as simple attributes (eg bitfield which is mapped to multiple checkboxes and needs conversion in setupRender / onSuccess).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira