You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Michael Edge <mi...@db.com> on 2002/08/22 11:20:08 UTC
XSP Best Practise Question
Hi All
I have a question regarding the use and purpose of XSP. I believe that XSP is an attempt to separate content/logic from presentation, and I believe it's possible to use it in this way. However, in many of the samples (such as results-dept.xsp below, found in the tutorial) XSP is used to retrieve XML from a database and wrap it in some sort of pseudo-html, which is then processed by a logicsheet to produce proper HTML. To me this defeats the whole purpose of XSP. The XSP below mixes content and presentation, and if it contained <xsp:logic> sections it would be even worse, mixing content, logic and presentation.
My thoughts are that, as the XSP is a generator it should generate XML in some suitable form. If logic is needed within the XSP dynamic tags can be used and translated using a logicsheet (or made part of XSP if they are not resuable). However, the actual presentation of this XML should be left to a stylesheet.
I would really appreciate your comments and thoughts on this as we are trying to implement multiple projects here using Cocoon and want to use a consistent, best-practise approach.
Thanks for your time :-)
Michael
<xsp:page xmlns:xsp="http://apache.org/xsp"
xmlns:xsp-request="http://apache.org/xsp/request/2.0"
xmlns:esql="http://apache.org/cocoon/SQL/v2">
<document>
<header>
<title>Search Results</title>
</header>
<body>
<s1 title="Department Search Results">
<p>
You can edit a department by clicking on the "edit"
button, and you can delete a department by clicking on
the "delete" button.
</p>
<esql:connection>
<esql:pool>personnel</esql:pool>
<esql:execute-query>
<esql:query>
SELECT id, name FROM department
WHERE name LIKE <esql:parameter>%<xsp-request:get-parameter name="name"/>%</esql:parameter>
ORDER BY name
</esql:query>
<esql:results>
<esql:row-results>
<s2>
<xsp:attribute name="title"><esql:get-string column="name"/></xsp:attribute>
<form handler="edit-dept.html">
<xsp:attribute name="name"><esql:get-string column="id"/></xsp:attribute>
<p>
<parameter name="id">
<xsp:attribute name="value"><esql:get-string column="id"/></xsp:attribute>
</parameter>
<submit name="Edit Department"/><submit name="Delete Department"/>
</p>
</form>
</s2>
</esql:row-results>
</esql:results>
<esql:no-results>
<p>
We could find any departments that matched your search
criteria of "<xsp-request:get-parameter name="name"/>".
<link href="search-dept.html">Go back and try again?</link>
</p>
</esql:no-results>
</esql:execute-query>
</esql:connection>
</s1>
</body>
</document>
</xsp:page>
-----------------------------------------------
Michael Edge
Global Markets Technology
Institutional Client Group
Phone: +44 (0) 20 7545 3204
Fax : +44 (0) 20 7545 1559
Internet email: Michael.Edge@db.com
--
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
---------------------------------------------------------------------
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: XSP Best Practise Question
Posted by Leigh Dodds <ld...@ingenta.com>.
>The XSP below mixes content and presentation, and if it
>contained <xsp:logic> sections it would be even worse, mixing content, logic and presentation.
On this point specifically, I'd consider it a best practice to have *all* logic
moved into a logicsheet so that you're left only with your own custom tags
in the XSP page.
If you do this correctly, and design a recently flexible *declarative* language
to wrap you're logic, then you're left with something which isn't wildly
different from a JSP page containing custom JSP tags.
Cheers,
L.
---------------------------------------------------------------------
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: XSP Best Practise Question
Posted by Leigh Dodds <ld...@ingenta.com>.
I've been thinking along the same lines recently, and am still in two minds.
I'm intending on writing up an essay on the CocoDocoWiki when I get a few minutes.
Current musings:
Model-View-Controller is the de facto example of a 'best practice' way of
organising your web application code to allow the maximum degree of separation
between content/logic/presentation.
In servlet/JSP terms this often ends up as a Servlet that does all the work
up front (the Model, often called an Action or Handler), and then the JSP just does the
job of formatting the content to produce the desired output. Often the Model involves
complex business logic, perhaps implemented as EJBs.
When looking sat Cocoon I decided that Generators (including XSP pages) were
definitely the Model part: they hid the complicated details of the processing, and
presented their results to the pipeline for suitable presentation.
This is nice and flexible, because you can quickly wrap existing code as a Generator
or XSP page, and can then take advantage of Cocoon as a flexible publication
tool. Composing pipelines is then often a case of plugging together pre-existing
components to create the desired presentation processing.
However...
As you've noted a lot of examples, and suggested solutions to problems posted
to this list, use an alternate approach: the generators present data to the
pipeline which uses Transformers and Actions to do often complex operations.
The data itself is often wrapped in a page markup language making it easier
to transform it to other forms (HTML/PDF/etc).
This looks like its breaking MVC, and it probably is. Not sure whether this is
good or bad yet, as there are advantages, the main one being that you end
up with less logic hidden in Generators and XSP pages and more in custom
Transformers/Actions. This can be a good thing if the logic is reusable. If
its not, and the various steps in your pipeline are actually tightly coupled then
you're going to end up in a mess, IMHO.
It's at this point that you're starting to treat the sitemap as a programming
language rather than a declarative means of gluing together components.
(Aside: anyone notice how close the Sitemap is becoming to a source file?
Imports: map:components; Instance Variables: component/global params
added in 2.1; Methods: pipelines. There's a danger there in making this
environment too programmer oriented).
So my general advice is: if the logic is reusable, then make it a transformer/action
so you'll have the most reuse. If its not, hide it away.
Hope this is useful.
I've got a slew more thoughts on page markup languages, templating and
separation of concerns, but I'll save that ramble for another time.
Cheers,
L.
--
Leigh Dodds
Weblog: http://weblogs.userland.com/eclectic
Home: http://www.ldodds.com
Current Project: http://outerthought.net/wiki/Wiki.jsp
"Pluralitas non est ponenda sine necessitate" -- William of Ockham
> -----Original Message-----
> From: Michael Edge [mailto:michael.edge@db.com]
> Sent: 22 August 2002 10:20
> To: cocoon-users@xml.apache.org
> Subject: XSP Best Practise Question
>
>
>
> Hi All
>
> I have a question regarding the use and purpose of XSP. I believe that XSP is an attempt
> to separate content/logic from presentation, and I believe it's possible to use it in
> this way. However, in many of the samples (such as results-dept.xsp below, found in the
> tutorial) XSP is used to retrieve XML from a database and wrap it in some sort of
> pseudo-html, which is then processed by a logicsheet to produce proper HTML. To me this
> defeats the whole purpose of XSP. The XSP below mixes content and presentation, and if it
> contained <xsp:logic> sections it would be even worse, mixing content, logic and presentation.
>
> My thoughts are that, as the XSP is a generator it should generate XML in some suitable
> form. If logic is needed within the XSP dynamic tags can be used and translated using a
> logicsheet (or made part of XSP if they are not resuable). However, the actual
> presentation of this XML should be left to a stylesheet.
>
> I would really appreciate your comments and thoughts on this as we are trying to
> implement multiple projects here using Cocoon and want to use a consistent, best-practise
> approach.
>
> Thanks for your time :-)
>
> Michael
>
> <xsp:page xmlns:xsp="http://apache.org/xsp"
> xmlns:xsp-request="http://apache.org/xsp/request/2.0"
> xmlns:esql="http://apache.org/cocoon/SQL/v2">
> <document>
> <header>
> <title>Search Results</title>
> </header>
> <body>
> <s1 title="Department Search Results">
> <p>
> You can edit a department by clicking on the "edit"
> button, and you can delete a department by clicking on
> the "delete" button.
> </p>
> <esql:connection>
> <esql:pool>personnel</esql:pool>
> <esql:execute-query>
> <esql:query>
> SELECT id, name FROM department
> WHERE name LIKE <esql:parameter>%<xsp-request:get-parameter
> name="name"/>%</esql:parameter>
> ORDER BY name
> </esql:query>
> <esql:results>
> <esql:row-results>
> <s2>
> <xsp:attribute name="title"><esql:get-string column="name"/></xsp:attribute>
> <form handler="edit-dept.html">
> <xsp:attribute name="name"><esql:get-string column="id"/></xsp:attribute>
> <p>
> <parameter name="id">
> <xsp:attribute name="value"><esql:get-string column="id"/></xsp:attribute>
> </parameter>
> <submit name="Edit Department"/><submit name="Delete Department"/>
> </p>
> </form>
> </s2>
> </esql:row-results>
> </esql:results>
> <esql:no-results>
> <p>
> We could find any departments that matched your search
> criteria of "<xsp-request:get-parameter name="name"/>".
> <link href="search-dept.html">Go back and try again?</link>
> </p>
> </esql:no-results>
> </esql:execute-query>
> </esql:connection>
> </s1>
> </body>
> </document>
> </xsp:page>
>
> -----------------------------------------------
> Michael Edge
> Global Markets Technology
> Institutional Client Group
>
> Phone: +44 (0) 20 7545 3204
> Fax : +44 (0) 20 7545 1559
> Internet email: Michael.Edge@db.com
>
>
> --
>
> This e-mail may contain confidential and/or privileged information. If you are not the
> intended recipient (or have received this e-mail in error) please notify the sender
> immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution
> of the material in this e-mail is strictly forbidden.
>
>
>
> ---------------------------------------------------------------------
> 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>