[
https://issues.apache.org/jira/browse/WICKET-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513972#comment-14513972
]
Martin Grigorov commented on WICKET-5884:
-----------------------------------------
I see what you mean. And I think I like it!
What bothers me that there is no easy/light way to switch this behavior off.
I don't want to do the broadcasts by default. I assume that most applications
will not use it..
Let's ask for more opinions at dev@.
> 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("addr...@example.org"))
> .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)
