Hi ALL,
But the newbe (me) still does not have a concrete answer to his question:
I Only need to make a lot of lookup queries to a DB.
No webforms are used, in fact the resulset can be written to a file.
I dont want to use java if not relly necessarry.
Now I do:
- query1.xml using SqlTransformer on table1
- cleansql.xsl rename <sql:dbfield>
- process1.xsl reorganize
- query2.xsl query different table
- cleansql.xsl rename <sql:dbfield>
- process2.xsl reorganize
...
....
It works , but is this the "right" approach ??
But I would rather recursivly "call" other components from query1.xml.
What can you advise?
greetings
Rob
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]
