Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 23600 invoked by uid 500); 20 Jun 2002 12:30:11 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 23589 invoked from network); 20 Jun 2002 12:30:11 -0000 Message-ID: <3D11CA8E.7060908@apache.org> Date: Thu, 20 Jun 2002 08:29:02 -0400 From: "Andrew C. Oliver" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [RT] Flowmaps References: <3D11C2A8.1080600@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Oh god no...businesslogic in javascript.. . no no no. I'm having nightmeres of "Sr. Application Developer"s (with emphasis on the quotes) writing nightmere webapps with "businesslogic" sprinkled throughout in this "flowmap" as one big huge jumble of spaghetti. I'll write on my concerns with the flowmap in about a week when I have a bit more time to study it closely (hopefully) Nicola Ken Barozzi wrote: > > Gerhard Froehlich wrote: > >> Niclola, >> >> >>>> You can also do everything in JavaScript, but beware that you're >>>> moving >>> >>> >> the >> >>>> business logic in JavaScript, where it shouldn't be. >>> >>> >>> >>> Where should it be then (not provocative, just a question I cannot >>> simply answer myself)? >>> >>> I think that if we don't come up with a business-logic framework of >>> some >>> sort, we will see programmers do the most wild things. >> >> >> >> Disagree, I wouldn't use it, when I don't have the freedom to code the >> flowscripts like *I* want them. Patterns OK, but please not again such a >> academic and not really usable thing like EJBs! > > > You are right. > EJBs are not really only business rules... I was thinking about > something like ILog rules. > >>> IMNSHO, Cocoon should be PnP, and not *require* java programming, ie no >>> compilation step. >> >> >> >> But I wouldn't ban it from the concept, IMO we would loose >> flexibility. Hmm >> maybe we can work with the BSF Framework >> (http://www-124.ibm.com/developerworks/projects/bsf) >> to get javascript implemented flowscripts integrated in our Java >> business >> logic. Like Parameters and stuff. > > > As I said, we should not *require*, that means that users should be > given the choice, ie possibility of not using Java directly for > business logic. > > Business logic is more... well... logic than Java programming, and I > think that for many needs Java is just overkill. > > I want *also* something that is not Java that can help me make my > business rules. > >>> >>> Assuming that I want to make my business rules *without* java, what >>> can I use? >>> Where do I put them? >>> How do I organize them? >>> Is there a repository for them? >>> How do I use them in the flow? >>> How do I make transactions? >>> � >> > > This is the whole point: I'm talking as a generic "user". > > I'm 100% sure that many users will use flowscript to make business logic. > If we tell them "use java", many will not. > If we give them also a business method system (markup, language, > binding, whatever) they will use it. > If we don't, they will use flowscript. > > Just as many use sitemaps for programming, but with flowscript, being > it procedural, it will be even more. > --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org