You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by "Yan, Charlene" <Ch...@thomsonlearning.com> on 2003/05/02 17:09:34 UTC
cocoon + struts
All,
I am working on creating reports in RTF and Excel formats. Our app is built with struts 1.1. We have XML format created using bitwix on the fly and we can either save it as a file or display it in a browser. My question is how difficult it is to marry cocoon with struts in this case. Any insights and help would be greatly appreciated!
Thanks,
Charlene
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: cocoon + struts
Posted by I-Shen Leong <is...@pwrsrc.net>.
> I am working on creating reports in RTF and Excel formats. Our app is
> built with struts 1.1. We have XML format created using bitwix on the
> fly and we can either save it as a file or display it in a browser. My
> question is how difficult it is to marry cocoon with struts in this
> case. Any insights and help would be greatly appreciated!
I've never tried it myself, but someone posted this link a while back:
http://www.twdata.org/struts/
It's also against Jakarta policy to cross post messages to multiple lists
btw.
I-Shen
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: cocoon + struts
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Milo Hyson wrote:
> Ryan Hoegg wrote:
>
>> Yes, I think writing a Generator is just the next incarnation of this
>> very approach. Whatever logic you are implementing in your XSP that
>> knows how to turn a request + session + context into XML might be
>> first refactored into logicsheets and then rewritten as a Generator
>> or Transformer. In fact, the RequestGenerator does half of this for
>> you out of the box.
>>
>> I am curious how you are leveraging struts in this case. If I assume
>> correctly, your Struts Actions are placing information in the session
>> for the XSP to pick up, correct? And at that point, an ActionForward
>> sends the browser to a particular URL that Cocoon picks up?
>
> Basically, yes. However, not all information is placed in the session.
> As I mentioned in the last post, using the session for exchanging data
> isn't necessarily the best thing, since much of the data is only
> needed during the request and thus has no business being in the session.
Sure, so the RequestGenerator with a custom Transformer sounds like a
viable approach.
>> In that case, I suggest you edit web.xml so that the Cocoon servlet
>> maps to /View/ or something similar, and then add a servlet mapping
>> for your Struts servlet as well.
>
> That is exactly what I'm doing, but I'm running into a bit of trouble
> trying to get Cocoon to behave. It's complaining about a malformed URL
> apparently in the logging config. Any insights?
>
> Logging Error: Could not set up Cocoon Logger, will use screen instead
> java.net.MalformedURLException
> at java.net.URL.<init>(URL.java:613)
> at java.net.URL.<init>(URL.java:476)
> at java.net.URL.<init>(URL.java:425)
> at
> org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown
> Source)
> at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLEntityManager.startDocumentEntity(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentScannerImpl.setInputSource(Unknown
> Source)
> at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
> Source)
> at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
> Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> Source)
> at
> org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.build(DefaultConfigurationBuilder.java:223)
>
> at
> org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.build(DefaultConfigurationBuilder.java:192)
>
> at
> org.apache.cocoon.servlet.CocoonServlet.initLogger(CocoonServlet.java:812)
>
> at
> org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:269)
> at
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:935)
>
> at
> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:823)
> at
> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3420)
>
> at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:3608)
> at
> org.apache.catalina.startup.HostConfig.checkWebXmlLastModified(HostConfig.java:614)
>
> at org.apache.catalina.startup.HostConfig.run(HostConfig.java:854)
> at java.lang.Thread.run(Thread.java:536)
Well I took a look at the CocoonServlet.initLogger() method, and it
looks like it is failing while trying to feed /WEB-INF/logkit.xconf to
the DefaultConfigurationBuilder with a MalformedURLException. In
logkit.xconf, it is specifying filenames using properties that look like
ant properties, namely ${context-root}. Also, in initLogger I see it
calling DefaultLogKitManager.contextualize() with a DefaultContext() on
which it has already put a value for "context-root". My guess is that
somehow this isn't parsing into a valid path on your system.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: cocoon + struts
Posted by Milo Hyson <mi...@cyberlifelabs.com>.
Ryan Hoegg wrote:
> Milo Hyson wrote:
>
>> Ryan Hoegg wrote:
>>
>>> Milo Hyson wrote:
>>>
>>>> Bertrand Delacretaz wrote:
>>>>
>>>> The only problem with this approach is that it puts Cocoon in
>>>> control -- Cocoon receives the initial browser request and
>>>> "proxies" to the Struts app for content. It also requires the
>>>> Struts app to output all data in XML, effectively coupling it to a
>>>> particular form of presentation. In the thread "Using Cocoon
>>>> exclusively for the V in MVC" I've been discussing the use of
>>>> Cocoon purely as a presentation engine in a Struts application. I
>>>> think that is a more flexible method since it does not tie your app
>>>> down to any single way of doing things.
>>>
>>>
>>> In my view, if Struts is not outputting XML then you have to create
>>> a custom Generator that converts the output to XML. StrutsCX either
>>> expects XML or expect a standard input format that it then converts
>>> to XML (an ArrayList of JavaBeans). So, if you want to use Cocoon
>>> as a View layer, you have to give it /some/ standard input format,
>>> and then use a Generator.
>>
>>
>> The approach I've been working on is just pulling in the necessary
>> context/session/request data from the app via XSP and processing it
>> through the pipeline that way. Essentially, the idea is to use Cocoon
>> as a straightforward replacement for JSPs.
>
>
> Yes, I think writing a Generator is just the next incarnation of this
> very approach. Whatever logic you are implementing in your XSP that
> knows how to turn a request + session + context into XML might be
> first refactored into logicsheets and then rewritten as a Generator or
> Transformer. In fact, the RequestGenerator does half of this for you
> out of the box.
>
> I am curious how you are leveraging struts in this case. If I assume
> correctly, your Struts Actions are placing information in the session
> for the XSP to pick up, correct? And at that point, an ActionForward
> sends the browser to a particular URL that Cocoon picks up?
Basically, yes. However, not all information is placed in the session.
As I mentioned in the last post, using the session for exchanging data
isn't necessarily the best thing, since much of the data is only needed
during the request and thus has no business being in the session.
>>> To architect the solution, have you considered using a separate
>>> webapp altogether? Struts could then forward to a view in a
>>> different context, which would be handled by the Cocoon servlet.
>>
>>
>> Using a separate context defeats the notion of a single, cohesive
>> application. It also interferes with the use of the application's
>> context and request data in the presentation. It has been suggested
>> to use session attributes to pass data between two contexts, but that
>> has its own problems. For one, it's a crude hack since you're putting
>> non-session-scoped data in a session purely to overcome a technical
>> limitation.
>
>
> In that case, I suggest you edit web.xml so that the Cocoon servlet
> maps to /View/ or something similar, and then add a servlet mapping
> for your Struts servlet as well.
That is exactly what I'm doing, but I'm running into a bit of trouble
trying to get Cocoon to behave. It's complaining about a malformed URL
apparently in the logging config. Any insights?
Logging Error: Could not set up Cocoon Logger, will use screen instead
java.net.MalformedURLException
at java.net.URL.<init>(URL.java:613)
at java.net.URL.<init>(URL.java:476)
at java.net.URL.<init>(URL.java:425)
at
org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown
Source)
at
org.apache.xerces.impl.XMLEntityManager.startDocumentEntity(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentScannerImpl.setInputSource(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at
org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.build(DefaultConfigurationBuilder.java:223)
at
org.apache.avalon.framework.configuration.DefaultConfigurationBuilder.build(DefaultConfigurationBuilder.java:192)
at
org.apache.cocoon.servlet.CocoonServlet.initLogger(CocoonServlet.java:812)
at
org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:269)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:935)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:823)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3420)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3608)
at
org.apache.catalina.startup.HostConfig.checkWebXmlLastModified(HostConfig.java:614)
at org.apache.catalina.startup.HostConfig.run(HostConfig.java:854)
at java.lang.Thread.run(Thread.java:536)
--
Milo Hyson
CyberLife Labs
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: cocoon + struts
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Milo Hyson wrote:
> Ryan Hoegg wrote:
>
>> Milo Hyson wrote:
>>
>>> Bertrand Delacretaz wrote:
>>>
>>> The only problem with this approach is that it puts Cocoon in
>>> control -- Cocoon receives the initial browser request and "proxies"
>>> to the Struts app for content. It also requires the Struts app to
>>> output all data in XML, effectively coupling it to a particular form
>>> of presentation. In the thread "Using Cocoon exclusively for the V
>>> in MVC" I've been discussing the use of Cocoon purely as a
>>> presentation engine in a Struts application. I think that is a more
>>> flexible method since it does not tie your app down to any single
>>> way of doing things.
>>
>> In my view, if Struts is not outputting XML then you have to create a
>> custom Generator that converts the output to XML. StrutsCX either
>> expects XML or expect a standard input format that it then converts
>> to XML (an ArrayList of JavaBeans). So, if you want to use Cocoon as
>> a View layer, you have to give it /some/ standard input format, and
>> then use a Generator.
>
> The approach I've been working on is just pulling in the necessary
> context/session/request data from the app via XSP and processing it
> through the pipeline that way. Essentially, the idea is to use Cocoon
> as a straightforward replacement for JSPs.
Yes, I think writing a Generator is just the next incarnation of this
very approach. Whatever logic you are implementing in your XSP that
knows how to turn a request + session + context into XML might be first
refactored into logicsheets and then rewritten as a Generator or
Transformer. In fact, the RequestGenerator does half of this for you
out of the box.
I am curious how you are leveraging struts in this case. If I assume
correctly, your Struts Actions are placing information in the session
for the XSP to pick up, correct? And at that point, an ActionForward
sends the browser to a particular URL that Cocoon picks up?
>> To architect the solution, have you considered using a separate
>> webapp altogether? Struts could then forward to a view in a
>> different context, which would be handled by the Cocoon servlet.
>
> Using a separate context defeats the notion of a single, cohesive
> application. It also interferes with the use of the application's
> context and request data in the presentation. It has been suggested to
> use session attributes to pass data between two contexts, but that has
> its own problems. For one, it's a crude hack since you're putting
> non-session-scoped data in a session purely to overcome a technical
> limitation.
In that case, I suggest you edit web.xml so that the Cocoon servlet maps
to /View/ or something similar, and then add a servlet mapping for your
Struts servlet as well.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: cocoon + struts
Posted by Milo Hyson <mi...@cyberlifelabs.com>.
Ryan Hoegg wrote:
> Milo Hyson wrote:
>
>> Bertrand Delacretaz wrote:
>>
>> The only problem with this approach is that it puts Cocoon in control
>> -- Cocoon receives the initial browser request and "proxies" to the
>> Struts app for content. It also requires the Struts app to output all
>> data in XML, effectively coupling it to a particular form of
>> presentation. In the thread "Using Cocoon exclusively for the V in
>> MVC" I've been discussing the use of Cocoon purely as a presentation
>> engine in a Struts application. I think that is a more flexible
>> method since it does not tie your app down to any single way of doing
>> things.
>
>
> In my view, if Struts is not outputting XML then you have to create a
> custom Generator that converts the output to XML. StrutsCX either
> expects XML or expect a standard input format that it then converts to
> XML (an ArrayList of JavaBeans). So, if you want to use Cocoon as a
> View layer, you have to give it /some/ standard input format, and then
> use a Generator.
The approach I've been working on is just pulling in the necessary
context/session/request data from the app via XSP and processing it
through the pipeline that way. Essentially, the idea is to use Cocoon as
a straightforward replacement for JSPs.
> To architect the solution, have you considered using a separate webapp
> altogether? Struts could then forward to a view in a different
> context, which would be handled by the Cocoon servlet.
Using a separate context defeats the notion of a single, cohesive
application. It also interferes with the use of the application's
context and request data in the presentation. It has been suggested to
use session attributes to pass data between two contexts, but that has
its own problems. For one, it's a crude hack since you're putting
non-session-scoped data in a session purely to overcome a technical
limitation.
--
Milo Hyson
CyberLife Labs
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: cocoon + struts
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Milo Hyson wrote:
> Bertrand Delacretaz wrote:
>
> The only problem with this approach is that it puts Cocoon in control
> -- Cocoon receives the initial browser request and "proxies" to the
> Struts app for content. It also requires the Struts app to output all
> data in XML, effectively coupling it to a particular form of
> presentation. In the thread "Using Cocoon exclusively for the V in
> MVC" I've been discussing the use of Cocoon purely as a presentation
> engine in a Struts application. I think that is a more flexible method
> since it does not tie your app down to any single way of doing things.
In my view, if Struts is not outputting XML then you have to create a
custom Generator that converts the output to XML. StrutsCX either
expects XML or expect a standard input format that it then converts to
XML (an ArrayList of JavaBeans). So, if you want to use Cocoon as a
View layer, you have to give it /some/ standard input format, and then
use a Generator.
To architect the solution, have you considered using a separate webapp
altogether? Struts could then forward to a view in a different context,
which would be handled by the Cocoon servlet.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: cocoon + struts
Posted by Milo Hyson <mi...@cyberlifelabs.com>.
Bertrand Delacretaz wrote:
> Le Vendredi, 2 mai 2003, à 17:09 Europe/Zurich, Yan, Charlene a écrit :
>
>> ...My question is how difficult it is to marry cocoon with struts in
>> this case.
>
>
> If cocoon can do an HTTP request to your application and receive XML
> data, it is very easy to use it as a front-end to generate other
> formats from this XML. The Cocoon FileGenerator can read XML directly
> from any URL.
>
> For an example see "Dynamic XML data" in
> http://xml.apache.org/cocoon/howto/howto-html-pdf-publishing.html
The only problem with this approach is that it puts Cocoon in control --
Cocoon receives the initial browser request and "proxies" to the Struts
app for content. It also requires the Struts app to output all data in
XML, effectively coupling it to a particular form of presentation. In
the thread "Using Cocoon exclusively for the V in MVC" I've been
discussing the use of Cocoon purely as a presentation engine in a Struts
application. I think that is a more flexible method since it does not
tie your app down to any single way of doing things.
--
Milo Hyson
CyberLife Labs
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: cocoon + struts
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Vendredi, 2 mai 2003, à 17:09 Europe/Zurich, Yan, Charlene a écrit :
> ...My question is how difficult it is to marry cocoon with struts in
> this case.
If cocoon can do an HTTP request to your application and receive XML
data, it is very easy to use it as a front-end to generate other
formats from this XML. The Cocoon FileGenerator can read XML directly
from any URL.
For an example see "Dynamic XML data" in
http://xml.apache.org/cocoon/howto/howto-html-pdf-publishing.html
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org