Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Tue, 2 Mar 2004 11:01:58 -0500
To: dev@cocoon.apache.org
Subject: Re: [RT] Cocoon Input Model
Message-ID: <20040302160158.GD22813@maribor.izzy.net>
References: 
 <1E0CC447E59C974CA5C7160D2A2854EC097DA2@SJMEMXMB04.stjude.sjcrh.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <1E0CC447E59C974CA5C7160D2A2854EC097DA2@SJMEMXMB04.stjude.sjcrh.local>
User-Agent: Mutt/1.4.1i
From: Alan <alan-cocoon-dev@engrm.com>
Mail-Followup-To: dev@cocoon.apache.org

* Hunsberger, Peter <Peter.Hunsberger@stjude.org> [2004-03-01 22:06]:
> Alan <alan-cocoon-dev@engrm.com> writes:
> 
> <snip/>
> 
> > > > There is already flow logic in the site map. The pipeline is a
> > > >     select statement. It is a clear expression of the pipelines
> > > >     intent.
> > 
> > > Ok, that's where we differ.  Our pipeline does not implement a
> > > select statement.  You can't, in general, look at our
> > > pipelines and determine what will come out of them.  Even
> > > prior to implementing flowscript all you could tell was that a
> > > certain sequence of generators and transformers would be
> > > called (I guess that's what you call "pipeline intent").

> > > However, once you have flow I don't see what that buys you?

> > > We can still determine that, but instead of starting at the
> > > sitemap we start at the flowscript: all flow starts from the
> > > same point in the sitemap: "*/**" --> call function(main).
> > > Half a dozen special case pages branch somewhere specific in
> > > our flowscript, the rest end back at the same point in the
> > > sitemap: "_page/*" --> generate --> transform --> serialize.
> > > Really, very easy to understand.  (BTW, when we implemented
> > > flow our sitemap shrank in size by half or more.)
> > 
> > Okay, I think I can see that model.
> > 
> >     I put a lot of information into the URI. It makes for
> >     permalinks. An application can be expressed in the sitemap
> >     matching.

<snip/>

> > I'm putting a lot of my logic in my XSLT transforms, I guess. I like
> >     to have it all my logic in one place. I like that each step
> >     along the way produces a document, which can be viewed in the
> >     browser as XML. I like the declaritive nature of the pipeline
> >     content.
>  
> I suspected you might be an XSLT heavy :-)  If you do a search of the
> dev archives you'll see I argued for a long time to be able to write the
> flow engine in XSLT...  I'd still like to do that; we've got a work flow
> project on the books that will require the same kind of generic rule
> based business logic for work flow that we do for data handling.  It
> would be nice to hook it into the same generic rule handling we
> currently have.

> > I am using the matching facilities agressively. It is how I see a
> >     web application. A GET are function calls, the URI's are the
> >     function signatures, the pipelines are the function bodies. Its
> >     stateless functional programming to me.
> 
> Well, yes, but you're encoding application logic in the sitemap.  That
> just doesn't scale;  the sitemap isn't supposed to be a programming
> language.  REST is fine, but flow isn't anti-REST (RESTless ?)...

It's a pity that it doesn't scale then, because it's been a nice way
    to do things.
    
    I'm not putting much logic in the sitemap except to
    match the path part of the URI. Parameter handling is done by
    whoever intercepts the path. Most of my logic is in XSLT.

    I came to Cocoon from XSLT. I was already chaining
    trasformations. I'd made the most of a little matching engine
    I'd written. I'm using Cocoon thus.

    Flow isn't anti-REST, but, yeah, the sitemap looks like a REST
    method dispatch engine.
    
    Maybe that is what I want. Maybe its easy to do this in flow,
    and if I want to be declartive, my flowscript can read a
    configuration file.

> >     The way I've implemented POST in the pass is to go forward or to
> >     return the post data with error messages. A single form contains
> >     data for single post. I rarely see a need to branch after success.
> > 
> >     Flow doesn't play a part in who I *intend* to use Cocoon. I'm
> >     not that far into it yet.
> 
> Well, I guess I'm telling you that you should maybe think about changing
> your direction....

I see that. I am thinking about changing direction.

Two things.

    1) I jumped into this because it was a discussion of input
       pipelines and I was interested in it in terms of Momento.
       
       I know there is some use of XUpdate in Cocoon, but that is
       the preferred language for Momento. I see the penultimate
       step in an input pipeline as a transform to XUpdate, the
       ultimate step a call to Momento.
       
       I think if someone were to develop a simpiliar declartive
       language to describe a complex set of SQL updates in XML, one
       cold use the same notion to update an SQL database. This,
       rather than writing loops, JDBC calls, and such in Java.

    2) I see that this is more of a disucssion of the
       deserialization and form validation. I will be able to do the
       above. Nothing is going to move out from underneith those
       plans while I'm implementing them. 

Also, thanks for all the knowledge.

-- 
Alan / alan@engrm.com / http://engrm.com/
    aim/yim: alanengrm - icq: 228631855 - msn: alanengrm@hotmail.com