cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan <>
Subject Re: [RT] Cocoon Input Model
Date Mon, 01 Mar 2004 19:53:03 GMT
* Stefano Mazzocchi <> [2004-03-01 18:32]:
> Alan wrote:
> >* Hunsberger, Peter <> [2004-03-01 16:17]:
> >
> >>So, bottom line, I don't think Cocoon needs any new sitemap constructs
> >>to do what is being discussed, unless what is needed is a way to do this
> >>without flow?  However, trying to do this without flow seems to me to
> >>mean going back to regular actions, so I can't see any real reason to do
> >>this...

> >I think what is needed is a way to do the following without flow.
> >
> >    deserialize -> validate -> store -> generate -> serialize

> >    I think there is a common idiom that can be expressed as XML.
> >    The sitemap becomes far too difficult to read if the
> >    relationships between pipelines are absent from the sitemap.
> >

> Been there, done that: it doesn't work.
> It's the 80/20 rule: 20% of the job requires 80% of the energy/time.
> What you are describing is a model that is highly simplicistic and 
> cannot be generalized enough.
> Look, nobody prevents you from doing this already today:
>  StreamGenerator -> ValidateTransformer -> StoreTransformer ->

> but then what happens if the validation is not complete? how to you 
> manage that? what is the logic?

As I said, the logic of a failed validator is to launch the error
    pipeline. Just as any uncaught exception in the pipeline
    launches the error pipeline.

> Pretty soon you start doing
>  StreamGenerator -> ValidateTransformer -> Selector -> ...

No because, the document is either valid or it isn't.

> to understand the various types of errors and the complexity of this 
> gets worse and worse over time and you start to realize that your 
> simplicistic mental model was not mapping with real life very well.

> This is exactly why we have flow.

My mental model is simple and abstract but not simplistic. Look at
    it again:

    deserialize -> validate -> store -> generate -> serialize

    This describes most of the form post handling code I've
    generated over the years.

    Let me revise it:

    deserialize -> validate -> store -> generate -> serialize
                !           !        !           !
    error      <-          <-       <-          <-

I'm not talking about adding procedural logic to the site map. In
    fact I'm arguing against procedural logic hidden in the site map
    as flowscript.

    I don't like the idea of flowscript, not because of the
    I am able to write a publishing application with Cocoon using
    chains of transformers, no logic beyond the implicit select
    statement that is the pipeline.

I'm looking for a way to do the same thing going in.

Alan / /
    aim/yim: alanengrm - icq: 228631855 - msn:

View raw message