cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@localbar.com>
Subject Re: [RT] resource views, error handling, pipeline debugging
Date Thu, 29 Jun 2000 05:59:27 GMT
Stefano Mazzocchi wrote:

> Pipeline revised
> ----------------
>
> I recently came to the conclusion our pipe model must be enhanced. The
> pipe currently passes SAX events. These are data events.
>
> I want to add a metaevents pipeline, sort of a logging/tracing pipeline
> where the components throw everything that is related to event
> generation and not event payload.
>
> Example of this are:
>
> - pipeline tracing (knowing what's going on, XSLT messages, FOP page
> generation output, pipeline timings, etc...)
>
> - error reporting (xml non-wellformed, exception inside a component,
> exception inside a server page)
>
> So, every component is given access to the stream of events of the next
> component, plus the orthogonal stream of pipeline metaevents. The
> implementation of this metaevent stream is not semantic abstract like
> SAX but its semantic specific (like any logging class).
>
> Something like
>
>   public interface PipelineLogger extends Generator {
>      public void startPipeline();
>      public void endPipeline();
>      public void trace(Component origin, String message);
>      public void error(Component origin, String message, Exception e);
>      ...
>   }
>
> This doesn't change the shape of the pipeline, but since PipelineLogger
> extends Generator, it is possible to use the "tracing" results of a
> pipeline, XML-ize them and feed them thru another pipeline for
> presentation.
>
> This solves the issue of error handling with multiple user agents. The
> pipeline as a whole becomes a generator for another pipeline.

THANK YOU!!!
I knew it would come to you sooner or later...

It is easy to see/define how a stream is split, but the hard part is how is
it joined back?
And even worse, how is this detailed in the Sitemap??
Tough questions indeed, and I will twist my head some, and see what comes
about later today.

> Resource views
> --------------
>
> Well, with a particular request parameter
>
>  http://myhost/myURI/resource?cocoon:view="xxx"
>
> where all "cocoon:*" names are reserved for future use. It's an XML-ish
> hack. but it works and it's easy to parse and easy to read and easy to
> edit by hand.

Not good to use "cocoon:". I have tried to use : in parameters before, and
you end up with a lot of misunderstanding in many browsers and URL
decoders. For it to work you then have to put in "cocoon%3A" which looks
"bad".


> So, for example a pipeline like
>
>  g -> f1 -> f2 -> f3 -> s
>
> can be refactored as
>
>   [ g ] [ f1 , f2 , f3 , s ]
>   [ g , f1 ] [ f2 , f3 , s ]
>   [ g , f1 , f2 ] [ f3 , s ]
>   [ g , f1 , f2 , f3 ] [ s ]
>
> Sort of pipeline diagonalization.
>
> Why this? well, mainly to reduce verbosity, the components of a view
> might change, but the component of a viewer might not.

And sorry for being an idiot,

If I have a resource;
/abc/def/ghi
and you say that it can be viewed in many ways, how is that different from
'extending' the resource itself;
/abc/def/ghi/complex-semantic
(other than syntactically in the URI)

And if so, could not all you are trying to accomplish, already be done by
matchers?
<map:match pattern="*/complex-semantic">

whereby the $1 is passed into the Generator.

I must be missing something big here, since I don't think you have
overlooked this. (Stefano is not Mohammed - Why go to the mountain, when
you can turn it... :o)

Niclas


Mime
View raw message