Well, I did say "good practice", not "best practice"! (I think the latter is a myth, anyway, and is so case- specific as to be of little use).
If there are two (or three, or more?!) equally good approaches, clearly laid out, with suggested areas of application, and pros and cons highlighted, this is a major step up from and "uh, just do what seems right, you know" [with hands waving in the air]. People are competent enough to make their own choices once you give them sufficient starting material.... >>> [EMAIL PROTECTED] 2004/05/03 07:56:07 PM >>> 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. > >:-) > > >Dave > > > > > > > >>-----Original Message----- >>From: Derek Hohls [mailto:[EMAIL PROTECTED] >>Sent: May 3, 2004 21:31 >>To: [EMAIL PROTECTED] >>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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
