cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: [RT] resource views, error handling, pipeline debugging
Date Fri, 30 Jun 2000 04:07:03 GMT
Stefano Mazzocchi wrote:

> > > 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...
> Hey, how unfair, I'm not that slow... :)

We were spawning (!) on this idea a year ago, but at that time, I didn't manage
to crystalize the concept in the foggy situation that was prevalent at that
time. Somehow, someone managed to convince me to drop the idea, probably because
of the DOM-centric processing which it was based upon.

> > 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??
> :-? Sorry, I don't understand you here.

My issue right now is, where does the MetaData stream end up?? How about it is
added at the end of a document if a particular parameter is set (debug)
otherwise not.

Then, when I started to look into the details of how this would work, there is
another complex matter.

The sequence of execution in a SAX based environment is not Pipelined per se. In
fact, there is not much you can say about the order of execution of everything.
Some processors in the pipeline receives a tag, and calls the processor
immediately down the line with the same tag, other will collect a whole bunch of
nodes, then do some processing, followed by spitting out hundreds of SAX events.
And so on.

The MetaData event stream will be something similar, but how would that stream
synchronize with the Data event stream? The XSLT processor have no clue when
the Xalan holds SAX events.

Let's say it is very foggy, and hours of thinking has not made it any clearer,
in fact the opposite.

> > 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".
> Damn. Any suggestion?

I basically agree with the dash (-) that you are using below.

> > 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.
> Yes, yes, you are totally right. The "view" element is completely
> redundant, it doesn't add functionality you didn't have with
> matchers.... but it gives you a way to focus more on it.
> Call it syntax sugar. Call it "Stefano would like you to see resources
> as multidimensional objects with different views as orthogonal
> projections".
> In fact, both filters and generators are "xml producers" but we
> introduced the notion of them to simplify and crystalize a vision of
> them.
> I'm trying to do the same with these views.
> Let us suppose it's not.
> How would you generate your site for off-line viewing? Cocoon offline
> mode requires you to give it xlinking information in order to be able to
> browse the site. And all URIs must follow a very specific pattern,
> something like (this is pseudosyntax, just as an example)
>  <match uri="a/b">
>   ...
>  </match>
>  <match uri="a/b/off-line">
>   ...
>  </match>
> and you must do this for all of your matchers since rarely the xlinked
> view and the normal view are the same and require the same pipeline to
> be generated.
> So, by creating the "view" notion and the view/viewer elements, I wanted
> to be able to reduce verbosity by introducing recurring concepts, also
> avoiding errors due to wrong use of URI spaces.
> <view> defines a contract between users and URI spaces.


> So, given HTTP, we have to modify the URI. A URI is composed by
>  http://host:port/path/resource?query
>   3) resource (what Niclas proposes)

Not really what I proposes...

>   4) query (what I proposed)
>      path/resource -> normal view
>      path/resource?cocoon-view="tracing" -> tracing view
> So the choice is between 3 and 4.

but again, <map:match pattern="*?cocoon-view=tracing">
is then the same thing??? (presuming now that ? and = is not part of regexp.)
And what you are trying to achieve is syntax reduction.

> Admittedly, 3 has some advantages since it's independent on the HTTP
> action and can be safely included in links, but also disadvantages since
> it could create naming conflicts.

The naming conflicts would be equivalent, and method 4 is less so, due to a more
limited "namespace", which could be introduced in method 3 as well,
/path/resource/cocoon-view/tracing, and the corresponding

The whole exercise as I see it is two fold;
a) Reduction of syntax (verbosity) to clarify for the admin what the purpose of
the construct is for.
b) Introduction of a 'notion' or 'concept' that otherwise would be
recommendations. By introducing the 'feature' straight into the syntax, one will
highlight the use.

Now, this has led me into another deduction. If the 'view' concept can be
achieved with the existing (interesting concept - "existing" in future tense)
matching proposal, could then this 'extension' be pluggable into the sitemap
specification? (Smells golden hammer, I know).

But assume for a second that each tag in the sitemap is handled by a component
defined in the cocoon.xml (or actually in a separate
sitemap-config) configuration, it would allow for interesting possibilities of
the future. The drawback?? I don't know at this moment.

> >(Stefano is not Mohammed - Why go to the mountain, when
> > you can turn it... :o)
> I know somebody would have said that, I just wanted to see who was the
> first one :)
> I guess the mountain twisting idea shows my egocentricy, doesn't it? :)

I tell you what.... It is easier to influence you than the mountain, that is for
sure. Not sticking to principals, just for the sake of it, like mountains does.


View raw message