Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3D173D22.2B386032@apache.org>
Date: Mon, 24 Jun 2002 17:39:14 +0200
From: Stefano Mazzocchi <stefano@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] SpitScript - B-Logic that doesn't suck   ( Re: [RT]
 Flowmaps)
References: <OFBCD8B822.3A84255A-ONC1256BDE.00359184@at.ibm.com>
 <3D11C2A8.1080600@apache.org> <3D11CA8E.7060908@apache.org>
 <3D11D166.3020201@apache.org> <3D11DC13.5060209@apache.org>
 <3D11FCBE.1030706@alma.nu> <3D121507.2060206@apache.org>
 <3D1250C2.9FD11044@apache.org> <3D133DD0.1060005@apache.org>
 <3D14BFEE.A31E2717@apache.org> <3D15D0EB.7010106@apache.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Andrew C. Oliver" 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.

It could be, yes.

But I find it extremely handy to be able to describe the transitions
using scripting because it allows me to add programmatic logic to the
transition stages procedurally instead of declaratively.

It's just a matter of taste, I agree, the functionality can be
implemented in many different ways, but just like I like Java more than
Scheme or Lisp, I like to write procedural flows rather than FSM tables
(or Turing Machine tapes, for that matter)

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

Yep, 'dynamic sitemap'. No matter how hard I try to look at it, I don't
see a reasonable way to do it without coming out with something so close
to XSP or XSLT extensions.

Both of which proved to be particularely ill-suited for procedural logic
or SoC in general.

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

This last comment of yours makes me think that you probably missed many
key points in the flowscript discussion: the flowmap doesn't have the
ability to assemble pipelines direction, just to call them via sitemap.

You fear something that is equivalent of stating that actions are bad
because you could write the entire cocoon application using a single big
action and not using the sitemap at all (which has been done, BTW)

It seems to me that it's javascript that scares people away from such a
beautiful and elegant concept and I really don't see why.
 
> >I hear you, but since we all agree that business logic shouldn't be in
> >the flowscript, I don't understand the need to discuss whether or not
> >it's good to have business logic defined in a scripting language.
> >
> >This is an entirely separate concern.
> >
> >
> Again, we're discussing something taramount to allowing multiple
> inheritance in Java.  

Multiple inheritance in Java is allowed for interfaces and not for
classes, just like scripting is allowed to augment the sitemap
capabilities but without mixing them.

> The issue is not whether YOU
> Stefano would code your business logic in the scripting language, its
> whether lots of folks would.  And hence creating more
> rediculous and unmaintainable software.  Its possible to create bad
> software in any tool, but some tools enable you to create worse
> software.  Its why Java succeeded despite being far poorer performing
> over C++.  C++ gave you more rope to hang yourself.  Its an underlying
> reason you write Cocoon in Java and not PERL.  PERL allows almost all of
> the features of Java, but it not only allows but encourages bad form.
>  Cocoon has areas that are coded in bad form and without comment, yet
> I'm able to read them moreso than if they were written by the same
> person in PERL for instance.  The point being is that this is one of
> those features that enocourages and allows bad form and will probably
> grow into a beast.

It's interesting that you state this, yet you didn't know the
limitations what are 'hardcoded' into the flowscript concept *exactly*
not to give you enough rope to hang yourself with.
 
> >
> >
> >It's hard to define what a business logic is, but it's easy to know if
> >this has anything to do with describing the transition between pages
> >(flow).
> >
> >
> But a scripting language will allow you to do either.

and actions, dynamic sitemaps or dynamic sitemap extensions.

At least, with flowscript, an abuse can be refactored with little
hassle, unlike abuse of actions which becomes hardcoded into obscure
black art and nobody is able to touch it once it works.

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