Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)

[Ovidiu Predescu <ov...@apache.org>]

James,

On 6/25/02 3:04 AM, "James Strachan" <ja...@yahoo.co.uk> wrote:

> From: "Piroumian Konstantin" <KP...@protek.com>
>>> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>>> 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 <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT]Flowmaps)

[James Strachan <ja...@yahoo.co.uk>]

HI Ovidiu

Thanks for the heads up. I guess you spotted I've been trying to catch up
with the flowscript discussions as quick as I can and obviously missed some
history along the way. Thanks for setting me straight. Sorry for the
misdirected noise up to now.

> From: "Ovidiu Predescu" <ov...@apache.org>
> > On 6/25/02 3:04 AM, "James Strachan" <ja...@yahoo.co.uk> wrote:
> > 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.

It all makes sense now - thanks.

James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org