cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierpaolo Fumagalli <p...@apache.org>
Subject Re: [finally!] The "Infamous" Cocoon Sitemap Proposal
Date Wed, 29 Dec 1999 15:01:27 GMT
Stefano Mazzocchi wrote:
> 
> [...] But, of course, I plan to finish it much earlier that that :)

Hopefully... I want to see something working sooner than that...

> So, here we are: the following is written by me [...]

Taking credits for what you didn't do???? I wrote the XML example file
down there :) :) :) hahahaha

> [...] (please, refer to the interfaces on the xml-cocoon2
> branch for more info on the design patterns that go after this, or look
> at the Avalon sources)

I'm updating them.... A couple of interfaces are nedeed, and a couple
need to be modified (like Changeable, needing to return a date, instead
of a boolean, so that we can better use http client side caching... More
on this later.)

> 2) the pattern logic will be pluggable. There will be a way to implement
> "pattern matchers" that implement the following interface
> 
>  public interface PatternMatcher {
>    boolean matches(String str, String pattern);
>  }

Hmm... I don't like that, because this doesn'd give informations on
rewriting (see below, <process uri="pattern" translate="..."/>).
This is nedeed to enable xlink "soft" support (I don't see it in this
E-Mail), that is a mechanism to automatically rewrite links in source
files.
For an example, see below...

>  <producer name="file">
>   <param name="mount-point" value="/home/www/xdocs"/>
>  </producer>

Don't be tweaked by this parameter... The mount point will be specified
thru the "translate" attribute in <process uri="..." translate="..."
.../> later.

>  <filter name="xslt">
>   <param name="stylesheet" value="sheets/page-html.xsl"/>
>  </filter>

That's good :)

> 2) components must implement interfaces of the form
> 
>    org.apache.cocoon.component.type.Type
> 
> and the component is registered with the role "type" in the
> ComponentManager

I believe the interface is declared in org.apache.cocoon.component.Type
class (why are you using also a package with the same name of the class
here?)

> 3) <process uri="..." translate="..."> applies URL very simple URL
> rewriting. For example, given the URI /docs/cocoon/index.xml the element
> 
>  <process uri="*/*.xml" translate="/usr/local/www/*/new/*.xml">
> 
> matches the given URI and rewrites it to
> 
>  /usr/local/www/docs/cocoon/new/index.xml

Here's the stuff I was saying before... Let's say I have this:

<process uri="/*.html" translate="/home/www/*.xml">
  <producer name="file"/>
  <filter name="xslt">
    <parameter name="stylesheet" value="xml2html.xsl"/>
  </filter>
  <serializer name="html"/>
</process>

Then I have this source document called /home/www/doc-1.xml:

<document>
  <paragraph>
    I like this document but <link href="doc-2.xml">this</link>
    is even nicer.
  </paragraph>
</document>

And a document called "/home/www/doc-2.xml" that is linked to the first
one.
To request the first one, I have to ask cocoon for "/doc-1.html", this
name gets translated to "/home/www/doc-1.xml" that is produced, styled
and formatted in html. But in the target html I have to translate
  <link href="doc-2.xml">
into
  <a href="doc-2.html">
Of course, I can do this into the xml2html.xsl style, but it's kinda
stupid, because if I change the rules in the sitemap, I also have to
rewrite also the styles that "convert" links.

While, if we can have a some kind of "url rewriting" in cocoon, that
derives those rules from the sitemap, all the process can be more clean
and our xslt styles can just ignore how those are handled.

We already have a some kind of solution for this, I'll detail it later
in another E-Mail.

> [...]
> All right, this is, for us, a complete proposal. Nothing that has been
> proposed for Cocoon cannot be done in this sitemap. I'm very proud of
> this and I think that Pier and I did a good job, but we'll be very
> welcome to clean it up further and test its strenght thru public review.
> 
> So, let's see how solid this is :)

The question is "please fire on the sitemap and show us how stupid we
were forgetting about this and that :) :) :)"

	Pier



Mime
View raw message