> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> Piroumian Konstantin wrote:
>
> > Writing JavaScript even for client-side can be very tricky
> sometimes, but
> > when you'll start to perform component lookups, EJB calls,
> etc. in JS then
> > you'll have much fun trying to understand why your code
> doesn't work ;)
>
> Sorry but I don't get why. We are not talking about client-side
> javascript that doesn't work as expected because the object
> model is so
> different from one browser to the next.
Are you sure that the OM will be the same from one Cocoon version to
another, or from one Rhino implementation to another? I'm not.
>
> Here, the FOM (flowscript object model) will be one and only
> one. Also,
> javascript enforces exception handling, and the FOM contains a direct
> reference to the cocoon log stream.
That's a good news, but using only logs to debug the flow logic that can be
very complex (remember the missiles ;) ) would be a like using Notepad for
Java programming.
>
> The only thing that misses is strong typing, but I really
> don't see the
> use of this for flow logic description.
Ok.
>
> > Currently, in our application all the flow logic is
> performed by our Screen
> > Flow Controller component that uses an XML-based flowmap
> and the business
> > logic is performed by EJBs. So, the whole picture looks like this:
> >
> > -----------
> > | Cocoon | URI map & Presentation logic
> > -----------
> > |
> > -----------
> > | SFC | Screen Flow logic
> > -----------
> > |
> > -----------
> > | EJB | Business logic
> > -----------
>
> Great, what if this was
>
> -----------
> | Sitemap | Declarative -> XML
> -----------
> |
> -----------
> | FlowScript | Procedural and weakly typed -> javascript
> -----------
> |
> ---------------
> | Business Logic | Procedural and strongly typed -> java
> ---------------
> |
> ------
> | Data | ???
> ------
>
> Why is this so hard to imagine?
No problems witht the imagivation. I just wanted to show how I see the
Presentation - Flow - B-Logic interconnection (and how we are implementing
it). In my picture the "Screen Flow Logic" is just "screen flow logic" and
nothing else (neither XML nor script).
To return to the subject, I just don't want the picture to be this:
---------------------------
| |
| COCOON |
| URI map & Presentation |
| Screen Flow logic |
| Business logic |
| |
---------------------------
And allow to keep things separate.
>
> > 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 .
>
> > I must admit that our XML-flow syntax is becoming more and
> more complex
>
> Bingo!
But I hope that "finite" in FSM is also indication that complexity is finite
;)
>
> > but the good news is that you can use a visual tool to edit
> your flow
>
> 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?
>
> > Here is a snipped from a sitemap where we are using actions...
>
> Oh, there is no doubt on the fact that the approaches are
> similar. Just
> that I don't think that writing flow logic in XML is a good thing.
We got it ;)
But seems that you agree that for simple cases you won't need scripting
(from your answer to Andrew), so in this case using a simplified XML flow
would be quite enough, aren't you? And another big advantage (that you maybe
concider a disadvantage) of XML flow is that the user can do only those
things that are allowed by the limited syntax, while in JavaScript you can
do such unintended things like dynamic pipeline generation or business logic
implementation.
Konstantin
>
> > Wish a had a little free time to implement an XML-based version of
> > flow[map|script] engine. If there are any volunteers for
> that then I can
> > give some examples of the script, answer questions, and
> maybe provide some
> > sources.
>
> Yes, that would be helpful.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <[EMAIL PROTECTED]> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
