Re: AbstractTransformerBehavior prevents further rendering.
Hi Thorsten, >Is that a special restriction for transformers only? transformers do something very special, they temporarily replace the response: https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/markup/transformer/AbstractTransformerBehavior.java I haven't tried it, but using two of these seems not to work. I never seen the need for this though. Have fun Sven On 18.08.20 14:38, Thorsten Schöning wrote: Guten Tag Sven Meier, am Dienstag, 18. August 2020 um 08:50 schrieben Sie: sorry I missed that: on first sight it seems to work with a single transformer only. Is that a special restriction for transformers only? Because behaviours in general seem to be looped through when rendering components. Doesn't it make more sense to support multiple transformers as well? Need to decide if I try to fix the underlying root cause or implement a workaround. Combing my transformers isn't that easy, they are totally unrelated in theory and are used individually already. Mit freundlichen Grüßen, Thorsten Schöning - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AbstractTransformerBehavior prevents further rendering.
Guten Tag Sven Meier, am Dienstag, 18. August 2020 um 08:50 schrieben Sie: > sorry I missed that: on first sight it seems to work with a single > transformer only. Is that a special restriction for transformers only? Because behaviours in general seem to be looped through when rendering components. Doesn't it make more sense to support multiple transformers as well? Need to decide if I try to fix the underlying root cause or implement a workaround. Combing my transformers isn't that easy, they are totally unrelated in theory and are used individually already. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AbstractTransformerBehavior prevents further rendering.
Hi, sorry I missed that: on first sight it seems to work with a single transformer only. Better you combined both your behaviors into one. Have fun Sven On 18.08.20 08:11, Thorsten Schöning wrote: Guten Tag Sven Meier, am Montag, 17. August 2020 um 20:34 schrieben Sie: please create a quickstart, without debugging I cannot pinpoint the problem. Will try to have a look at this later. In general, should multiple of my behaviours on the same component work? Do you know of any tests in place already making sure this works? Because in my setup the problem happens when executed using WicketTester, which might make a difference to normal rendering as well. Mit freundlichen Grüßen, Thorsten Schöning - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AbstractTransformerBehavior prevents further rendering.
Guten Tag Sven Meier, am Montag, 17. August 2020 um 20:34 schrieben Sie: > please create a quickstart, without debugging I cannot pinpoint the problem. Will try to have a look at this later. In general, should multiple of my behaviours on the same component work? Do you know of any tests in place already making sure this works? Because in my setup the problem happens when executed using WicketTester, which might make a difference to normal rendering as well. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AbstractTransformerBehavior prevents further rendering.
Hi Thorsten,
please create a quickstart, without debugging I cannot pinpoint the problem.
Have fun
Sven
On 17.08.20 19:52, Thorsten Schöning wrote:
Hi all,
I'm using Wicket as a renderer for HTML-reports WITHOUT browser, web
server or requests, only by using ComponentRenderer. There are two
implementations of AbstractTransformerBehavior to update "colspan"
attributes of table cells and IDs of arbitrary HTML nodes. Both are
used on the same component:
resultsCont.add(new DvResultsCont.ColSpanUpdater());
resultsCont.add(new MkIdReplacer
(
"th", "id", "td", "headers",
String.format("%d.%s", itemIdx, kindOfDetail)
));
When only ONE of both behaviours is used, the page renders
successfully and it doesn't make any difference which one is used. If
both of those are used OTOH, the page stops rendering after the markup
of the component "resultsCont". That component renders to a table, so
the last markup I have is the following:
[...]
In theory, after that table there should be additional content like
foots, closing elements for HTML itself etc. So the current rendering
is invalid. It's important to note, though, that I don't get any
exception, things seems to simply stop. When enabling DEBUG logging
during rendering, the logs make pretty much clear that Wicket really
tries to continue rendering, but the output is simply missing.
It might be of interest that the resulting HTML is somewhat large,
around 1,7 MiB. Though I didn't find any hard-coded limits in the
behaviours yet in that direction.
As no exceptions are thrown and output seems to simply be ignored at
some point, I have the feeling the problem is in handling the response
objects in "AbstractTransformerBehavior.afterRender". But I couldn't
find anything problematic during debugging yet and things seem to work
with only one behaviour applied.
Do you have any idea what might go wrong? Is there any size limit with
behaviours or when rendering at all? Is it generally OK to place
multiple behaviours onto one and the same component?
Thanks for your ideas!
Mit freundlichen Grüßen,
Thorsten Schöning
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
AbstractTransformerBehavior prevents further rendering.
Hi all,
I'm using Wicket as a renderer for HTML-reports WITHOUT browser, web
server or requests, only by using ComponentRenderer. There are two
implementations of AbstractTransformerBehavior to update "colspan"
attributes of table cells and IDs of arbitrary HTML nodes. Both are
used on the same component:
> resultsCont.add(new DvResultsCont.ColSpanUpdater());
> resultsCont.add(new MkIdReplacer
> (
> "th", "id", "td", "headers",
> String.format("%d.%s", itemIdx, kindOfDetail)
> ));
When only ONE of both behaviours is used, the page renders
successfully and it doesn't make any difference which one is used. If
both of those are used OTOH, the page stops rendering after the markup
of the component "resultsCont". That component renders to a table, so
the last markup I have is the following:
>
> [...]
>
In theory, after that table there should be additional content like
foots, closing elements for HTML itself etc. So the current rendering
is invalid. It's important to note, though, that I don't get any
exception, things seems to simply stop. When enabling DEBUG logging
during rendering, the logs make pretty much clear that Wicket really
tries to continue rendering, but the output is simply missing.
It might be of interest that the resulting HTML is somewhat large,
around 1,7 MiB. Though I didn't find any hard-coded limits in the
behaviours yet in that direction.
As no exceptions are thrown and output seems to simply be ignored at
some point, I have the feeling the problem is in handling the response
objects in "AbstractTransformerBehavior.afterRender". But I couldn't
find anything problematic during debugging yet and things seem to work
with only one behaviour applied.
Do you have any idea what might go wrong? Is there any size limit with
behaviours or when rendering at all? Is it generally OK to place
multiple behaviours onto one and the same component?
Thanks for your ideas!
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: thorsten.schoen...@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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
