cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Squaring the sitemap circle...
Date Fri, 26 May 2000 15:38:06 GMT
An improved version of the sitemap has been just placed on the CVS
cocoon2 branch. I will refert to that one from now on.

[P.S. Am I the only one or the CVS commit emails stopped functioning?
It's a nightmare to work like this with blink CVS commits]

Jason Reid wrote:
> I'm basically just a lurker on this list, but last night
> I decided to take a close look on the sitemap, and to think
> of as many points that I could raise about it.  So, I loaded
> it up, tweaked and twiddled with it for a couple of hours,
> just to see what I would have done differently, and if I
> found anything interesting.
> Now, I must first say that I was totally standing on the
> shoulders of a giant with this one...I don't think I would
> have ever come up with something like this on my own, even
> though I've bought into the concept of the 'sitemap' since
> I first heard mention of it on this list.
> So, anyway, in order of least impactful to most impactful,
> here's what I've found.
> 1)  classpath: (or is it classpath://) prefixes to the
> component this really necessary, or does it
> just add verbosity?  It would seem to me that without
> any prefix, the class 'org.xml.apache.cocoon.Whatever'
> should be loaded from the classpath by default.

I added a namespace mechanism to do this on the latest sitemap WD.
> 2)  'matcher' vs 'match' tag:  In the component definitions,
> you have generator, filter, serializer, and matcher.  Under
> the process definitions, you have generator, filter, serializer,
> and match tags.  Just for consistency's sake, I probably would
> have kept 'matcher' under the process definitions.

Either this, or, move all the actor elements into verbs.

<generators> ---> <generate>

and so on. I like this one most since it also allows different
validation to be performed.
> 3)  matcher rules:  Match tags are of the form:
>         <match type='browser' accepts='text/vnd.wap.wml'>
>                  and
>         <match type='load' greater-then='2.5'>
> I think that putting attributes like 'accepts' and 'greater-then'
> in the Sitemap Schema would make it difficult to make new matchers
> without simultaneously evolving the schema.  I would think the
> following, while a little more verbose, is more extensible:
>         <match type='browse' rule='accepts' value='text/vnd.wap.wml'>
>                 and
>         <match type='load' rule='greater-then' value='2.5'>

Good suggestion, but read my previous message on this one.
> 4)  I'm sure this has come up at least once before, but the ability
> to specify some sort of 'defaults' for filters, serializers, etc.
> would be nice.  I'd propose something along the lines of:
>         <partition mount-point='/'>
>                 <configuration>
>                         <defaults>
>                                 <serializer type="html"/>
>                         </defaults>
>                 <configuration>
>                 <process uri="*">
>                         <generator type="parser" src="./*.xml"/>
>                         <filter type="xslt"
> src="./stylesheet/standard.xsl"/>
>                 </process>
>                 ...
>         </partition>

Oh, good point for component defaults. I will think about it... hmmm,
how about "process" inheritance?
> 5) Actually, the above also introduced the concept of the "partition",
> which is sort of an internal 'mount'.  The point of the partition is to
> be able to specify a set of configurations (security, defaults) for
> all of the processes under a particular URI space.

I removed the concept of partitions since now the partition is the local
sitemap. If you need to differentiate security and configurations, you
need to "mount" another sitemap.
> 6) Nested matchers have been mentioned before, so I'll just echo that
> sentiment.  Other discussions have already mentioned techniques for this,
> so I'll let that thread carry on elsewhere.

Ok, I'll make a follow-up summary later on.
> 7) Multiple generators:  Ok, now I'm pushing it, I know.  A lot of work
> I have done recently is done by way of 'componentizing' the display to
> the user...a good comparision is Jetspeed, where each 'portlet' knows how
> to display itself, but they are assembled into a 'document' containing many
> of them.  I've not actually used Jetspeed yet, but I would guess that the
> different 'components' know little about the overall layout of the document,
> and even less about the behavior of other components.  Anyway, instead of
> just having a single generator under a process, I envision something like
>         <process uri='*'>
>                 <generator type='parser' src='./*.xml'/>
>                 <generator type='parser' src='./footer.xml'/>
>                 <generator type='parser' src='./header.xml'/>
>                 ...
>         </process>
> This is probably drastic, and goes against the grain of the pipeline, but
> I'm just talking here...

strong -1

this is _not_ something that should go into the sitemap, but rather in a
page that has a bunch of <xinclude> embedding tags. Each URI has one and
only one generator. Anything else is FS!

> 8) Of course, if the above is implemented, and everything is broken down
> into
> display 'components', then there is nothing that has an overall view of the
> 'document'.  How does the system know which image in the navigation bar
> should be highlighted?  This isn't a property of any one component, but is
> a property of the document itself.  This would have to be solved.

This shows you one of the problems with removing the URI from its
central place.
> This might sound sick, but it's the first thing that came to mind:
>         <process uri='/homepage'>
>                 ...
>                 <generator type='inline><![CDATA[
>                         <navigation-element>HOME</navigation-element>
>                 ]]>
>                 </generator>
>         </process>
> I _know_ that this is nothing like your vision of the sitemap...the
> sitemap is for sitemapping, not for content generation!  I was
> more or less just tossing it out there.

Good try but I personally thing this is a very dangerous path.
> Anyway, those are my initial thoughts and reactions.  If nothing I've
> suggested makes it in, but it at least makes you think about something
> in a slightly different light, it will be worth it.  Cocoon 2 is shaping
> up to be a terrific beast, so keep at it!

You bet :)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message