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.
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.
The only thing that misses is strong typing, but I really don't see the
use of this for flow logic description.
> 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?
> 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 must admit that our XML-flow syntax is becoming more and more complex
Bingo!
> 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.
> 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?
> Here is a snipped from a sitemap where we are using actions to connect to
> our flow engine which is XML-based:
>
> <map:match pattern="process/start">
> <map:act type="start-process">
> <map:read
> src="jsp/{current-page}.jsp" mime-type="text/html"/>
> </map:act>
> </map:match>
>
> <map:match pattern="process/input">
> <map:act type="input-process">
> <map:read
> src="jsp/{current-page}.jsp" mime-type="text/html"/>
> </map:act>
> </map:match>
>
> The first matcher is equivalent of the 'calc/' matcher in Ovidiu's example,
> the second one is the continuation matcher for the same, so seems that all
> approaches are more or less similar.
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.
> 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]
