[
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
