cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piroumian Konstantin <KPiroum...@protek.com>
Subject RE: [RT] Flowscript [was Re: [RT] Flowmaps]
Date Fri, 21 Jun 2002 10:45:59 GMT
> From: Ovidiu Predescu [mailto:ovidiu@apache.org] 
> On 6/18/02 8:35 AM, "Stefano Mazzocchi" <stefano@apache.org> wrote:
> 
> > Ovidiu Predescu wrote:
> > [...]
> 
> >> 1. Stefano points out that flowmaps (I don't really like 
> this term, a "map"
> >> is more appropriate for state machines, how about 
> flowscript instead?)
> > 
> > You are right. The concept of 'flowmap' came because of a mental
> > parallel I had between a declarative approach and a 
> procedural one...
> > but after understanding that we don't need that, being the HTTP
> > client/server model intrinsically declarative.
> > 
> > So +1 for 'flowscript'.

What about 'flowlet'?
One can use an XML-FSM (flowmap) implementation, the others JS
(flowscripts), thirds maybe some Prolog-based (logic-engine).

Flowlets can be treated like other servlets and be connected using
<map:forward ... />.

What do you think?

> 
> >> should not be considered as ordinary resources, but a 
> separate concept. I
> >> have no issue declaring them in a different way, just to 
> emphasize this
> >> point. So something like
> >> 
> >>   <map:flowscripts default="calculator">
> >>    <map:flowscript name="calculator" language="javascript">
> >>      <map:script src="calc.js"/>
> >>    </map:flowscript>
> >>   </map:flowscripts>
> >> 
> >> should be OK. 
> > 
> > Hmmm, call me picky, but what's wrong with
> > 
> >  <map:flowscripts default="calculator">
> >   <map:flowscript name="calculator" src="calc.js"
> > language="javascript"/>
> >  </map:flowscripts>
> 
> Because my calculator implementation may be composed of 
> multiple script
> files. This is not the case in this simple example, but I may 
> need to split
> the implementation for clarity in multiple files. Having the 
> ability to
> specify multiple files by adding <map:script> as needed 
> solves the problem.

This will raise namespace problems with function names. Is it really the
task of the sitemap to bother about the set of files? Won't it be better to
use a single file as an entry point and all the rest can be included by this
first one. This way you can add more files without changing the sitemap.

> > 
> > Many ask to make continuations ID as transparent as session 
> IDs. Do you
> > think this is possible/desirable?
> 
> I think it is both desirable and possible. I think the 
> responsibility for
> deciding this should be in the sitemap, and only in one place.

+1 

[...]

> 
> >> 8. Vadim's idea about making the syntax easier.
> >> 
> >> I think the idea of having something as simple as:
> >> 
> >> <map:match pattern="calc/*">
> >>   <map:flow method="calculator" continuation="{1}" />
> >> </map:match>
> >> 

What if one would need this kind of matchers:

<map:match pattern="calc/back/*">
	<map:flow method="calculator" continuation="{1} shift -1" />  <-- go
one step back in the continuation history -->
</map:match>

Having transparent continuations this will allow to use clean links/matchers
like:
'calc/forward'  (+ 1, step forward)
'calc/back' ( -1, step back)

etc.

Is it possible? And is it a good idea from the conceptual point of view:
maybe this kind of behavior should be better coded in the flow script?

[...]

Konstantin

> > 
> > Good luck for all this!
> 
> Thanks!
> 
> Regards,
> -- 
> Ovidiu Predescu <ovidiu@apache.org>
> http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, 
> GNU, Emacs...)
> 
> 
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message