I've wrestled with similar problems for a while with my content management system, which uses a database for content and structure. I'm in the process of setting the system to use file extensions for the client to specify the file type and have Cocoon return that type. If they request /a.html, they get html, /a.pdf and they get pdf, and so on. This seems elegant, but it has problems when you consider the points covered in the slashforward article. Here's the compromise I've come up with so far, adapted to a filesystem like you're using. I'm still toying with these ideas, so i'd like to hear comments.
1) Instead of having directories with index.xml files, have a directory and an xml file with the same name at the same level.
so you have /a/b/ actually returning /a/b.xml. you could map a request for /a/b/index.html to /a/b.xml as well. This way you can add a leaf, and if you need to later add sub-nodes, and turn the leaf into a node, you just add a directory and some files underneath it.
2) Redirect all urls to *not* end in a slash. I see the point of the article you've linked to, and agree with it, but the file extension is the only form of file meta data that's pretty standard. Ending all urls in slashes only works, in my opinion, if all the files are the same type, if not it's really nice to have a way of identifying the type from the url, not just the mime-type response header. So considering that any request is going to point to a leaf (or an error page), then I would redirect /a/b/ to /a/b.html
This way the extension isn't revealing the underlying technology of the site, but the type of file the client is expecting, and this goes for directories too.
The matchers would look something like this: (i might have this wrong)
<map:match pattern="**/">
<map:redirect-to uri="{1}.html"/>
</map:match>
<map:match pattern="**/*.html">
<map:generate src="documents/{1}.xml/>
<map:transform src="stylesheets/page2html.xsl"/>
<map:serialize type="xhtml"/>
</map:match>
Add matchers, or use selectors, for more file types.
-Justin
On Thursday, November 7, 2002, at 02:57 PM, Tony Collen wrote:
Apologies for the extra long post, but this has been bugging me for a while.
First, some background:
I'm attempting to put together a URL space using cocoon that will allow users to drop an XML file into a directory, say $TOMCAT_HOME/webapps/cocoon/documents/ and have it published. This is easy enough:
<map:match pattern="*.html>
<map:generate src="documents/{1}.html"/>
<map:transform src="stylesheets/page2html.xsl"/>
<map:serialize type="xhtml"/>
</map:match>
So then I decide that for organization's sake, I want to allow people to create subdirectories under documents/ any number of levels deep, and still have cocoon publish them. This is also fairly simple:
<map:match pattern="**/*.html">
<map:generate src="documents/{1}.html"/>
<map:transform src="stylesheets/page2html.xsl"/>
<map:serialize type="xhtml"/>
</map:match>
However, later I realize that using file extensions is "bad". Read http://www.alistapart.com/stories/slashforward/ for more info on this idea.
This creates problems with how I automatically generate content using Cocoon. I want to allow people to create content arbitrarily deep in the documents/ directory, but I run into a bunch of questions.
Should trailing slashes always be used? I think so.
Therefore: Consider an HTTP request for "/a/b/c/".
1. Is it a request for the discreet resource named "c" which is contained in "b"?
2. Is it a request for the listing of all the contents of the "c" resource (which is in turn contained within "b")?
3. Is this equivalent to a request for "/a/b/c"? 3b. Should a request for something w/o a trailing slash be redirected to the same URL, but with a trailing slash added?
Using the "best practice" of always having trailing slashes creates problems when mapping the virtual URL space to a physical directory structure. Considering a request for "/a/b/c/", do I go into documents/a/b/c/ and generate from index.xml? Or do I go to documents/a/b/ and generate from c.xml? Having every "leaf" be a directory with an index.xml gets to be unmaintainable, IMO.
Likewise, do I generate from documents/a/b/d.xml or documents/a/b/d/index.xml for a request of "/a/b/d"? Additionally, what should happen when there's a request for "/a/b/"? Obviously, if the subdirectory "b" exists, it would not be correct to go to documents/a/ and look for b.xml.
Part of my reasoning behind all these questions lies in my quest for creating an uber-flexible "drop-in" directory structure where people can simply add their .xml files to the "documents" directory and have Cocoon automagically publish them, as I stated above. The other reason for this is that I'm trying to devise a system which automatically creates navigation, as well. I've looked at the Bonebreaker example, and it's good, but has some limitations. What if I don't want to use the naming scheme they have?
Oh well, thanks for listening to my ramblings, and hopefully I can get some light shed on this situation, as well as have a nifty autonavbar work eventually :)
Regards,
Tony
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
--------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
