Return-Path: 
 <cocoon-dev-return-28588-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 57021 invoked by uid 500); 24 Jun 2002 09:39:03 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 57009 invoked from network); 24 Jun 2002 09:39:02 -0000
Message-ID: <B6352CB87AA70442A1C6F49E6B658C9801EDF3@POSTMAN.flagship.ru>
From: Piroumian Konstantin <KPiroumian@protek.com>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: [RT] SpitScript - B-Logic that doesn't suck   ( Re: [RT] Flow
	maps)
Date: Mon, 24 Jun 2002 13:40:20 +0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="koi8-r"
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

> 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