[
https://issues.apache.org/jira/browse/WICKET-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Feurich updated WICKET-5884:
--------------------------------
Description:
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.
was:
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.
> 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)
