cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Cocoon database access strategy
Date Sat, 23 Jun 2007 19:46:59 GMT
On 6/22/07, warrell harries <> wrote:
> 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.

I think I agree with you.  I limit each technology to its best use.
XSL: Transform XML.
XMAP: Define processing sequence.
JS Flow: Processing requiring custom programming.
XSP: XML generator requiring custom programming.
Java: Reusable components for XMAPs.

Anything that can be reused should become an XMAP component.  I have
an XSP for POST information which would be better as a Generator; it
was written when I was new to Cocoon and I have been too lazy to
rewrite it.  Some functions must be written in Java, usually because
an obvious function is missing from the standard components.  I
overloaded URLSource to pass Cookies in both directions.  (I should
submit my HttpURLSource and HttpURLSourceFactory code to Cocoon.  They
replace URLSource as the default source resolver.)

Business logic rarely belongs in Java because customization belongs at
a higher level.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message