Re: Is it safe to use ComponentRenderer with different apps in the same thread one after another?
Hi Thorsten,
> As well I really only need to render within one and the same thread
> one after another,
that should work.
> is it safe to render recursively using ComponentRenderer within
> one and the same thread?
I assume you mean 'consecutively'? Yes, see above.
Have fun
Sven
On 29.03.20 15:45, Thorsten Schöning wrote:
Hi all,
I'm using Wicket as some render engine to render mails for reports
consisting of different individual render approaches: plain text only,
HTML only, a combination of both. In the latter case I of course would
like to simply reuse the former approaches, but am not sure if the
used ComponentRenderer does support that.
My individual rendering looks like the following:
private static String
forSome(VwrCtxctx,
Supplier page)
{
try (VwrCtxThreadScoped scopedCtx = new VwrCtxThreadScoped(ctx))
{
VwrHtmlApp app = new VwrHtmlApp();
ComponentRenderer renderer= new ComponentRenderer(app);
CharSequenceretVal = renderer.renderPage(page);
return retVal.toString();
}
}
"renderer.renderPage" is where I would call the above additionally to
provide text- and HTML-only. From my understanding that should be
safe, because ComponentRenderer supports multiple different contexts
for app etc.:
private T inThreadContext(Supplier supplier)
{
ThreadContext oldContext = ThreadContext.detach();
try
{
ThreadContext.setApplication(application);
return supplier.get();
}
finally
{
ThreadContext.restore(oldContext);
}
}
As well I really only need to render within one and the same thread
one after another, I'm not resuing apps or contexts between different
threads in parallel. If that would be needed at some point, it would
be dealt with at a higher level rendering using some threadpool.
So, is it safe to render recursively using ComponentRenderer within
one and the same thread? Thanks!
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
Is it safe to use ComponentRenderer with different apps in the same thread one after another?
Hi all,
I'm using Wicket as some render engine to render mails for reports
consisting of different individual render approaches: plain text only,
HTML only, a combination of both. In the latter case I of course would
like to simply reuse the former approaches, but am not sure if the
used ComponentRenderer does support that.
My individual rendering looks like the following:
> private static String
> forSome(VwrCtxctx,
> Supplier page)
> {
> try (VwrCtxThreadScoped scopedCtx = new VwrCtxThreadScoped(ctx))
> {
> VwrHtmlApp app = new VwrHtmlApp();
> ComponentRenderer renderer= new ComponentRenderer(app);
> CharSequenceretVal = renderer.renderPage(page);
>
> return retVal.toString();
> }
> }
"renderer.renderPage" is where I would call the above additionally to
provide text- and HTML-only. From my understanding that should be
safe, because ComponentRenderer supports multiple different contexts
for app etc.:
> private T inThreadContext(Supplier supplier)
> {
> ThreadContext oldContext = ThreadContext.detach();
>
> try
> {
> ThreadContext.setApplication(application);
>
> return supplier.get();
> }
> finally
> {
>
> ThreadContext.restore(oldContext);
> }
> }
As well I really only need to render within one and the same thread
one after another, I'm not resuing apps or contexts between different
threads in parallel. If that would be needed at some point, it would
be dealt with at a higher level rendering using some threadpool.
So, is it safe to render recursively using ComponentRenderer within
one and the same thread? Thanks!
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: IRequestCycleProvider and ComponentRenderer
https://issues.apache.org/jira/browse/WICKET-5574 Thanks for reporting! Martin Grigorov Wicket Training and Consulting On Tue, Apr 29, 2014 at 7:08 PM, Sven Ludwig wrote: > Hi, > > I noticed that ComponentRenderer is directly instantiating a concrete > RequestCycle while in the Application there is an abstract factory > mechanism based on IRequestCycleProvider. > > Could the flexibility of having a custom RequestCycle be provided for > ComponentRenderer as well? > > Kind Regards, > Sven > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
IRequestCycleProvider and ComponentRenderer
Hi, I noticed that ComponentRenderer is directly instantiating a concrete RequestCycle while in the Application there is an abstract factory mechanism based on IRequestCycleProvider. Could the flexibility of having a custom RequestCycle be provided for ComponentRenderer as well? Kind Regards, Sven - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ComponentRenderer
Hi, On Wed, Nov 27, 2013 at 2:57 AM, Colin Rogers < colin.rog...@objectconsulting.com.au> wrote: > Wicketeers, > > I have a problem when using ComponentRenderer in an actual live cycle. I > assume it's not actually intended for this use, and hence the errors, but > if I explain the issue, maybe someone can suggest an alternative or a > workaround. > > So... we have a set of 'pages' in a pageflow that update the main panel of > a page with each button click - effectively a Wizard - but using our own > component, rather than the standard one. Each step is updated via Ajax. > > Our requirement - as odd as it is, is... we have a bunch of steps. We then > eventually have a 'summary step'. For this step, we need to take a copy of > the HTML, and render it to PDF, so in the next step, we can download a PDF > version of the summary. The rendering of HTML to PDF is all fine, and > saving as a resource - that all fine, too. > > Basically - the error we end up with is an Ajax error - where the XML > response is malformed. A fresh copy of the component/panel is returned, > plus a second tag that has a random page redirect. It's this > second ajax response that is ultimately the issue. > > We've tried adding code to onConfigure(), onBeforeRender() or > onAfterRender() - we've also been cloneing the object (via WicketObjects) - > with extra code not to repeat the method, etc. > > I assume, because ComponentRenderer still uses the current 'live' response > object, that two responses are being given, and the browser is then > confused. > Your assumption is not correct. https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/core/util/string/ComponentRenderer.java?source=c#L59 https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/core/util/string/ComponentRenderer.java?source=c#L93 For both #renderPage() and #renderComponent() Wicket creates a temporary Response object for the rendering. There must be another issue. > > Is there anyway to either work round the issues above - using dummy > requests, or is there another way to get the generated HTML via page cache > or something else? I'm really open to any ideas! :) > > Cheers, > Col. > > > > > EMAIL DISCLAIMER This email message and its attachments are confidential > and may also contain copyright or privileged material. If you are not the > intended recipient, you may not forward the email or disclose or use the > information contained in it. If you have received this email message in > error, please advise the sender immediately by replying to this email and > delete the message and any associated attachments. Any views, opinions, > conclusions, advice or statements expressed in this email message are those > of the individual sender and should not be relied upon as the considered > view, opinion, conclusions, advice or statement of this company except > where the sender expressly, and with authority, states them to be the > considered view, opinion, conclusions, advice or statement of this company. > Every care is taken but we recommend that you scan any attachments for > viruses. >
ComponentRenderer
Wicketeers, I have a problem when using ComponentRenderer in an actual live cycle. I assume it's not actually intended for this use, and hence the errors, but if I explain the issue, maybe someone can suggest an alternative or a workaround. So... we have a set of 'pages' in a pageflow that update the main panel of a page with each button click - effectively a Wizard - but using our own component, rather than the standard one. Each step is updated via Ajax. Our requirement - as odd as it is, is... we have a bunch of steps. We then eventually have a 'summary step'. For this step, we need to take a copy of the HTML, and render it to PDF, so in the next step, we can download a PDF version of the summary. The rendering of HTML to PDF is all fine, and saving as a resource - that all fine, too. Basically - the error we end up with is an Ajax error - where the XML response is malformed. A fresh copy of the component/panel is returned, plus a second tag that has a random page redirect. It's this second ajax response that is ultimately the issue. We've tried adding code to onConfigure(), onBeforeRender() or onAfterRender() - we've also been cloneing the object (via WicketObjects) - with extra code not to repeat the method, etc. I assume, because ComponentRenderer still uses the current 'live' response object, that two responses are being given, and the browser is then confused. Is there anyway to either work round the issues above - using dummy requests, or is there another way to get the generated HTML via page cache or something else? I'm really open to any ideas! :) Cheers, Col. EMAIL DISCLAIMER This email message and its attachments are confidential and may also contain copyright or privileged material. If you are not the intended recipient, you may not forward the email or disclose or use the information contained in it. If you have received this email message in error, please advise the sender immediately by replying to this email and delete the message and any associated attachments. Any views, opinions, conclusions, advice or statements expressed in this email message are those of the individual sender and should not be relied upon as the considered view, opinion, conclusions, advice or statement of this company except where the sender expressly, and with authority, states them to be the considered view, opinion, conclusions, advice or statement of this company. Every care is taken but we recommend that you scan any attachments for viruses.
