[
https://issues.apache.org/jira/browse/WICKET-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14509744#comment-14509744
]
Martin Grigorov commented on WICKET-5884:
-----------------------------------------
In my experience usually the callback method (onClick(), onSubmit()) needs to
use some context information - the component model or any other component
state. With your suggestion this kind of information won't be available to the
behaviors that easy.
But if you prefer to use this style of coding then it is very easy to introduce
such broadcasting Form/Link.
I prefer to not add the broadcasting logic as default behavior in Form/Link
components because it will add to the used CPU time and I guess most of the
applications will not use the broadcasted events.
> Let Links, Buttons and Forms send Click and Submit Events
> ---------------------------------------------------------
>
> Key: WICKET-5884
> URL: https://issues.apache.org/jira/browse/WICKET-5884
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 7.0.0, 6.20.0
> Reporter: Tim Feurich
>
> h4. Links, Buttons
> Having the Link/Button components send click events to child {{IEventSinks}}
> would allow decoupling their behavior into {{Behaviors}} for reuse.
> This would also make their anonymous subclassing optional.
> {code:java}
> add(new Link<>("logout")
> .add(new LogoutClickBehavior())
> .add(new ClickLogger("authentication")));
> {code}
> Sending the events to the children probably would suffice, as a custom
> behavior could easily reroute the events to other destinations.
> {code:java}
> add(new Link<>("logout").add(EventPropagator.SESSION));
> {code}
> h4. Forms
> Form onSubmit events would allow {{Behaviors}} to contribute to the
> submission without forcing users to subclass forms for any number of tasks.
> {code:java}
> MailingStatelessContactForm.class
> DatabasePersistedContactForm.class
> XSDValidatingJAXBMarshallingAgainstXMLRantingContactForm.class
> {code}
> The decoupled behavior is quite a bit more flexible and reuseable compared to
> individual classes for every combination of usecases.
> {code:java}
> add(new ContactForm<>(id, model)
> //decoupled behavior, that can be made to work for any form
> .add(new FormMailBehavior("[email protected]"))
> .add(new DevFormDumper()));
> {code}
> Using listeners instead of the {{IEvent}} mechanism might be a viable
> alternative with a typesafty-flexibility tradeoff.
> Although there might be a naming conflict with {{IFormSubmitListener}}, which
> seems quite different in nature.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
