cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <Giacomo.P...@pwr.ch>
Subject Re: Squaring the sitemap circle...
Date Fri, 26 May 2000 21:03:44 GMT
Jason Reid wrote:
> 
> 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.

How would you distinguish between loading from classpath or loading from
filesystem or even loading out of a jar (not in the classpath)?

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

Why not having <generate> and <serialize> ?

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

Hey Stefano, another way to express <matcher>. What di you think of
this?

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

Now that you say it, there is a <partition> in the current sitemap (not
the proposal we are discussing now). Stefano, what was the purpose of
that <partition> tag in the early stages?

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

Are you mixing content with style. Leave it to the stylesheet to put in
headers and footers. Except they contain dynamic content. the I would
suggest using XSP instead.

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

Yup, you gave the answer yourself. We could also loose the ability to
selve different clients.

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

Giacomo

-- 
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7                     Mailto:Giacomo.Pati@pwr.ch
CH-8166 Niederweningen                    Web:   http://www.pwr.ch

Mime
View raw message