Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <467D41ED.3020308@robf.nl>
Date: Sat, 23 Jun 2007 17:53:17 +0200
From: Rob Frohwein <rob@robf.nl>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: Cocoon database access strategy
References: <4676C884020000D400006965@cs-emo.csir.co.za>
	 <4676E0C5.40207@robf.nl> <46779B81020000D40000697D@cs-emo.csir.co.za>
 <5c4168b80706220637p4eb89dc3h3147c8e390a974c4@mail.gmail.com>
In-Reply-To: <5c4168b80706220637p4eb89dc3h3147c8e390a974c4@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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* <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