You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Barry Books (JIRA)" <ji...@apache.org> on 2013/03/23 12:53:15 UTC

[jira] [Commented] (TAP5-1618) Component events "onValidate / onSuccess / onFailure"

    [ https://issues.apache.org/jira/browse/TAP5-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13611682#comment-13611682 ] 

Barry Books commented on TAP5-1618:
-----------------------------------

This would be a useful addition. The code needed to be a form field seems complicated and very unTapestry like. Just having events instead of ComponentActions would fix that.
                
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira