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* <[EMAIL PROTECTED]
<mailto:[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] <mailto:[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]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[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] <mailto:[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]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
