cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Fagerstrom" <daniel.fagerst...@swipnet.se>
Subject RE: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Date Sun, 23 Jun 2002 16:25:19 GMT
Andrew C. Oliver wrote:
> Stefano Mazzocchi wrote:
> >Ok. Here's my vision: a flowscript is the location where you place your
> >flow logic. The flow logic is the collection of instructions that
> >indicate how to make the transition from one page to another.
> >
> >Everything else shouldn't be there.
> >
> So why do you need scripting for that?  It seems inconsonant with the
> rest of Cocoon and even unnecessary.

Agree, if flowscripts only are supposed to be used for flow logic and not
for writing complete webapps, the use of JavaScript seem like _massive_ FS
to me.

> There is relatively minor difference between what XSLT does (match
> conditions and output a result) and
> what the flowscript does and the sitemap and what the flowscript does.
>  The gap is I suppose a mid sitemap
> decision on what the next step should be, therefore, why can the sitemap
> not be extended with minor conditionals
> similar to the ones in XSLT and make flow decisions in XML versus
> Javascript.

I described how to add some minimal flow handling mechanisms to the sitemap
in the last sections of
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101882151416705&w=2.
The proposal is based on a _very_ light weight kind of continuation passing.

As the few commenter seemed to hate the use of xml to describe flow logic
and the inclusion of flow logic in the sitemap, maybe I should add that one
of course could describe the same concepts in a different syntax and in a
separate (flow description) file.

> I regard this flowmap decision as taramount to multiple inheritance.  I
> think its a decision that will later come to be
> regretted.  I also think I'll be seeing Cocoon applications that are
> virtually implemented exclusively in Javascript instead
> of using the sitemap at all.

I don't know if it is a good or a bad decision (or even if there have been a
decision yet ;) ), to adopt flowscripts. I'm quite surprised that there have
been so little discussion about what they are supposed to be used for. I
guess most people agree about that flowscripts should describe the flow
aspect of webapps, but such a general view doesn't help design much. IMO we
need to be more concrete about the use cases for flowscripts. Without a
common view on what problem they are supposed to solve, it is hard to know
if a certain technical solution is good or not.

So what use cases do we have?

* It should definitely be easy to write wizards in a flow description
language.
I believe this is the case for flowscripts (see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102052662705449&w=2, for
details), but on the other hand this could be done in a much smaller and
more specialized language. Ivelin and Torsten listed some requirements for
wizards, IIRC.

* Shopping carts? This will be possible when Ovidiu (or someone else) have
added variables that are accessible across different flowscript invocations.

* Anything more?

<snip/>
> >No, no, no. With this you are assuming that it's equivalent to use a
> >scripting language to describe business logic. This is yet to be
> >discussed, but this is an entirely different concern from this
> >discussion, thus my call to stop it until we have finished focusing on
> >the flowscript.

AFAIK Ovidiu have always advertised flowscripts as a language for writing
webapps in, which is far more general than just describing flow logic. As
flowscripts can, and most probably, will be used for writing complete
webapps, I can't see that the business logic and the flow description are
different concerns. Keeping the concerns separated at this stage means that
we decide to just discuss "if", "when", "for", "case" and the like in
Javascript and don't care about the effects of introducing all the other
parts of the language.
If we really want to focus on the flow aspect, it is IMO premature to assume
that flowscripts is the right solution, before we know what problem we want
to solve.

/Daniel



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


Mime
View raw message