cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Ramsteijn <Ramste...@xs4all.nl>
Subject Re: Cocoon database access strategy
Date Sat, 23 Jun 2007 09:28:03 GMT
Warrel,

Do you mean to put the bulk of your business logic into your database, 
using both a full-fledged physical datamodel, SQL and stored procedures?

I am using Oracle, and went even a step further as far as interfacing to 
Cocoon is concerned. From XSPs, I only talk to stored procedures, which 
produce XML output via Oracle's DOM implementation, based on underlying 
SQL and PL/SQL data retrieval methods. XML is converted to BLOBs just 
before handing it over to the Cocoon pipeline. In XSP, I only link in 
presentation related XML (menus, language specific text, etc.), using 
both xinclude and cinclude.

Should I be worried about XSP being depricated?

Paul Ramsteijn
Renal Replacement Registry of the Netherlands


warrell harries wrote:
> 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* <DHohls@csir.co.za 
> <mailto:DHohls@csir.co.za>> 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 <rob@robf.nl <mailto:rob@robf.nl>> 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: users-unsubscribe@cocoon.apache.org
>     <mailto:users-unsubscribe@cocoon.apache.org>
>     For additional commands, e-mail: users-help@cocoon.apache.org
>     <mailto:users-help@cocoon.apache.org>
>
>
>
>     --
>     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
>     CallCentre@csir.co.za <mailto:CallCentre@csir.co.za>.
>
>
>     This message has been scanned for viruses and dangerous content by
>     MailScanner,
>     and is believed to be clean.
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>     <mailto:users-unsubscribe@cocoon.apache.org>
>     For additional commands, e-mail: users-help@cocoon.apache.org
>     <mailto:users-help@cocoon.apache.org>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message