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 <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: [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. <http://xml.apache.org/cocoon/faq/index.html> > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> > --------------------------------------------------------------------- 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]>
