On 6/22/07, warrell harries <[EMAIL PROTECTED]> 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.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
