You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Thorsten Schöning <ts...@am-soft.de> on 2020/08/31 10:48:32 UTC
How to support multiple AbstractTransformerBehavior per component, if at all?
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
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
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
Re: How to support multiple AbstractTransformerBehavior per component, if at all?
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Thorsten Schöning,
am Freitag, 4. September 2020 um 10:40 schrieben Sie:
> 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.
I've created a container to work around the current limitation, which
is pretty easy overall and easily compatible with different versions
of Wicket. A corresponding PR is made, if it doesn't make it into the
project, simply copy&paste it into an individual class into your own
projects and use it.
https://github.com/apache/wicket/pull/457
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
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
Re: How to support multiple AbstractTransformerBehavior per
component, if at all?
Posted by Martin Grigorov <mg...@apache.org>.
On Fri, Sep 4, 2020 at 11:40 AM Thorsten Schöning <ts...@am-soft.de>
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: Thorsten.Schoening@AM-SoFT.de
> 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
>
>
Re: How to support multiple AbstractTransformerBehavior per component, if at all?
Posted by Thorsten Schöning <ts...@am-soft.de>.
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.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
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
Re: How to support multiple AbstractTransformerBehavior per
component, if at all?
Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Sep 2, 2020, 11:24 Thorsten Schöning <ts...@am-soft.de> 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: Thorsten.Schoening@AM-SoFT.de
> 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
>
>
Re: How to support multiple AbstractTransformerBehavior per component, if at all?
Posted by Thorsten Schöning <ts...@am-soft.de>.
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.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de
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
Re: How to support multiple AbstractTransformerBehavior per
component, if at all?
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Aug 31, 2020, 19:14 Sven Meier <sv...@meiers.net> 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
> >
>
Re: How to support multiple AbstractTransformerBehavior per
component, if at all?
Posted by Sven Meier <sv...@meiers.net>.
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
>