cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <>
Subject Re: Splitting xconf files step 2: the sitemap
Date Tue, 04 Jan 2005 14:45:20 GMT
On Tue, 04 Jan 2005 13:25:05 +0100, Daniel Fagerstrom
<> wrote:
> Peter Hunsberger wrote:
> >On Mon, 03 Jan 2005 15:55:23 +0100, Daniel Fagerstrom
> ><> wrote:
> >
> <snip/>
> >>Somewhat RT I believe that the pluggable matchers in the sitemap is FS
> >>and do more harm than good. I'm certain that there are edge cases where
> >>it is usefull to plug in special pupose matchers and selectors. But the
> >>disadvantage is that the sitemap not is declarative in its mapping
> >>between URI:s and pipelines and as a consequence it is not possible to
> >>ask the sitemap anything about its URI space.
> >>
> >>
> >
> >This is an interesting point.  I wrote a couple of weeks ago about a
> >"generic" generator and I finished up a basic implementation over the
> >holidays.
> >
> I didn't understod the difference between your generic generator and the
> file generator, both uses a cocoon source, checks if it is XMLizable and
> generate SAX from it, what am I missing?

Not much, except that our sources come from a database and are
wrappers around a Cocoon source that contain other information.  The
biggest thing is the way we handle caching, it's essentially a two
stage source look up, the source itself can generate an internal cache
key that our generic generator can use to look up the source.

This all could be pushed into a source resolver, but I don't see any
advantage over doing this in the generator: I don't need another
protocol and I'd write essentially the same code whether I extend the
file generator or write the source resolver.  If we had many different
ways of doing this a source resolver would make more sense, but as it
is, the code and the URL space are cleaner using a generator.

<snip>dynamic sitemap example</snip>

> Sure, if you don't want to use the sitemap at all, it shouldn't matter
> if it is declarative or not ;)

Fair enough...

> What I find most important ATM is to make simple things simple to achive
> in Cocoon. For me and my colleagues, Cocoon in most cases already is
> powerfull enough. But for many simple and common use cases there are
> rough edges that decreases productivity and makes the threshold for
> being able to start using Cocoon unnecesarily high IMO. So if your use
> case can illuminate some isue that can make Cocoon simpler to use for
> basic use cases I'm interested, but if it as extreme as you say, I'm not
> within your target audience for this.
>                             ---o0o---
> Anyway, sometimes when I need to refactor or add functionallity to some
> of our Cocoon applications, where I or colleagues of mine have written
> endless sitemaps, I have felt that it would have been nice if the
> sitemap would have been more declarative so that I could have asked it
> basic things like geting a list of what URLs or URL pattern it handles.
> Also if I have an URL in a large webapp and it doesn't work as expected
> it can require quite some work to trace through all involved sitemaps to
> see what rule that actually is used.
> Of course I understand that if I used a set of efficient conventions
> about how to structure my URL space and my sitemaps the problem would be
> much less. Problem is that I don't have found such a set of conventions
> yet. Of course I'm following some kind of principles, but I don't have
> anything that I'm completely happy with yet. Anyone having good design
> patterns for URL space structuring and sitemap structuring, that you
> want to share?

We have conventions that use sort of type extensions on the names:, patient.list, patient.edit where the search, list,
edit (and other) screen patterns are common across many different
metadata sources (in this case patient). We don't do match *.edit
directly in the sitemap (any more) but I find that if you've got to
handle orthoganal concerns then x.y.z naming patterns can sometimes
help.  The problem for us, is as you allude to at the start of this
thread: Cocoon takes the first match, where what you really want is a
more XSLT "best match" type of handling; sometimes *.a, *.b, *.c works
and other times it's m.*, n.*, o.*...

In the past that has lead me to suggest a sort of XSLT flow, but
thinking about it in this light I wonder if what I really want is just
XSLT sitemap matching (same thing in the end)...

> >  A year ago I wouldn't have dreamed of abusing Cocoon in
> >this way, but I can't see any nice way around it for what we need to
> >do...
> >
> >RT: writing this I wonder if there would be some new method(s) you
> >could add to pluggable matchers so that they would behave
> >declaratively?  Essentially, at a Cocoon internals level you'd need
> >some kind of semantics/grammar for a matcher to tell Cocoon how it was
> >matching.
> >
> Should be possible.
> > Then you'd also need a way for flow functions to communicate
> >that same information since flow can behave as a matching component
> >also.
> >
> Don't feel any itch to support perverse use cases ;)

Hey, I wouldn't call flow perverse... ;-

> >  What this would gain you would be way to, after the fact, get
> >Cocoon to generate the equivalent of the declarative map that you
> >could at least use for debugging and documentation purposes...
> >
> That would be a step forward.

It occurred to me in the shower this morning that the other way to do
this would be to use sub-sitemaps and have the sub-sitemaps generated
by some kind of Cocoon startup/bootstrap process.  In our case, the
actual URL space doesn't change unless someone edits the metadata,
which on a production system doesn't happen very often (a couple of
times a month, except for release boundaries).  In that case, if the
sitemap can be produced programmatically from a database then every
match can be completely explicit.  Of course this just inverts the
problem of managing the grammar:  now this new sitemap builder has to
know the grammar instead of the new matcher methods, but it somehow
seems like maybe a cleaner solution?

Peter Hunsberger

View raw message