forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: Link-Addressing, and breaking up the sitemap
Date Thu, 05 Sep 2002 12:40:31 GMT
On Thu, Sep 05, 2002 at 09:51:55AM +0200, Marc Portier wrote:
> Jeff Turner wrote:
...
> >This sounds much like Marc's siteplan idea
...
> it does, I have felt some resent to the idea of generating 
> sitemap contents though, so I'm trying to find solutions that do 
> not require that, yet still solve the issues we are facing...

Yes,  trying to 'hide' the sitemap could just introduce a layer of
complexity and get in the way.

...
> >One issue..
> >
> >I think it should always be possible to use Forrest sites offline or
> >online. For this to work, links to external things like javadocs need to
> >work 'statically' as well. It's no good having links starting with
> >'/jdoc', because in a static site they'll be interpreted relative to the
> >site root, not the forrest root.
> >
> 
> Well hidden in another side-track of this thread I launched 
> another solution for this to Nicola (he has the cocoon CLI knowledge)
> 
> <snip 
> from="http://marc.theaimsgroup.com/?l=forrest-dev&m=103097448015510&w=2">
> 
> >> by the way Nicola: the CLI should also be the one that
> >> "relativizes" all the none http://-leading hrefs in our
> >> generated html as well :-D
> >> that is the correct way to produce a bunch of relative
> >> interconnected pages that can be placed where-ever (not just
> >> in the /forrest) on a webserver. (and detaches the solution
> >> from the webapp that doesn't have this concern)
> 
> </snip>
> 
> whadayathink?
> using the CLI is about "staticalizing" your content.  The webapp 

That's almost as bad as 'prextensination'! ;)

> does not have this concern, so only the CLI needs to be taking up 
> this concern to 'relativise' all the /-leading references in the 
> produced static content.

+1. Just like how JSP tags all treat '/'-leading paths as relative to the
servlet context, not the server root.

> >
> >How about just adding a 'default' attribute to the above XML?
> >
> 
> That was my original plan, only this feature DOES push more into 
> the direction of generation of the sitemap, which is a path I try 
> to avoid ATM.

Yes, generating a whole sitemap is yucky. But generating a sitemap
_snippet_, which then gets combined (perhaps at runtime) into a live
sitemap, is much nicer. See below..

> Only solution I see now, is just to make this kinda 'fix'
> after all the real world web has this thing with index.html as 
> well, right? (I expect you to have some emotions, Jeff, given 
> your recent train of thought on the URI's :-))

 "Ban All Extensions!! Ban All Extensions!! Ban All Argghhh..
 getyourhandsoffme, peasant. I'm a knight of the W3C Ivory Tower.."

:) No, I'm not that bad, yet.

...
<snip useful tab rationale>

> >Sounds cool, as long as users can still edit the sitemap directly. No
> 
> I think this very feature offers a strong reason against 
> generating it?

Not against generating parts of it.....

> unless you want the hastle of merging with user-customizations 
> and the like :-S

Generate snippets, and then merge them with user snippets :)

> There once was the idea to enable end-user sitemap customizations 
> through mounted sitemaps though...
> 
> >matter how much project-specific info the siteplan captures, there will
> >always be users needing to play with the sitemap directly.
> >
> >What I'd like to do is write some code which, given a set of patterns:
> >
> >*.pdf
> >manual/*.pdf
> >**/*.pdf
> >
> >can sort them by 'generality'. Then we can have an Ant task which can
> >build a sitemap from a bunch of sitemap snippets. Currently, the
> >sitemap is very confusing, because matchers cannot be grouped by
> >function; they must be ordered by increasing generality. Getting the
> >order wrong leads to hard-to-debug problems. If, instead of a
> >monolithic sitemap.xmap, we could have a bunch of sitemap snippets
> >which are assembled at runtime, then a) the sitemap's functionality
> >would be modular, b) users could add their snippets without editing
> >(and potentially breaking) a giant confusing sitemap.
> >
> 
> sounds good, but needs some elaboration though...


It would be best to define the goals first:

 - Users need to be able to customize the sitemap with their own
   matchers, for whatever crazy reasons they want.

 - In addition, we'd like to provide quick'n simple ways of doing routine
   customizations, like specifying javadoc prefixes, and adding pipelines
   for new document types (docbook, say). Ie, a siteplan.

 - Forrest's sitemap needs to be modularized, so users can choose just
   the functionality they need. If they don't want svg2png, don't include
   Batik. If they don't want PDFs, don't include FOP. 


To meet these goals, I'd like to chop the sitemap into functional
sections:

 - Straight *.xml to *.html
 - Site statistics reporting (apachestats)
 - todo generation
 - changelog generation
 - faq
 - 'community' section with feedback
 - doclist
 - DTD documentation
 - PDFs-of-every-page

Each of these is in a sitemap 'snippet'. Users can add project-specific
functionality by adding new snippets.

Could this breakup be done by mounting subsitemaps? I don't think so,
because it would be impossible to order the subsitemap mounts correctly,
without knowing what's in them. Eg, say the "straight *.xml to *.html"
subsitemap is mounted first. It contains matchers for:

<map:match pattern="*.html">
<map:match pattern="**/*.html">

That's going to match requests that ought to be left for the todo,
changelog, faq and community snippets. Conclusion: the master sitemap
writer would need to know in detail, just what mounted snippets contain
and how they could interact. It's perfectly feasible that two snippets
could 'deadlock', with A required before B in some circumstances, and B
before A in others.

So my suggested alternative to subsitemaps is to simply throw all snippet
contents together into one big sitemap, and then sort by increasing
matcher generality. So *.html and **/*.html will end up near the bottom.

> and again, maybe solving it with less ant and more new cocoon 
> components would probably also solve it, and be more welcomed?

The cleanest solution is for Cocoon to not care about matcher order. You
don't have to order your templates in XSLT, so why should you have to
order matchers in a sitemap? If the sitemap didn't care about order, then
we could just mount subsitemaps for each snippet, just like in an XSLT
you can <xsl:import> various XSLTs in any order.

So given this solution, either implemented as an Ant task, or as an
enhanced Cocoon, how does it meet the goals?

  - Users need to be able to customize the sitemap with their own
    matchers, for whatever crazy reasons they want.

The Ant task just includes ${project.home}/src/documentation/*.xmap,
which adds user-defined snippets to the mix.

   - In addition, we'd like to provide quick'n simple ways of doing
     routine customizations, like specifying javadoc prefixes, and adding
     pipelines for new document types (docbook, say). Ie, a siteplan.

The Ant task transforms the siteplan into a number of .xmap snippets,
which are then included.

   - Forrest's sitemap needs to be modularized, so users can choose just
     the functionality they need. If they don't want svg2png, don't
     include Batik. If they don't want PDFs, don't include FOP. 

If the user can edit the includes and excludes pattern that the Ant task
uses to find .xmap snippets, then they can exclude snippets they don't
want.

Problem solved :) Technically, all that is required is a way of ordering
matcher patterns, and then the Ant task is easy. Then we ask Sylvain if he'll
kindly write us another sitemap processor that ignores matcher order, and
it's beer and skittles from there on.


--Jeff


> -marc=

Mime
View raw message