Peter Hunsberger wrote:
On Mon, 03 Jan 2005 15:55:23 +0100, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote:
<snip/>
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?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.
Sure, if you don't want to use the sitemap at all, it shouldn't matter if it is declarative or not ;)This basically ends up turning the sitemap into a single match "**" and everything is then looked up based on database mappings to data sources internally to our application. Our case is extreme since everything (and I mean everything) is dynamic; we've reached the point where having to code anything statically doesn't work.
Our next step will be to replace the static pattern of aggregated generators within the match to a dynamically generated aggregation lists. At that point the Cocoon sitemap will be out of our application loop: the generic match will call flow which will get the list of datasources. Flow will essentially do it's own aggregation using processPipelineTo to a Cocoon source and that source will be picked up and sent on to the transformers.
That's lots more explanation than you need, but the essential point is that, for us, having the Sitemap be declarative doesn't gain us anything.
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?
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 ;)
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.
/Daniel
