cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Reid <jr...@agency.com>
Subject RE: Squaring the sitemap circle...
Date Fri, 26 May 2000 13:55:42 GMT
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 classes...is 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.

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.

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'>

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>

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.

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.

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...

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 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.

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!

	>	Jason Reid
		Technical Consultant
		AGENCY.COM
		100 Woodbridge Center Drive, Suite 102
		Woodbridge, NJ 07095
		Email: jreid@agency.com
		http://www.agency.com

		"Do not meddle in the affairs of programmers, 
		 for they are subtle and quick to anger."

Mime
View raw message