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.
> > Hmmm, where did I hear that? Ah, that's the old 'if the language sucks
> > use a better tool' redmond tune. Believe, it doesn't work on open
> > source.
>
> Don't be so sceptic about good visual tools. They make learning time of
the
> (maybe sucking) language much shorter. What do you think, if the sitemap
had
> a good visual editor then won't it be much simpler to convince people to
use
> Cocoon?
>
> (Disclaimer: I am not a fan of visual XML editing).
>
> >
> > > and tie it to business logic
> > > (which is simpler to implement for XML rather than for
> > script-based flow).
> >
> > I don't understand this. May you elaborate more?
>
> 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
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
