On Mon, Aug 31, 2020, 19:14 Sven Meier <s...@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 > > >