[
https://issues.apache.org/jira/browse/WICKET-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14510964#comment-14510964
]
Sven Meier commented on WICKET-5884:
------------------------------------
How reusable would these behaviors be? LogoutClickBehavior sound pretty
singular and ClickLogger can already be done with an IRequestCycleListener.
Wicket events are a great solution to certain problems, but IMHO not in such a
fine-granular manner.
> 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)
