Hi Sven,

Maybe I didn't understand your idea with the interfaces.
wicket-core components should instantiate the payload and broadcast it.
How something implemented by the application will be instantiated by Wicket?

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Tue, Apr 28, 2015 at 2:56 PM, Martin Grigorov <[email protected]>
wrote:

> Hi Sven,
>
> The only problem I see with the interfaces approach is that it won't be
> easy to extend them with extra functionality in a minor release if this is
> ever needed.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Apr 28, 2015 at 12:47 PM, Sven Meier <[email protected]> wrote:
>
>> Hi Martin,
>>
>> why not just define interfaces in Components, and allow behaviors to
>> implement these?
>> Not that I'm convinced of the usefulness of this feature :P.
>>
>> Regards
>> Sven
>>
>>
>>
>> On 28.04.2015 11:23, Martin Grigorov wrote:
>>
>>> Hi Sven,
>>>
>>> I imagine them as inner static classes in AbstractLink, Button and Form
>>> classes.
>>> AjaxRequestTarget will be an optional property for the event payload.
>>> I.e.
>>> AjaxButton will set it, Button will leave it null.
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Tue, Apr 28, 2015 at 12:11 PM, Sven Meier <[email protected]> wrote:
>>>
>>>  Hi,
>>>>
>>>> how (where) will these events (=payloads?) be defined?
>>>>
>>>> Sven
>>>>
>>>>
>>>> On 28.04.2015 08:29, Martin Grigorov wrote:
>>>>
>>>>  Hi Dan,
>>>>>
>>>>> On Mon, Apr 27, 2015 at 4:21 PM, Dan Haywood <
>>>>> [email protected]>
>>>>> wrote:
>>>>>
>>>>>   Sounds a bit similar to Apache Isis' support for domain events
>>>>> (albeit
>>>>>
>>>>>> at a
>>>>>> higher level of abstraction).
>>>>>>
>>>>>> we've found that feature very useful, so I would imagine there would
>>>>>> be
>>>>>> benefits from implementing this lower more general support in Wicket.
>>>>>>
>>>>>>   Thanks for sharing your experience!
>>>>>>
>>>>>
>>>>>   You could also perhaps submit events for the validation (allowing
>>>>>
>>>>>> subscribers to veto changes).
>>>>>>
>>>>>>   IMO there is no need to do this for validation.
>>>>>>
>>>>> Currently when an IValidator is added to a FormComponent it is
>>>>> automatically wrapped in a Behavior [1].
>>>>> So Wicket will use the typesafer IValidator#validate(IValidatable)
>>>>> instead
>>>>> of Behavior#onEvent(IEvent)
>>>>>
>>>>>
>>>>> 1.
>>>>>
>>>>>
>>>>> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/markup/html/form/FormComponent.java#L515
>>>>>
>>>>>
>>>>>   Cheers
>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 27 April 2015 at 13:13, Martin Grigorov <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>   Hi,
>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/WICKET-5884 suggest an
>>>>>>> interesting
>>>>>>> feature:
>>>>>>>
>>>>>>> All links/buttons/forms to broadcast Wicket events to their Behaviors
>>>>>>>
>>>>>>>  about
>>>>>>
>>>>>>  the event.
>>>>>>> I.e. a Link/Button will tell all its Behaviors that it has been
>>>>>>> clicked,
>>>>>>>
>>>>>>>  a
>>>>>>
>>>>>>  Form will tell that it has been submitted.
>>>>>>> The broadcast would be with type EXACT so only the current component
>>>>>>> and
>>>>>>> its behaviors will be notified via #onEvent().
>>>>>>> This way the application developer can reuse functionality that
>>>>>>> should
>>>>>>> be
>>>>>>> executed for several links/submitters.
>>>>>>>
>>>>>>> While I see how this could be useful for some applications I also see
>>>>>>>
>>>>>>>  that
>>>>>>
>>>>>>  it will add to the processing time for all applications no matter
>>>>>>> whether
>>>>>>> they use the feature or not.
>>>>>>>
>>>>>>> Also I guess some user will ask for OnBeforeButtonSubmitEvent +
>>>>>>> OnAfterButtonSubmitEvent (same for Link and Form) so the extra
>>>>>>> processing
>>>>>>> time be doubled.
>>>>>>>
>>>>>>> What do you think about the feature?
>>>>>>>
>>>>>>> Martin Grigorov
>>>>>>> Wicket Training and Consulting
>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>
>>>>>>>
>>>>>>>
>>
>

Reply via email to