James, On 6/25/02 3:04 AM, "James Strachan" <[EMAIL PROTECTED]> wrote:
> From: "Piroumian Konstantin" <[EMAIL PROTECTED]> >>> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] >>>> Piroumian Konstantin wrote: >>>> For completeness of the example I have to say, that >>> business logic is >>>> implemented partially in EJBs (in pure Java) and partially >>> comes from >>>> external resources (a Workflow System, Rules engine, other >>> subsystems >>>> through Corba, etc.). >>> >>> Then my picture would fit your environment better since the flow logic >>> will call business logic components that will then know where >>> and how to >>> find the appropriate information (IoC here). >> >> I don't see why? Our flow engine calls business components using so called >> "operations" that are written in Java and are much like the Cocoon > actions. >> The next step planned here is to implement direct calls to EJBs, like: >> >> <exec operation="ejb:myEJB.getCustomerAccount"> >> <result var="customerAccount" /> >> </exec> >> >> Maybe BSF will be used to implement this or something else, but the flow >> description itself won't require any programming . > > This was why I suggested Jelly as a possible implementation technology. It > can do things like the above already, using XML syntax so its easy to parse > & validate & manipulate & generate & edit with visual tools. > > <j:set var="customerActount" value="${myEJB.customerAccount}"/> > > It can also have embedded bits of javascript / beanshell / jython / pnuts or > any other BSF scripting engine of choice if folks ever feel the need to use > bits of traditional scripting languages for complex stuff, or just invoke > bean method calls to keep complex stuff in Java code. > > With it all being inside XML, its then easy to do things like, disallow > javascript on a site, if folks want to disallow the putting complex logic in > javascript, for example. > > I think i'd prefer to use Java rather than JavaScript for complex logic. > Also if you're going to use a scripting langauge I don't quite grok why > JavasScript is elevated above other languages like beanshell or Jython. The point is not to use the flow language, in this case JavaScript, to write complex business logic, but to write simple scripts that describe what is the order in which the pages are presented to the user. We use what is called a continuation to have the ability to describe this flow in a procedural way, without having to break it in multiple functions. With continuations you can describe your flow in a single procedure. Here are some older threads describing this concept: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=flowmaps%3A+the+wro ng+approach&q=t http://marc.theaimsgroup.com/?w=2&r=1&s=%5Brt%5D+Managing+Flow+and+Resources &q=t It's a lot of reading, so you may want to look at a complex sample of how one would write a Web app using a language with continuations: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100802231017059&w=2 The reason why we use JavaScript is because we have a modified engine which supports continuations. Beside Scheme no other (scripting) language AFAIK supports continuations. >> This was meant about the editor implementation. It's much easier to >> implement a visual editor for formalized flow language (e.g. Rational > Rose - >> State/Activity diagrams) than for a scripting lanuage. Am I wrong? > > Agreed. This was why I'm a fan of using declarative XML languages where > possible, so visual editors can be used, scripts can be easily analysed, > transformed etc. > > For example take a look at the 'workflow' space of BPML, WfMC, EDOC, WSFL > and the like are all declarative XML languages and seem to do similar things > to the 'flow' concept. > > http://www.ebpml.org/status.htm But all think of flow in terms of a finite state machine. The continuations-based flow engine which we use allows flow descriptions as normal programs. When you read such a program, it appears as the function that executes stops at a certain point, when the response is sent back to the user, and resumes when the user click a button on the Web browser. It's much easier to write the code, maintain and enhance it this way. No complex visual tools (usually $$$) are required for this. Regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
