Re: How to support multiple AbstractTransformerBehavior per component, if at all?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: How to support multiple AbstractTransformerBehavior per component, if at all?

Sven Meier
Hi Thorsten,

> changed implementation is simply reversing the order of how behaviours are called per component

the solution I was able to came up with: reverse the order of #afterRender() only!
This way callbacks to behaviors are 'nested', i.e. the first behavior has the first *and* last word on rendering -
something you can see in other frameworks/architectures too where resources are managed:

   behaviorA#beforeRender()
     behaviorB#beforeRender()
     behaviorB#afterRender()
   behaviorA#afterRender()

I agree with Martin that we shouldn't change this lightheartedly - it might break existing applications.
AbstractTransformerBehaviour is special and I don't know of any other behavior that needs this if more than one instance is added to a component.

You can just use a single behavior and let it manage a list of transformators.

+1 for changing this in Wicket 10
+0 for Wicket 9

Best regards
Sven
   

On 31.08.20 12:48, Thorsten Schöning wrote:

> Hi all,
>
> multiple instances of AbstractTransformerBehaviour on one component
> don't work properly currently. Reason is that all of those change
> response objects and are always executed in the order they were
> registered, which doesn't properly take the replaced responses into
> account. At some point, later registered and executed transformers
> replace the response with what they think is the original one, while
> it actually is a temporary one of former transformers as well.
>
> This behaviour can be tested with the attached quickstart by simply
> changing the following two lines. Details are documented in the linked
> JIRA-issue as well.
>
>> label.add(new FooTrans());
>> //label.add(new BarTrans());
> https://issues.apache.org/jira/browse/WICKET-6823
>
> This thread is about discussion whether or not to support multiple
> transformers per component at all, if so how and in which release of
> Wicket.
>
> One suggestion for a changed implementation is simply reversing the
> order of how behaviours are called per component. Another one is to
> change instead who manages the replaced responses how, e.g. by
> introducing some container-concept wrapping multiple transformers.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
Reply | Threaded
Open this post in threaded view
|

Re: How to support multiple AbstractTransformerBehavior per component, if at all?

Martin Grigorov-4
On Mon, Aug 31, 2020, 19:14 Sven Meier <[hidden email]> wrote:

> Hi Thorsten,
>
> > changed implementation is simply reversing the order of how behaviours
> are called per component
>
> the solution I was able to came up with: reverse the order of
> #afterRender() only!
> This way callbacks to behaviors are 'nested', i.e. the first behavior has
> the first *and* last word on rendering -
> something you can see in other frameworks/architectures too where
> resources are managed:
>
>    behaviorA#beforeRender()
>      behaviorB#beforeRender()
>      behaviorB#afterRender()
>    behaviorA#afterRender()
>
> I agree with Martin that we shouldn't change this lightheartedly - it
> might break existing applications.
> AbstractTransformerBehaviour is special and I don't know of any other
> behavior that needs this if more than one instance is added to a component.
>
> You can just use a single behavior and let it manage a list of
> transformators.
>
> +1 for changing this in Wicket 10
> +0 for Wicket 9
>

Same votes from me too


> Best regards
> Sven
>
>
> On 31.08.20 12:48, Thorsten Schöning wrote:
> > Hi all,
> >
> > multiple instances of AbstractTransformerBehaviour on one component
> > don't work properly currently. Reason is that all of those change
> > response objects and are always executed in the order they were
> > registered, which doesn't properly take the replaced responses into
> > account. At some point, later registered and executed transformers
> > replace the response with what they think is the original one, while
> > it actually is a temporary one of former transformers as well.
> >
> > This behaviour can be tested with the attached quickstart by simply
> > changing the following two lines. Details are documented in the linked
> > JIRA-issue as well.
> >
> >> label.add(new FooTrans());
> >> //label.add(new BarTrans());
> > https://issues.apache.org/jira/browse/WICKET-6823
> >
> > This thread is about discussion whether or not to support multiple
> > transformers per component at all, if so how and in which release of
> > Wicket.
> >
> > One suggestion for a changed implementation is simply reversing the
> > order of how behaviours are called per component. Another one is to
> > change instead who manages the replaced responses how, e.g. by
> > introducing some container-concept wrapping multiple transformers.
> >
> > Mit freundlichen Grüßen,
> >
> > Thorsten Schöning
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: How to support multiple AbstractTransformerBehavior per component, if at all?

Martin Grigorov-4
In reply to this post by Sven Meier
On Wed, Sep 2, 2020, 11:24 Thorsten Schöning <[hidden email]> wrote:

> Guten Tag Sven Meier,
> am Montag, 31. August 2020 um 18:13 schrieben Sie:
>
> > I agree with Martin that we shouldn't change this lightheartedly -
> > it might break existing applications.
>
> The order shouldn't be changed at all to circumvent a limitation of the
> implementation of one behaviour only.
>
> > AbstractTransformerBehaviour is special and I don't know of any
> > other behavior that needs this if more than one instance is added to a
> component.
>
> And that's the reason why that implementation should be changed.
>
> > You can just use a single behavior and let it manage a list of
> transformators.
>
> The question is if Wicket should do so in the long term implicitly, so
> that users don't need to care at all or explicitly by providing a
> container already. Otherwise all users need to implement their own,
> which doesn't seem to make too much sense. This perfectly well reads
> like infrastructure Wicket could provide and makes a good place to
> document the limitation I encountered at the same time.
>

No one else ever asked for this functionality for 10-15 years.
You are welcome to implement, document and contribute it!

>

> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning       E-Mail: [hidden email]
> AM-SoFT IT-Systeme      http://www.AM-SoFT.de/
>
> Telefon...........05151-  9468- 55
> Fax...............05151-  9468- 88
> Mobil..............0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
>
Reply | Threaded
Open this post in threaded view
|

Re: How to support multiple AbstractTransformerBehavior per component, if at all?

Martin Grigorov-4
On Fri, Sep 4, 2020 at 11:40 AM Thorsten Schöning <[hidden email]>
wrote:

> Guten Tag Martin Grigorov,
> am Donnerstag, 3. September 2020 um 21:06 schrieben Sie:
>
> > No one else ever asked for this functionality for 10-15 years.
> > You are welcome to implement, document and contribute it!
>
> That's why I asked: I most likely prefer an explicit container to add
> transformers to currently, something like "MultiAbstract[...]" or
> "[...]BehaviorMulti" or alike. That collects individual transformers
> and gets itself only added to the component.
>
> This the only easy way I see for a workaround in the version of Wicket
> I'm using and keeps existing transformers usable individually without
> any changes.
>

Take your time!
Experiment with few implementations and once you are happy with a solution
you can propose it with a Pull Request!


>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning       E-Mail: [hidden email]
> AM-SoFT IT-Systeme      http://www.AM-SoFT.de/
>
> Telefon...........05151-  9468- 55
> Fax...............05151-  9468- 88
> Mobil..............0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
>