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

[Piroumian Konstantin <KP...@protek.com>]

> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org] 
> Luca Morandini wrote:
> > Nicola,
> > 

<snip what="a few X-related sentences" />

> 
> > The page structure of HTML has nothing to do with Business Object or
> > Business Rules or other abstractions... but we should deal with it.
> > 
> > Therefore, let's just try to centralize transitions amongst 
> pages, like the
> > sitemap has done with URI matching and dispatching. Just 
> implementing this
> > feature will be a giant step forward.
> 
> How can you define transitions without logic?

May I demonstrate?

In most cases you will need simple wizards to gather some data from the user
and then call some business logic at the end. Here is a transition
description without logic (coded in it):

<!-- Customer Registration wizard -->
<wizard id="INPUT_PERSON_PROFILE" base="/xml/forms">
	<form href="person_reg.xml" name="person" />
	<form href="enter_address.xml" max-pass="3" collection="addresses"
name="address"/>
	<form href="ident_doc.xml" name="identification_document"/>

	<form href="enter_contact.xml" name="contact"/>	
</wizard>	

I think that everything's here is obvious, isn't it? The logic of the wizard
(Next, Prev, Finish, Add/Remove, etc.) was implemented in a Java and in a C1
logicsheet. There were also other nice features, like automatic navigation
bar generation, etc.

And this quite simple construct were used to create rather complex and
configurable application (using Cocoon 1): a web interface to a workflow
system. 

> Transitions are based on rules.
> Rules come from algorithms that operate on the model.
> Thus, you need
> 
> > BTW, I'd like a declarative implementation, rather than 
> using a script
> > language.
> 
> If flowmaps are page transitions it could be.
> 
> But it's intriguing to think that the javascript flowmaps can 
> be an easy 
> way to make webapps... hmmm...

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 ;)

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
 -----------
 
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.). 

I must admit that our XML-flow syntax is becoming more and more complex, but
the good news is that you can use a visual tool to edit your flow and tie it
to business logic (which is simpler to implement for XML rather than for
script-based flow).

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.

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.

Konstantin

> 
> -- 
> Nicola Ken Barozzi                   nicolaken@apache.org
>              - verba volant, scripta manent -
>     (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

---------------------------------------------------------------------
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)

[Stefano Mazzocchi <st...@apache.org>]

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.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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