cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)
Date Mon, 24 Jun 2002 16:33:10 GMT
Daniel Fagerstrom wrote:
> 
> 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.

Hmmm, I wish I was allowed to send you my 58Kb sitemap used to control
the flow of 4 URI familites (4 mathers)! 

Anyway, that sitemap had 12 levels of nesting, matchers with 110 lines
each and I had to write a special transformer and 4 different actions.
Actions that were 10/15 lines each.

With the flowscript, I estimate to be able to refactor the entire thing
in a third of the sitemap code, no actions and a few Kbs of javascript.

And there is no business logic whatsoever there, just page transitions
based on system status (the entire business logic is contained in java
objects).

Now matter what, it will be hard to convince me that using the XML
syntax is a good idea to describe simple procedural logic.

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

Hmmm, I think I missed this. I'll go over it again.

> 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 would not be against this, just I think Javascript is the best
compromise so far because it doesn't force people to learn a new syntax.
 
> > 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.

Good point.

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

what? is your web-app world limited to multi-pages and shoppint carts? I
can believe that. No wonder why you think that the flowscript is FS. For
those things it might well be.

Think granular: you are talking about 'pieces' of web applications. I'm
talking about web applications all together. Think of a on-line banking
system, think of a webmail, a calendar, an administrative intranet, a
revision control system for air-2-air NATO missiles platform spare parts
(yes, I did consulting for that once!)

There is no need to write a flow for something so simple as a data-entry
wizard or a shopping cart. In fact, those are *exactly* those webapp
components where flows can be standardized and reused with little
hassle.

But I'm talking about the webapps: suppose you are hired by a company
that does this revision control system for missiles platforms. It's a
huge military system that connects to spare part databases located
around the planet, thru kick-ass crypto extranets, you have vector parts
transformed into VRML2 and you can know who, when, why and how changed
the spare part 3849484984489 of that missile.

Now, suppose you want to *understand* what's going on: how you move from
page A to page B and why, what can errors are catched, what things can
go wrong, what is called to obtain this data and how.

You *do* *not* care *HOW* the pages are created. First thing you want to
find out is how the system behaves. And 'web app behavior' is the
description of the flow, not the description of the sitemap.

So, your learning process would be something like:

 1) use the webapp
 [learn cocoon] (optional if you already know this)
 2) learn the flowscript
 3) learn the sitemap

Believe me: today there is *NO* web technology that allows this simple
course of action to get productive on a system, or to estimate in a
short term the complexity of the system in question.

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

Hmm, we might be having a terminology impedence mismatch here.

I call 'flow logic' the logic that describes the transition between
states of a web application (sometimes these states map to changes in
pages, sometimes they do not, but the state changes). In this sense, a
flow logic is a white box.

I call 'business logic' the logic that describes how data is created,
handled, managed, kept secure, consistent, persistent. In this sense, a
business logic is a black box.

Example: a webmail is a web application that shows a web view of a mail
server. The business logic is the 'mail server abstraction'. The objects
you call to get access to the underlying data. In case of an IMAP
server, this is a think layer that makes a client IMAP, in case of a POP
server, the layer is bigger because it has to simulate the mail
repository.

The flow layer simply connects the web layer to the underlying business
object layer. It might become quite a complex logic, but the 'juicy'
mail-related logic is contained in the underlying model.

Nobody stops you from writing everything (even the mail business logic)
inside the flowscript, just like nobody forces you to use object
orientation in Java (you can have one single class to do everything!),
but this doesn't mean that OO for Java is FS.

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

Hope the above definition of the terminology explains my vision better
because I think that writing a complex business logic using the
flowscript would be such an evident suicide that it would be our fault
if someone does it.

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

I know what problems I want to solve: the sitemap poorely describes
procedural flow logic. So far, I've not seen any better solution than
the flowscript.

As far as the 'SpitScript' and this thread: writing business logic (as I
defined it above) in the flowscript is such an evidently terrible idea
that I don't even think it's worth talking about it at this point.

It's like stating that map:readers lead to FS becase you could write an
entire cocoon replacer as a reader.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Mime
View raw message