cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marco Rolappe" <>
Subject AW: [RT] Forwarding of internal pipeline calls
Date Mon, 08 Mar 2004 12:32:09 GMT
I don't really want to delve too deeply into this (the mail would become
very long ;-) but...

the core problem IMO is the current concept(s) of the sitemap; I had that
feeling already when starting with Cocoon, hearing about the 'sitemap' and
then looking at it and being confused.

and when seeing a proposal like a separate protocol for forwarding I find it
fairly obvious that there's something wrong.

one of the core problems I see is missing SoC. the most powerful thing and
the core concept (for me) are the processing pipelines; they are supposed to
produce a deliverable response by using a generator, transformers and a
serializer. the missing/weak SoC IMO already starts with Reader's; these
haven't really anything to do with (XML/SAX) processing pipelines.

I think the reason(ing) for forcing Reader's into the pipeline concept
already leads to the core problem; requests are always mapped to pipelines.

I don't know what you people use internal 'redirects' for, but I mainly use
it for delegation or aliasing respectively. the reasoning for internal
'redirects' I assume are the same as for Reader's. force everything into a
pipeline (which still is an XML processing pipeline).

all of it would be so much cleaner, more elegant, more
maintainable/resuable... if concerns were better separated; declaration of
URI space handled by sitemap (think contract/interface), definition of URI
space (think implementation, including useful concepts like inheritance),
definition of processing pipelines and respective pipeline components.

you would map URIs/requests, e.g. to 'request processors', not directly to
pipelines (which are still XML processing pipelines ;-) here you could
eliminate the aliasing internal 'redirect'; you just map a set of requests
to the same processing:

"foo(*)", "bar(*)" -> pipeline baz(param: {1})

the delegating internal 'redirect' wouldn't be needed anymore since you
could directly call pipelines by name (which is also more maintainable than
making it part of the URI space). think of <map:pipeline

or you map to a flow controller, or to a reader, ...

there's so many problems such a cleanup would solve...

I've been thinking about it for a while and I'm considering starting an
alternative Processor implementation.

example snippet (<map:resource> converted to a serializer):

	// serializer contract: SAX input, no SAX output
	serializer amore2pml
            xsltc  src: cocoon://emotion/core/stylesheets/layout.xsl
            cinclude  support-caching: true, expires: 86400
            xsltc  src: stylesheets/vodafone-de.xsl, contextpath:
            xsltc  src: stylesheets/adapt.xsl
            i18n  locale: de
            xsltc  src: cocoon://emotion/core/stylesheets/amore2pml.xsl,
service-name: eMotion

	// generator contract: no SAX input, SAX output
	generator header(which)
		file src: headers/{which}.xml		// use file generator

	generator footer(which)
		file src: footers/{which}.xml

well, I'll stop now...

> -----Ursprungliche Nachricht-----
> Von:
> []Im Auftrag
> von Carsten Ziegeler
> Gesendet: Montag, 8. Marz 2004 12:31
> An:
> Betreff: RE: [RT] Forwarding of internal pipeline calls
> Unico Hommes wrote:
> > I am just thinking whether it'd be worth a separate protocol
> > something like forward://something ?
> >
> Yes, I thought of this as well. Unfortunately we have to many hardcoded
> places, where against the protocol name "cocoon:" is tested. So if
> we provide a new protocol we have to change all those places as well.
> And we have to come up with a good name, as
> <map:generate src="forward://something"/>
> might look at little bit strange :)
> Carsten

View raw message