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 04:19:39 GMT
On Tue, Sep 03, 2002 at 01:50:57PM +0200, Marc Portier wrote:
...
> for this last part I still think a simple forrest-config file 
> makes the most sense: (since I don't know how to have ant run 
> through properties that you don't know about at design time)
> 
> <content>
>   <part name="doc"
>         location="./src/documentation/content/xdocs"/>
>   <part name="mail"
>         location="..." />
>   <part name="jdoc"
>         location="..." />
> </content>
>
> with the knowledge of the current bot we could easily build out 
> of this a dynamic/embedded ant piece that gets to copy over this 
> stuff to the cocoon context dir in separate dirs that == the 
> part-name

This sounds much like Marc's siteplan idea, where an XML file contains
project-specific details that result in various sitemap modifications.

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.

We could just have an Ant task that replaces '/jdoc' with the correct
path, adding extra ..'s to compensate for subdirectories.

> what remains though is the knowledge of the "default-page" for 
> each of the parts... what if we link to just /doc/ ? must there 
> then be some /content/doc/index.* ?
> if we make this flexible and possibly differrent for the various

How about just adding a 'default' attribute to the above XML?

> there is one other thing we could mingle in here, and that is the 
> tab-definitions:
> <content>
>   <tab label="must reads" default-part="doc">
>     <part name="doc" location=".." />
>     <part name="jdoc" location=".." />
>   </tab>
>   <tab label="community" defaut-part="mail">
>     <part name="mail">
>   </tab>
>   <part name=".." location=".." />
> </content>
> 
> so we could also generate a tabs.xml :-)

>From what I gather of the siteplan proposal, the idea was to have one XML
file that effectively configures the whole of Forrest for the user's
project.  From that XML siteplan file, one would generate XML catalogs,
tab files, book files (integrate libre.xml?), and do lots of tweaking of
the sitemap, and generate parameters for the skins.

Sounds cool, as long as users can still edit the sitemap directly. No
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.


--Jeff


> any other ideas?
> 
> -marc=

Mime
View raw message