Re: XSP Best Practise Question

[Jens Lorenz]

- Original Message -
From: "Hunsberger, Peter" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 22, 2002 4:47 PM
Subject: RE: XSP Best Practise Question


> > 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 necessarily (through it often seems to be true with XSP): Consider
the
> case where your MVC is implemented in XML and XSLT with Java just
providing
> a way to produce the XML.  In such a case you exploit the Cocoon
pipeline to
> separate things, with separate transformation passes (and separate XSLT)
> implementing each piece.  It's a little foggy on whether the XML or the
XSLT
> implements each piece, the paradigm is twisted enough that it doesn't
map
> completely cleanly.  However, you can still get good separation of
function
> if you don't mind the fact that it's a combination of rules specified in
XML
> and implemented in XSLT that end up implementing the complete MVC
pattern
> (as opposed to a single Java or JSP file).
>
> > 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).
>
> Yes, that's a good observation.  In particular, the sitemap matching
> capabilities begin to become a rule processor.  It strikes me that a
more
> generalized version of the site map would allow XPath traversal of the
> current "pipeline" contents, to match to a template which produces a
"map".
> In other words; the pipeline would just fire off an XSLT that has the
> current Cocoon contexts available to it as parameters or document
sources.
> It would be able to parse these as it needed and directly invoke other
> Cocoon components.  Cocoon's pipeline processing becomes the equivalent
of
> running a transform on a series of XML files which specify what matching
> rules are to be fired. (The results of the transform could be fed to a
> filter that implements the current Cocoon pipeline capabilities.)  The
> default transform would be the identity transform to handle something
> isomorphic to the current version of the sitemap, but one could then
just
> plug in your own XSLT to customize the flow (you'd map various
applications
> with different XML inputs).  This way not only does Cocoon provide a way
of
> running transformations, but the rule engine for determining what
transforms
> to run is just another transform.  Perhaps, this is where flowmaps are
> headed?  I haven't had a chance to look at anything in 2.1 yet

lost you here. Flow is about letting sitemap do what sitemap is meant
for (mapping resources to urls) and defining the application logic
independantly of sitemap. Currently this is procedural JavaScript code.

> > 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.
>
> My advice would be more like; stop thinking in procedural terms and stop
> thinking of using Java to implement everything.  Use XML and XSLT and
> exploit their capabilities!
>

XSLT is definitely the wrong place for business logic. You're missing
database access, transactions and other important things for business
logic.


Jens

--

jens.lorenz at interface-projects dot de

interface:projects GmbH \\|//
Tolkewitzer Strasse 49  (o o)
01277 Dresden   oOOo~(_)~oOOo
Germany


-
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: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

RE: XSP Best Practise Question

[Hunsberger, Peter]

> 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 necessarily (through it often seems to be true with XSP): Consider the
case where your MVC is implemented in XML and XSLT with Java just providing
a way to produce the XML.  In such a case you exploit the Cocoon pipeline to
separate things, with separate transformation passes (and separate XSLT)
implementing each piece.  It's a little foggy on whether the XML or the XSLT
implements each piece, the paradigm is twisted enough that it doesn't map
completely cleanly.  However, you can still get good separation of function
if you don't mind the fact that it's a combination of rules specified in XML
and implemented in XSLT that end up implementing the complete MVC pattern
(as opposed to a single Java or JSP file).

> 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).

Yes, that's a good observation.  In particular, the sitemap matching
capabilities begin to become a rule processor.  It strikes me that a more
generalized version of the site map would allow XPath traversal of the
current "pipeline" contents, to match to a template which produces a "map".
In other words; the pipeline would just fire off an XSLT that has the
current Cocoon contexts available to it as parameters or document sources.
It would be able to parse these as it needed and directly invoke other
Cocoon components.  Cocoon's pipeline processing becomes the equivalent of
running a transform on a series of XML files which specify what matching
rules are to be fired. (The results of the transform could be fed to a
filter that implements the current Cocoon pipeline capabilities.)  The
default transform would be the identity transform to handle something
isomorphic to the current version of the sitemap, but one could then just
plug in your own XSLT to customize the flow (you'd map various applications
with different XML inputs).  This way not only does Cocoon provide a way of
running transformations, but the rule engine for determining what transforms
to run is just another transform.  Perhaps, this is where flowmaps are
headed?  I haven't had a chance to look at anything in 2.1 yet

> 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.

My advice would be more like; stop thinking in procedural terms and stop
thinking of using Java to implement everything.  Use XML and XSLT and
exploit their capabilities!


-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

RE: XSP Best Practise Question

[Leigh Dodds]

>The XSP below mixes content and presentation, and if it 
>contained  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. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

RE: XSP Best Practise Question

[Leigh Dodds]

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:[EMAIL PROTECTED]]
> Sent: 22 August 2002 10:20
> To: [EMAIL PROTECTED]
> 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  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
>
> http://apache.org/xsp";
>   xmlns:xsp-request="http://apache.org/xsp/request/2.0";
>   xmlns:esql="http://apache.org/cocoon/SQL/v2";>
>   
> 
>   Search Results
> 
> 
>   
> 
>   You can edit a department by clicking on the "edit"
>   button, and you can delete a depar

RE: XSP Best Practise Question

[Morrison, John]

Michael,

The _main_ reason that the example XSP operates in this manner
is, quite simply, *because* it's example.  The best method _is_
as you describe, but that would add extra overhead to the example
which would hide what the example is actually trying to show.

J.


===
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission.  There is no intention to
create any legally binding contract or other commitment through the use
of this email.

Experian Limited (registration number 653331).  
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF

-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

XSP Best Practise Question

[Michael Edge]

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  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

http://apache.org/xsp";
  xmlns:xsp-request="http://apache.org/xsp/request/2.0";
  xmlns:esql="http://apache.org/cocoon/SQL/v2";>
  

  Search Results


  

  You can edit a department by clicking on the "edit"
  button, and you can delete a department by clicking on
  the "delete" button.

  
personnel

  
SELECT id, name FROM department
WHERE name LIKE %%
ORDER BY name
  
  

  
  
  


  

  
  

  
  

  

  
We could find any departments that matched your search
criteria of "".
Go back and try again?
  


  
  

  


---
Michael Edge
Global Markets Technology
Institutional Client Group

Phone:  +44  (0) 20 7545 3204
Fax :   +44  (0) 20 7545 1559
Internet email:[EMAIL PROTECTED]


--

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. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>