[
https://issues.apache.org/jira/browse/WICKET-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14511164#comment-14511164
]
Tim Feurich commented on WICKET-5884:
-------------------------------------
@[~mgrigorov]
Using component specific Listeners instead should provide easier accessible
context information
(i.e. without having to typecheck and cast around first) and avoid unnecessary
broadcasting.
Yet the separation of component and component behavior would still be possible,
which was the main intention here.
@[~svenmeier]
The examples were probably not the best, as their reuseability shows only
across projects, and only provides a rather small gain.
An example closer to the codebase might be a decoupled "OrderBy" click
behavior/listener.
With this suggestion it would be possible to extract the behavior from the
Component.
It would allow the user to freely choose whether to add it to a {{Link}},
{{AjaxFallbackLink}}, {{Button}}, {{AjaxFallbackButton}},
{{InidicatingAjaxLink}}, {{IndicatingAjaxButton}}, {{IndicatingFallbackLink}}
(or any other clickable future components) instead of having to either use the
provided {{OrderByLink}}/{{AjaxFallbackOrderByLink}} or copy-paste the behavior
over to a custom e.g {{AjaxFallbackOrderByButton}}.
Businesslogic related actions might end up being bound to a link in one place
and a button in another. The current system would enforce different
implementations for every context despite the same/similar behavior,
multiplying component-subclasses, where they wouldn't need to.
> 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)
