cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nacho Jimenez <>
Subject Re: Business Logic in Cocoon Applications?
Date Mon, 03 May 2004 17:56:07 GMT
David Leangen wrote:

>Well said!
>I don't mind volunteering myself to draft a Wiki during my spare time.
>However, as I mentioned before, I think that we need some type of consensus
>on these issues... even if that means agreeing to disagree.
>So, first reach consensus and I'll sum in all up in a Wiki with pleasure.
>>-----Original Message-----
>>From: Derek Hohls []
>>Sent: May 3, 2004 21:31
>>Subject: Business Logic in Cocoon Applications?
>>There have been a number of threads on the mailing list (April 2004) on
>>the issue of "where to locate the Business Logic"; with Cocoon Flow, for
>>example, coming under criticism (and defence) for its potential to act
>>(correctly or incorrectly?!) in this respect.
>>It would be very helpful to set up a "good practice guide" for Cocoon
>>users that identifies (a) what types of logic one encounters [what do we
>>actually mean by 'Business Logic', and there are any other types??] and
>>(b) how and where to go about implementing these in the various layers.
>>As always, clear examples would help new users.
>>I do not think it matters if the application is small or large, simple
>>or complex, the principles and approaches need to be consistent so that
>>one can transition from between projects knowing that the "same things
>>will be in the same places".
>>Any takers to draft a Wiki Page on this topic?

    Mine! Mine!

    The thing is.. who's so cocky as to say that he (she? any 
cocoon-girls arround?) is using the best approach?

    I think we should run a debate on which is the "best" way to do 
something and once we clarify which way is it, then we can do the wiki.  
But we have to try to keep it in practical terms, or the dabate will 
take on forever. Sometimes the theoreticaly-best way is not the best way 
due to performance, ease of use, etc..

    We could have several different scenarios and the best way to 
implement each one.. and maybe as a final page, a guide with some 
interesting alternatives that branch from each case...

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

View raw message