You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Helmut Tammen <HT...@htsystemloesungen.de> on 2004/01/16 16:11:58 UTC
[Portal, Woody, PDF]: PDF Output in new window
I´ve developed a woody app that has some input fields on a form and a
"Print" button. Pressing the button leads to a pipeline that generates
PDF Output of the form fields.
This is o.k. as long as I run the woody application as standalone app.
When I run it as coplet in the portal the pdf-output is rendered as text
and displayed in the portal.
Is there a way to tell the pdf-pipeline generating the output in a new
window (javascript: window.open()) ?
Thanks Helmut
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
portal-roles-bug
Posted by wolfgang weigel <wg...@physik.uni-wuerzburg.de>.
Hi!
I have detected some strange behaviour in the portal-administration.
1. If you try to make a role-name with spaces like "Coach Football" it is
not possible to move, add or delete coplets in the administration view of
the role.
2. It is not possible to use "_" in role-names. If you do this this role
can not managed anymore.
3. If you try to use some german special characters in the roles name like
"Bcher" and you want to add some coplets and save them I get the following
exception:
The org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode
notifies that org.apache.cocoon.ProcessingException says:
Lookup of PortalManager failed.
More precisely:
org.apache.cocoon.ProcessingException: Lookup of PortalManager failed.:
org.apache.avalon.framework.component.ComponentException: Could not find
component
extra info
full exception chain stacktrace show
Original exception :
org.apache.avalon.framework.component.ComponentException: Could not find
component
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:255)
at
org.apache.cocoon.components.CocoonComponentManager.lookup(CocoonComponentManager.java:236)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory$ComponentManagerProxy.lookup(DefaultComponentFactory.java:393)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory$ComponentManagerProxy.lookup(DefaultComponentFactory.java:393)
at
org.apache.cocoon.webapps.portal.generation.PortalGenerator.generate(PortalGenerator.java:79)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:512)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:204)
.
.
.
and so on
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:534)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:530)
at java.lang.Thread.run(Thread.java:536)
has anbody detected the same errors? has anybody some solution for this
problem?
bye
wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [Portal, Woody, PDF]: PDF Output in new window
Posted by Helmut Tammen <HT...@htsystemloesungen.de>.
Joerg Heinicke schrieb:
> On 17.01.2004 15:08, Helmut Tammen wrote:
>
>>>> I´ve developed a woody app that has some input fields on a form and
>>>> a "Print" button. Pressing the button leads to a pipeline that
>>>> generates PDF Output of the form fields.
>>>> This is o.k. as long as I run the woody application as standalone
>>>> app. When I run it as coplet in the portal the pdf-output is
>>>> rendered as text and displayed in the portal.
>>>
>>>
>>> If it's rendered as text something else is wrong (wrong mime-type for
>>> example).
>>>
>>>> Is there a way to tell the pdf-pipeline generating the output in a
>>>> new window (javascript: window.open()) ?
>>>
>>>
>>> If the print button submits the form you just have to adapt the
>>> target of the form:
>>> http://selfhtml.teamone.de/html/formulare/definieren.htm#zielfenster
>>> (@target on the form element). Woody supports this in the default
>>> styles by copying all attributes from wi:form-template, i.e. just add
>>> it to your from template wt:form-template.
>>>
>>> A bit more complicated is the window.open() version as you have to
>>> collect the form values yourself and it's not needed I think.
>>>
>>> Joerg
>>
>>
>>
>> I have to go a bit more into detail, I think.
>>
>> Beside the input fields and the print-button there are also some more
>> buttons at the form. These should not lead to a new window. They send
>> the request to the portal resp. the actual continuation.
>> <wt:form-template action="portal" method="POST">
>> Even the print-event should first go back to the continuation
>> (flowscript) because the data of the input fields are first
>> interpreted and the resulting data for the PDF is generated and saved
>> as {continuation.id}.xml. After that has been done I call
>> cocoon.sendPageAndWait(continuation.id + "-print-pipeline", {} );
>> to print the data (generate the PDF).
>> My print-pipeline looks like that:
>> <map:match pattern="*-print-pipeline">
>> <map:generate src="tmp/{1}.xml"/>
>> <map:transform src="xsl/dienstreisen_fop.xsl"/>
>> <map:serialize type="fo2pdf"/>
>> </map:match>
>> It´s generating text output when using it in the portal. Otherwise PDF
>> is generated.
>
>
> So it's just a client side issue. You can't determine and influence the
> window the response is shown in from server side. One way I can imagine
> is to set the target just before submitting the form. But I don't know
> if there are hooks to add client side javascripts in Woody or if you
> have to do it by hand.
>
> Joerg
Thanks Joerg,
in the meantime I´ve also found the client side solution.
Helmut
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [Portal, Woody, PDF]: PDF Output in new window
Posted by Joerg Heinicke <jo...@gmx.de>.
On 17.01.2004 15:08, Helmut Tammen wrote:
>>> I´ve developed a woody app that has some input fields on a form and a
>>> "Print" button. Pressing the button leads to a pipeline that
>>> generates PDF Output of the form fields.
>>> This is o.k. as long as I run the woody application as standalone
>>> app. When I run it as coplet in the portal the pdf-output is rendered
>>> as text and displayed in the portal.
>>
>> If it's rendered as text something else is wrong (wrong mime-type for
>> example).
>>
>>> Is there a way to tell the pdf-pipeline generating the output in a
>>> new window (javascript: window.open()) ?
>>
>> If the print button submits the form you just have to adapt the target
>> of the form:
>> http://selfhtml.teamone.de/html/formulare/definieren.htm#zielfenster
>> (@target on the form element). Woody supports this in the default
>> styles by copying all attributes from wi:form-template, i.e. just add
>> it to your from template wt:form-template.
>>
>> A bit more complicated is the window.open() version as you have to
>> collect the form values yourself and it's not needed I think.
>>
>> Joerg
>
>
> I have to go a bit more into detail, I think.
>
> Beside the input fields and the print-button there are also some more
> buttons at the form. These should not lead to a new window. They send
> the request to the portal resp. the actual continuation.
> <wt:form-template action="portal" method="POST">
> Even the print-event should first go back to the continuation
> (flowscript) because the data of the input fields are first interpreted
> and the resulting data for the PDF is generated and saved as
> {continuation.id}.xml. After that has been done I call
> cocoon.sendPageAndWait(continuation.id + "-print-pipeline", {} );
> to print the data (generate the PDF).
> My print-pipeline looks like that:
> <map:match pattern="*-print-pipeline">
> <map:generate src="tmp/{1}.xml"/>
> <map:transform src="xsl/dienstreisen_fop.xsl"/>
> <map:serialize type="fo2pdf"/>
> </map:match>
> It´s generating text output when using it in the portal. Otherwise PDF
> is generated.
So it's just a client side issue. You can't determine and influence the
window the response is shown in from server side. One way I can imagine
is to set the target just before submitting the form. But I don't know
if there are hooks to add client side javascripts in Woody or if you
have to do it by hand.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [Portal, Woody, PDF]: PDF Output in new window
Posted by Helmut Tammen <HT...@htsystemloesungen.de>.
Joerg Heinicke schrieb:
> On 16.01.2004 16:11, Helmut Tammen wrote:
>
>> I´ve developed a woody app that has some input fields on a form and a
>> "Print" button. Pressing the button leads to a pipeline that generates
>> PDF Output of the form fields.
>> This is o.k. as long as I run the woody application as standalone app.
>> When I run it as coplet in the portal the pdf-output is rendered as
>> text and displayed in the portal.
>
>
> If it's rendered as text something else is wrong (wrong mime-type for
> example).
>
>> Is there a way to tell the pdf-pipeline generating the output in a new
>> window (javascript: window.open()) ?
>
>
> If the print button submits the form you just have to adapt the target
> of the form:
> http://selfhtml.teamone.de/html/formulare/definieren.htm#zielfenster
> (@target on the form element). Woody supports this in the default styles
> by copying all attributes from wi:form-template, i.e. just add it to
> your from template wt:form-template.
>
> A bit more complicated is the window.open() version as you have to
> collect the form values yourself and it's not needed I think.
>
> Joerg
I have to go a bit more into detail, I think.
Beside the input fields and the print-button there are also some more
buttons at the form. These should not lead to a new window. They send
the request to the portal resp. the actual continuation.
<wt:form-template action="portal" method="POST">
Even the print-event should first go back to the continuation
(flowscript) because the data of the input fields are first interpreted
and the resulting data for the PDF is generated and saved as
{continuation.id}.xml. After that has been done I call
cocoon.sendPageAndWait(continuation.id + "-print-pipeline", {} );
to print the data (generate the PDF).
My print-pipeline looks like that:
<map:match pattern="*-print-pipeline">
<map:generate src="tmp/{1}.xml"/>
<map:transform src="xsl/dienstreisen_fop.xsl"/>
<map:serialize type="fo2pdf"/>
</map:match>
It´s generating text output when using it in the portal. Otherwise PDF
is generated.
Helmut
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [Portal, Woody, PDF]: PDF Output in new window
Posted by Joerg Heinicke <jo...@gmx.de>.
On 16.01.2004 16:11, Helmut Tammen wrote:
> I´ve developed a woody app that has some input fields on a form and a
> "Print" button. Pressing the button leads to a pipeline that generates
> PDF Output of the form fields.
> This is o.k. as long as I run the woody application as standalone app.
> When I run it as coplet in the portal the pdf-output is rendered as text
> and displayed in the portal.
If it's rendered as text something else is wrong (wrong mime-type for
example).
> Is there a way to tell the pdf-pipeline generating the output in a new
> window (javascript: window.open()) ?
If the print button submits the form you just have to adapt the target
of the form:
http://selfhtml.teamone.de/html/formulare/definieren.htm#zielfenster
(@target on the form element). Woody supports this in the default styles
by copying all attributes from wi:form-template, i.e. just add it to
your from template wt:form-template.
A bit more complicated is the window.open() version as you have to
collect the form values yourself and it's not needed I think.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org