Hi Derek,Ard and Rob, This is an interesting thread because it touches on the received wisdom that 'business-logic' belongs in Java classes. This is even promoted on the web-site under the XSLT FAQ.
At the risk of being heretical, I'm not sure that is something I believe in any longer (or have done for many years). These days, Business logic(whatever that is) is usually managed by some implementation of a pattern e.g. Workflow or a Domain Specific Language. If a Relational DBMS is at the heart of the system then most of the non-process business logic will (or should) be inherent in the entity relationship physical model. Therefore the web-application that Cocoon is being used for is likely to be concerned mostly with handling the View and Controller components of the MVC pattern. The pipeline is an implementation of a use-case and the aggregation, transformation and serialization of XML throughout the life of that interaction is the realisation of the Process associated with the interaction (use-case). Personally, I don't have a problem implementing this with SQL and XSLT. IMHO these are the best supported mainstream Declarative languages (if the underlying documents are properly normalized that is) and so should be understood by anyone involved in the application development or maintenance (if only it were so). I have found that bias towards putting 'business logic' in Java classes usually comes from those who perhaps do not fully grasp the power of the relational model and SQL as a Set calculus. Their preference for imperative programming seems to stem from the very human urge to be in full control of the environment and to stick with familiar constructs and tools. This leads to start writing code before the problem is fully understood and a reluctance to refactor once it is. These are the very tendencies that Cocoon allows us to overcome because it is entirely possible to develop fully fledged applications without writing any Java code. These 'pure' XML applications are likely to be much more maintainable, flexible and capable of re-use than those that skew their centre of gravity back towards Java. On 19/06/07, Derek Hohls <[EMAIL PROTECTED]> wrote:
Rob I too have a copy of the "Cocoon developers handbook"; it occupies a nice niche on my bookshelf. :-) Unfortunately, Cocoon is a live framework, not a static language. The handbook was published in 2003, which means it was probably written in 2002 ie. 5 years ago. If, according to a popular reckoning, one month of "Internet time" equals three months of "real time", then the book is 15 years old! Things move on - fast - during that time. More especially, there was a lot of development around the use of flow and JXtemplates, effectively replacing XSP as the preferred way for "scripting logic" (of course, be aware that "serious" Cocoon developers will insist that ALL logic belongs in Java classes). Suggest you look at newer version of Cocoon, and the samples, (eg. the "Easy SQL database access" sample in blocks/forms) as well as some of the more recent documents on the above topics. This comes up a lot on the mailing list too! >>> robf <[EMAIL PROTECTED]> 2007/06/18 09:45:09 PM >>> Derek Hohls wrote: > "XSL and Database Actions are deprecated" > > As far as I know, XSL is not deprecated - perhaps you meant XSP? > But I am not sure that is deprecated... perhaps one of the developers > could address the plans for that technology - will it still be supported > in > versions 2.2 and beyond? > XSP's deprecated ? I recently red a book "Cocoon developers handbook" where esql embedded in xsp's is teached... I am astonished about the rapid deprecation of cocoon 'techniques' , I think I can better fallback to C, xsltproc and some scripting glue logic :-) So where do I put my esql now? Rob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to [EMAIL PROTECTED] This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
