Return-Path: Delivered-To: apmail-xml-cocoon-users-archive@xml.apache.org Received: (qmail 38081 invoked by uid 500); 22 Aug 2002 16:44:09 -0000 Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-users@xml.apache.org Delivered-To: mailing list cocoon-users@xml.apache.org Received: (qmail 38067 invoked from network); 22 Aug 2002 16:44:09 -0000 From: "Artur Bialecki" To: Subject: RE: XSP Best Practise Question Date: Thu, 22 Aug 2002 12:42:43 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200208220933.33950.agallardo@agsoftware.dnsalias.com> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N There is no single place in cocoon where you can put your logic. Some of it must go into the sitemap, some of it must go into actions, and some of it usually ends up in XSP (since it's so easy). I use cocoon as front end to a J2EE application and not as publishing engine. This means lots of forms, menus, tabs, logic, and sometimes frames. After considering many options I decided that XSP is the best single place for logic. I've created tags (logicsheets) to access our J2EE data as well as some logic tags that take care of authorization (who can see which parts of data). I also have tags that define possible errors for current page and/or request resulting from current page. The errors are usually handled by redirecting to the offending form with hints of what's wrong and original data. I even have a tag. Our GUI developers that don't know Java, but understand XML, XSL like this approach since they can define everything related to given page in one place, the XSP. To achieve this I have to process my XSP in an action and buffer the result (as DOM, or stream of SAX events) until processing is done. Then the generator just streams it out again. I use transormers for localization and user/device specific presentation. This is not your ideal MVC separation, but it works for us. Part of the reason for this approach is that when we started we used cocoon 1.8 which had very different architecture and we didn't want to redo 1000+ XSPs and XSLs. Unfortunately right now I don't see any other way to use Cocoon for application front end even if I was starting from scratch and NO ONE has come up with solution that would satisfy my needs. I don't blame the developers since cocoon was built to be a great publishing engine (which it is) and I know they're working on some neat things for 2.1 that will help (not solve) the application use of Cocoon. Artur... > -----Original Message----- > From: Antonio Gallardo Rivera [mailto:agallardo@agsoftware.dnsalias.com] > Sent: Thursday, August 22, 2002 11:34 AM > To: cocoon-users@xml.apache.org > Subject: Re: XSP Best Practice Question > > > Jens: > > Just a question. You told where is not the best place. My question is: > > Then, where is the better place to put the business logic inside a Cocoon > application? > > This is just a question. Not an argument. I am new in Cocoon too. > > Antonio Gallardo > > > El Jueves, 22 de Agosto de 2002 09:10, Jens Lorenz escribi�: > > ----- Original Message ----- > > From: "Hunsberger, Peter" > > To: > > 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 > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. > > To unsubscribe, e-mail: > For additional commands, e-mail: > --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. To unsubscribe, e-mail: For additional commands, e-mail: