cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: [RT] Cocoon Input Model
Date Mon, 01 Mar 2004 20:01:11 GMT
Alan <alan-cocoon-dev@engrm.com> writes:

<snip/>

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

Only for simple validation, there's lots of corner cases where things
aren't that clear cut.  For example, our validation code can also
generate warnings.  Things like migrating from one version of name space
to another, or from one document encoding to another make determining
what is "valid" pretty complex... 

<snip/>

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

Then why exactly?

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

Just a suspicion, but when you say "chains of transformers" I suspect
there are many of these chains?   



Mime
View raw message