You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Ad...@eFunds.com on 2001/02/05 14:04:57 UTC
Combining Cocoon with Struts Tag libs
Cocoon-Collective,
I am still trying to make architecture decisions. I have a pretty good
understanding of both Struts and Cocoon architectures. I have seen a
couple of other people inquire about a hybrid solution using the strengths
in both. Has anyone considered or done this successfully and seemingly
painlessly?
I guess this really comes down to a comparison of xsp vs. jsp and which to
use. The other major consideration is performance, the system I need to
build will be high traffic and transactional. Does anyone have a similar
situation or opinion that will help my decision process?
Thanks,
Adam
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Combining Cocoon with Struts Tag libs
Posted by Jorge De Flon <jd...@netappsmexico.com>.
I dont think that it is only xsp vs JSP, if that were the case, cocoon would
be the immediate winner.
Things get complicated when you use struts with velocity or other template
engine, because you get a lot of flexibility and the JSP disadvantages get
diminished.
----- Original Message -----
From: <Ad...@eFunds.com>
To: <co...@xml.apache.org>
Sent: Monday, February 05, 2001 8:04 AM
Subject: Combining Cocoon with Struts Tag libs
> Cocoon-Collective,
>
> I am still trying to make architecture decisions. I have a pretty good
> understanding of both Struts and Cocoon architectures. I have seen a
> couple of other people inquire about a hybrid solution using the strengths
> in both. Has anyone considered or done this successfully and seemingly
> painlessly?
>
> I guess this really comes down to a comparison of xsp vs. jsp and which to
> use. The other major consideration is performance, the system I need to
> build will be high traffic and transactional. Does anyone have a similar
> situation or opinion that will help my decision process?
>
> Thanks,
> Adam
>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Combining Cocoon with Struts Tag libs
Posted by Werner Guttmann <We...@morganstanley.com>.
Adam,
there's a couple of alternatives you seem to have, one of them using XMLForms
et alias to implement functionality of Struts in Cocoon. As this functionality
has only become available in the recent past, we have taken a different
approach using the XMLizable interface of Cocoon to integrate our business
domain model with both Struts and Coccon.
In our case, an inbound HTTP request is
1) picked up by Struts, which a) populates its FormBean(s) , and b) forwards
to a pre-configured Action for additional validation. If successful, we then
forward control to an XSP ... in order to avoid introducing dependencies
between Struts and Cocoon, we decided to implement our own set of JavaBeans to
keep the set of parameters as selected in the HTML form, which we attached to
the request/session scope as attributes.
b) On Coccon receiving the HTTP request (forward), Coocon kicked in and
invoked the relevant pipeline. That pipeline uses the ServerPages generator to
invoke an XSP that uses the following code fragment:
<xsp:logic>
XMLizable xmlizable = new XTransformer();
</xsp:logic>
<some_entities><xsp:expr>xmlizable</xsp:expr></some_entities>
Cocoon - when processing the <xsp:exp> element - will invoke the
toSAX(ContentHandler) method on our XTransformer class, and expects this
method to insert SAX events into the event stream. In our case, for each
business entity we have a corresponding Transformer instance that uses the
aforementioned Criteria object, a business delegate and (potentially) a value
list handler implementation to get a collection of business entities from our
business backend, and render them to SAX events. From there on, it's business
as usual with Cocoon executing the remainder of the pipeline.
Now, having followed some of the traffic on this list re: XMLForms, etc., I am
under the impression that most of the stuff could (and maybe should) be done
through the use of XMLForms, ValidatorAction, etc. Unfortunately, I have not
had the time to evaluate the various offering (yet).
I hope this helps.
Werner
Adam_Waldal@eFunds.com wrote:
> Cocoon-Collective,
>
> I am still trying to make architecture decisions. I have a pretty good
> understanding of both Struts and Cocoon architectures. I have seen a
> couple of other people inquire about a hybrid solution using the strengths
> in both. Has anyone considered or done this successfully and seemingly
> painlessly?
>
> I guess this really comes down to a comparison of xsp vs. jsp and which to
> use. The other major consideration is performance, the system I need to
> build will be high traffic and transactional. Does anyone have a similar
> situation or opinion that will help my decision process?
>
> Thanks,
> Adam
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: Combining Cocoon with Struts Tag libs
Posted by Andre Cusson <ac...@hyperbase.com>.
Hi Werner,
Struts is fine but for maintainability I would also try to minimize the
different technologies that developpers/maintainers have to master. Java,
EJB, JMS, XML, RuleML, XSLT and Cocoon are some of our basic/core
technologies. XSP and XMLForms are interesting and are being considered but
given that we already have some xslt code generating all kinds of pages by
merging (separation of concerns) page layouts and complex document contents
at an impressive rate, and that validation and entitlement can be managed in
xslt and may not require Java code. Why would it still be better for us to
integrate with XSP, loose some portability and (slightly!) increase manpower
qualification requirements ? I am guessing that there is a reason (or
many), I am just trying to figure it out clearly.
As for Struts, given that we do not already have a heavy investment in it,
what would integrating Struts with Cocoon provide that Cocoon and XSLT do
not already provide ?
As for workflow, shouldn't a real solution involve rules (as in
RuleML/XSLT), as opposed to Struts actions, for example ?
Thank you
ac
-----Message d'origine-----
De : Werner Guttmann [mailto:Werner.Guttmann@morganstanley.com]
Envoye : 17 juin, 2002 13:03
A : cocoon-users@xml.apache.org
Objet : Re: Combining Cocoon with Struts Tag libs
Andre,
wouldn't you loose most of the benefits being given to by a framework such
as
Struts (or Cocoon's new XMLForms et alias features) is, e.g. form
validation,
declarative definition of your flows, error handling, etc ? Which somehow is
the
opposite of what Adam is trying to achieve, I assume: i.e. create an
application
space where framework like Struts/Cocoon are used to manage and cut down on
the
complexity of the task(s) in question and where long-term maintainability
(through separation of concerns) is a major concern and needs to be managed
carefully.
Thanks
Werner
Andre Cusson wrote:
> Hi,
>
> How about no JSP, no XSP, just XSLT (with external (ex: Java) functions
(and
> some sitemap design) to access the back end) ?
> Wouldn't this make the application less dependent on a specific Cocoon
> technology (XSP) ?
> What would really be lost without XSP ?
>
> Thank you for your support and consideration.
> ac
>
> -----Message d'origine-----
> De : Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> Envoye : 17 juin, 2002 12:31
> A : cocoon-users@xml.apache.org
> Objet : RE: Combining Cocoon with Struts Tag libs
>
> > From: Adam_Waldal@eFunds.com [mailto:Adam_Waldal@eFunds.com]
> >
> > Cocoon-Collective,
> >
> > I am still trying to make architecture decisions. I have a pretty
> good
> > understanding of both Struts and Cocoon architectures. I have seen a
> > couple of other people inquire about a hybrid solution using the
> strengths
> > in both. Has anyone considered or done this successfully and
> seemingly
> > painlessly?
> >
> > I guess this really comes down to a comparison of xsp vs. jsp and
> which to
> > use. The other major consideration is performance, the system I need
> to
> > build will be high traffic and transactional. Does anyone have a
> similar
> > situation or opinion that will help my decision process?
>
> XSP generates XML. JSP generates plain text. Beware of extra parsing
> result of JSP must go throw to become SAX XML events.
>
> Vadim
>
> > Thanks,
> > Adam
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Parameters, their stack and cocoon: protocol....
Posted by KOZLOV Roman <r-...@opencascade.com>.
Hi,
What is {2} in this case? It seems that you can use {1} because there is one "*"
only.
Roman
Per Kreipke wrote:
> This is a two part question.
>
> - If I call another pipeline with an XSP file using the cocoon: protocol, it
> doesn't seem as if the caller's sitemap parameters are available to any XSP
> the called pipeline. Is that true? E.g.
>
> <!-- Callee -->
> <map:match pattern="config">
> <map:generate src="config.xsp" />
> <map:serialize type="xml" />
> </map:match>
>
> <!-- Caller -->
> <map:match pattern="*/foo">
> <map:generate src="cocoon:/config>
> <map:parameter name="client" value="{2}" />
> </map:generate>
> </map:match>
>
> in config.xsp, I can't get the value of {client} through
> parameters.getParameter("client").
>
> - corollary: is the stack of parameters available to XSP file? Or is there a
> way of getting the parent of the parameters?
>
> Per
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: Parameters, their stack and cocoon: protocol....
Posted by Per Kreipke <pe...@onclave.com>.
> > > > - If I call another pipeline with an XSP file using the cocoon:
> > > > protocol, it
> > > > doesn't seem as if the caller's sitemap parameters are available
> > > > to any XSP
> > >
> > > _sitemap_ parameters are not available to _any_ XSP. Only parameters
> > > declared _on_ generator/transformer/action/matcher/selector are
> > > available to the component.
> >
> > Fine, you're saying that "sitemap parameters" are different than the
>
> "Sitemap parameters" which are available for substitution as {1},
> {name}, {../other}, etc, *are* different from the <map:parameter/>s on
> components.
>
> "Sitemap parameters" is a Stack of Maps, and every matcher/action adds
> one more Map to it, and it is removed as soon as matcher/action tag is
> closed. To navigate the stack, you have directory-like {../../1} syntax.
Ok. Got it.
> > map:parameters that are declared on gen/trans/action/match/select
> sections.
> >
> > Then let me ask: are the caller's parameters available to the callee
> below?
> >
> > > > the called pipeline. Is that true? E.g.
> > > >
> > > > <!-- Callee -->
> > > > <map:match pattern="config">
> > > > <map:generate src="config.xsp" />
> > > > <map:serialize type="xml" />
> > > > </map:match>
> > > >
> > > > <!-- Caller -->
> > > > <map:match pattern="*/foo">
> > > > <map:generate src="cocoon:/config>
> > > > <map:parameter name="client" value="{2}" />
> > >
> > > Does this syntax exist? (too lazy to check source code...)
> >
> > First, should have been {1}.
> > Second, what syntax do you mean?
>
> Sorry, did not get at first.
>
> Parameter declared on the generator will be available *only* to this
> generator. What generator will do with it - it's a different question.
Ah. So they won't be available to the generator in the other matcher. Ok.
> In this particular case, this parameter will be used nowhere.
Well, I was hoping that the config.xsp would have it to do something with.
For example, the sitemap fragment for "config" could be used from different
parts of the sitemap with different values (e.g. different clients, etc).
I see your examples below for another way to do it. Will check them out,
thanks.
> > > > </map:generate>
> > > > </map:match>
> > > >
> > > > in config.xsp, I can't get the value of {client} through
> > > > parameters.getParameter("client").
> >
> > > > - corollary: is the stack of parameters available to XSP file?
> > >
> > > No.
> >
> > Sigh.
>
> "Sitemap parameters", this stack of maps, will not exist once execution
> of sitemap is finished. And execution of XSP will not start before
> execution of sitemap is finished.
Now that's very interesting and important. I did not know that. Will remap
my synapses right away.
> > > > Or is there a
> > > > way of getting the parent of the parameters?
> > >
> > > Sorry, did not get this one.
> >
> > Can I (from XSP) ask for parameters.getParameter("../../client") for
> > example?
>
> No. You can ask only for parameters which are declared on XSP.
Right, got it now.
> Example 1:
>
> <!-- Callee -->
> <map:match pattern="config">
> <map:match type="reqest-parameter" pattern="client">
> <map:generate src="config.xsp">
> <map:parameter name="client" value="{1}"/>
> </map:generate>
> <map:serialize type="xml" />
> </map:match>
>
> <!-- Caller -->
> <map:match pattern="*/foo">
> <map:generate src="cocoon:/config?client={1}"/>
> <map:serialize type="xml" />
> </map:match>
>
>
> Example 2:
>
> <!-- Callee -->
> <map:match pattern="config/*">
> <map:generate src="config.xsp">
> <map:parameter name="client" value="{1}"/>
> </map:generate>
> </map:match>
>
> <!-- Caller -->
> <map:match pattern="*/foo">
> <map:generate src="cocoon:/config/{1}"/>
> <map:serialize type="xml" />
> </map:match>
Thanks much. I'd done the same for another pipeline. Not sure why I didn't
think of it for this part :-)
Per
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: Parameters, their stack and cocoon: protocol....
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Per Kreipke [mailto:per@onclave.com]
>
> > > - If I call another pipeline with an XSP file using the cocoon:
> > > protocol, it
> > > doesn't seem as if the caller's sitemap parameters are available
> > > to any XSP
> >
> > _sitemap_ parameters are not available to _any_ XSP. Only parameters
> > declared _on_ generator/transformer/action/matcher/selector are
> > available to the component.
>
> Fine, you're saying that "sitemap parameters" are different than the
"Sitemap parameters" which are available for substitution as {1},
{name}, {../other}, etc, *are* different from the <map:parameter/>s on
components.
"Sitemap parameters" is a Stack of Maps, and every matcher/action adds
one more Map to it, and it is removed as soon as matcher/action tag is
closed. To navigate the stack, you have directory-like {../../1} syntax.
> map:parameters that are declared on gen/trans/action/match/select
sections.
>
> Then let me ask: are the caller's parameters available to the callee
below?
>
> > > the called pipeline. Is that true? E.g.
> > >
> > > <!-- Callee -->
> > > <map:match pattern="config">
> > > <map:generate src="config.xsp" />
> > > <map:serialize type="xml" />
> > > </map:match>
> > >
> > > <!-- Caller -->
> > > <map:match pattern="*/foo">
> > > <map:generate src="cocoon:/config>
> > > <map:parameter name="client" value="{2}" />
> >
> > Does this syntax exist? (too lazy to check source code...)
>
> First, should have been {1}.
> Second, what syntax do you mean?
Sorry, did not get at first.
Parameter declared on the generator will be available *only* to this
generator. What generator will do with it - it's a different question.
In this particular case, this parameter will be used nowhere.
> > > </map:generate>
> > > </map:match>
> > >
> > > in config.xsp, I can't get the value of {client} through
> > > parameters.getParameter("client").
>
> > > - corollary: is the stack of parameters available to XSP file?
> >
> > No.
>
> Sigh.
"Sitemap parameters", this stack of maps, will not exist once execution
of sitemap is finished. And execution of XSP will not start before
execution of sitemap is finished.
> > > Or is there a
> > > way of getting the parent of the parameters?
> >
> > Sorry, did not get this one.
>
> Can I (from XSP) ask for parameters.getParameter("../../client") for
> example?
No. You can ask only for parameters which are declared on XSP.
Example 1:
<!-- Callee -->
<map:match pattern="config">
<map:match type="reqest-parameter" pattern="client">
<map:generate src="config.xsp">
<map:parameter name="client" value="{1}"/>
</map:generate>
<map:serialize type="xml" />
</map:match>
<!-- Caller -->
<map:match pattern="*/foo">
<map:generate src="cocoon:/config?client={1}"/>
<map:serialize type="xml" />
</map:match>
Example 2:
<!-- Callee -->
<map:match pattern="config/*">
<map:generate src="config.xsp">
<map:parameter name="client" value="{1}"/>
</map:generate>
</map:match>
<!-- Caller -->
<map:match pattern="*/foo">
<map:generate src="cocoon:/config/{1}"/>
<map:serialize type="xml" />
</map:match>
Vadim
> Per
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: Parameters, their stack and cocoon: protocol....
Posted by Per Kreipke <pe...@onclave.com>.
> > - If I call another pipeline with an XSP file using the cocoon:
> protocol, it
> > doesn't seem as if the caller's sitemap parameters are available to
> any XSP
>
> _sitemap_ parameters are not available to _any_ XSP. Only parameters
> declared _on_ generator/transformer/action/matcher/selector are
> available to the component.
Fine, you're saying that "sitemap parameters" are different than the
map:parameters that are declared on gen/trans/action/match/select sections.
Then let me ask: are the caller's parameters available to the callee below?
> > the called pipeline. Is that true? E.g.
> >
> > <!-- Callee -->
> > <map:match pattern="config">
> > <map:generate src="config.xsp" />
> > <map:serialize type="xml" />
> > </map:match>
> >
> > <!-- Caller -->
> > <map:match pattern="*/foo">
> > <map:generate src="cocoon:/config>
> > <map:parameter name="client" value="{2}" />
>
> Does this syntax exist? (too lazy to check source code...)
First, should have been {1}.
Second, what syntax do you mean?
> > </map:generate>
> > </map:match>
> >
> > in config.xsp, I can't get the value of {client} through
> > parameters.getParameter("client").
> > - corollary: is the stack of parameters available to XSP file?
>
> No.
Sigh.
> > Or is there a
> > way of getting the parent of the parameters?
>
> Sorry, did not get this one.
Can I (from XSP) ask for parameters.getParameter("../../client") for
example?
Per
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: Parameters, their stack and cocoon: protocol....
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Per Kreipke [mailto:per@onclave.com]
>
> This is a two part question.
>
> - If I call another pipeline with an XSP file using the cocoon:
protocol, it
> doesn't seem as if the caller's sitemap parameters are available to
any XSP
_sitemap_ parameters are not available to _any_ XSP. Only parameters
declared _on_ generator/transformer/action/matcher/selector are
available to the component.
> the called pipeline. Is that true? E.g.
>
> <!-- Callee -->
> <map:match pattern="config">
> <map:generate src="config.xsp" />
> <map:serialize type="xml" />
> </map:match>
>
> <!-- Caller -->
> <map:match pattern="*/foo">
> <map:generate src="cocoon:/config>
> <map:parameter name="client" value="{2}" />
Does this syntax exist? (too lazy to check source code...)
> </map:generate>
> </map:match>
>
> in config.xsp, I can't get the value of {client} through
> parameters.getParameter("client").
>
> - corollary: is the stack of parameters available to XSP file?
No.
> Or is there a
> way of getting the parent of the parameters?
Sorry, did not get this one.
Vadim
>
> Per
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Parameters, their stack and cocoon: protocol....
Posted by Per Kreipke <pe...@onclave.com>.
This is a two part question.
- If I call another pipeline with an XSP file using the cocoon: protocol, it
doesn't seem as if the caller's sitemap parameters are available to any XSP
the called pipeline. Is that true? E.g.
<!-- Callee -->
<map:match pattern="config">
<map:generate src="config.xsp" />
<map:serialize type="xml" />
</map:match>
<!-- Caller -->
<map:match pattern="*/foo">
<map:generate src="cocoon:/config>
<map:parameter name="client" value="{2}" />
</map:generate>
</map:match>
in config.xsp, I can't get the value of {client} through
parameters.getParameter("client").
- corollary: is the stack of parameters available to XSP file? Or is there a
way of getting the parent of the parameters?
Per
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Combining Cocoon with Struts Tag libs
Posted by Werner Guttmann <We...@morganstanley.com>.
Andre,
wouldn't you loose most of the benefits being given to by a framework such as
Struts (or Cocoon's new XMLForms et alias features) is, e.g. form validation,
declarative definition of your flows, error handling, etc ? Which somehow is the
opposite of what Adam is trying to achieve, I assume: i.e. create an application
space where framework like Struts/Cocoon are used to manage and cut down on the
complexity of the task(s) in question and where long-term maintainability
(through separation of concerns) is a major concern and needs to be managed
carefully.
Thanks
Werner
Andre Cusson wrote:
> Hi,
>
> How about no JSP, no XSP, just XSLT (with external (ex: Java) functions (and
> some sitemap design) to access the back end) ?
> Wouldn't this make the application less dependent on a specific Cocoon
> technology (XSP) ?
> What would really be lost without XSP ?
>
> Thank you for your support and consideration.
> ac
>
> -----Message d'origine-----
> De : Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> Envoye : 17 juin, 2002 12:31
> A : cocoon-users@xml.apache.org
> Objet : RE: Combining Cocoon with Struts Tag libs
>
> > From: Adam_Waldal@eFunds.com [mailto:Adam_Waldal@eFunds.com]
> >
> > Cocoon-Collective,
> >
> > I am still trying to make architecture decisions. I have a pretty
> good
> > understanding of both Struts and Cocoon architectures. I have seen a
> > couple of other people inquire about a hybrid solution using the
> strengths
> > in both. Has anyone considered or done this successfully and
> seemingly
> > painlessly?
> >
> > I guess this really comes down to a comparison of xsp vs. jsp and
> which to
> > use. The other major consideration is performance, the system I need
> to
> > build will be high traffic and transactional. Does anyone have a
> similar
> > situation or opinion that will help my decision process?
>
> XSP generates XML. JSP generates plain text. Beware of extra parsing
> result of JSP must go throw to become SAX XML events.
>
> Vadim
>
> > Thanks,
> > Adam
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: Combining Cocoon with Struts Tag libs
Posted by Andre Cusson <ac...@hyperbase.com>.
Hi,
How about no JSP, no XSP, just XSLT (with external (ex: Java) functions (and
some sitemap design) to access the back end) ?
Wouldn't this make the application less dependent on a specific Cocoon
technology (XSP) ?
What would really be lost without XSP ?
Thank you for your support and consideration.
ac
-----Message d'origine-----
De : Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
Envoye : 17 juin, 2002 12:31
A : cocoon-users@xml.apache.org
Objet : RE: Combining Cocoon with Struts Tag libs
> From: Adam_Waldal@eFunds.com [mailto:Adam_Waldal@eFunds.com]
>
> Cocoon-Collective,
>
> I am still trying to make architecture decisions. I have a pretty
good
> understanding of both Struts and Cocoon architectures. I have seen a
> couple of other people inquire about a hybrid solution using the
strengths
> in both. Has anyone considered or done this successfully and
seemingly
> painlessly?
>
> I guess this really comes down to a comparison of xsp vs. jsp and
which to
> use. The other major consideration is performance, the system I need
to
> build will be high traffic and transactional. Does anyone have a
similar
> situation or opinion that will help my decision process?
XSP generates XML. JSP generates plain text. Beware of extra parsing
result of JSP must go throw to become SAX XML events.
Vadim
> Thanks,
> Adam
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: Combining Cocoon with Struts Tag libs
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Adam_Waldal@eFunds.com [mailto:Adam_Waldal@eFunds.com]
>
> Cocoon-Collective,
>
> I am still trying to make architecture decisions. I have a pretty
good
> understanding of both Struts and Cocoon architectures. I have seen a
> couple of other people inquire about a hybrid solution using the
strengths
> in both. Has anyone considered or done this successfully and
seemingly
> painlessly?
>
> I guess this really comes down to a comparison of xsp vs. jsp and
which to
> use. The other major consideration is performance, the system I need
to
> build will be high traffic and transactional. Does anyone have a
similar
> situation or opinion that will help my decision process?
XSP generates XML. JSP generates plain text. Beware of extra parsing
result of JSP must go throw to become SAX XML events.
Vadim
> Thanks,
> Adam
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>