forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Bolger <pbol...@gmail.com>
Subject Re: improving menus and linking (Was: vague issues with Forrest use)
Date Wed, 02 Nov 2005 01:15:50 GMT
> Because this is no longer Vague - you have made a very concrete
> suggestion. The change of subject makes it much easier to read the
> archives where subject is all that is initially seen when searching.
>
> > if this has already
> > been implemented isn't there a case for making the
> > '#project.menu-scheme=directories' the default, and letting those who
> > need extra flexibilty choose the other option if they need it?
>
> Does it actually work the way David suggestd? Seems daft that we don't know!

Thinking more about this I can see one drawback: one wouldn't be able
to control the order in which links appear in menus. I don't think
this is necessarily a fatal problem though, particularly if the user
were able to 'freeze' the site structure to the site.xml file.
One could always hack the order by just renaming the source files,
01_foo.xml, 02_morefoo.xml etc. I realise this is probably horrifying
stuff for programmers... but a lot of website builders like to mess
around with the usability side of their site structure - nav, nesting
of sections etc. This would make restructuring very quick and easy.
There's a lot to be said for using an interface (the OS directory
structure) which most users are very familiar with.


> > I've read the documentation on linking and I admit I'm yet to be
> > convinced why putting an extra layer of translation into links is
> > advantageous.
>
> Here are a couple of advantages (there are others I am sure):
>
> You have a site with 1000 documents. One of them is in directory A and
> appears in the site navigation structure in a corresponding place.
> However, you eventually realise that the document would be more
> appropriate in a different part of the navigation structure.

> Without site.xml you would have to move the file, but now you have
> broken all the internal links to the original file. Using site.xml you
> simply move it in the navigation structure, but leave it where it is in
> the directory structure.



> ---
>
> You have a file that you want to appear twice in the navigation
> structure. Without site.xml you need to duplicate the content and manage
> two identical files.
>
> ---
>
> Imagine a scenario in which you have 100 files in subdirectories. The
> first 50 are user manuals, the second 50 are developer manuals. The dev
> documents reference the user documents, but not the other way around.
>
> You want to create two sites, one for users (user docs only), one for
> devs (both sets of docs).
>
> Without site.xml how do you do it?
>
I tend  to use SSI's for nav. I also use CSS to filter the output of
those includes. For instance the developer manuals would be
class="dev" and in the user site .dev would have a display:none value.
That's if I needed the the two lists completely merged into user, dev,
user, dev etc.


Which is not to say that the site.xml solution isn't inherently
superior. I must admit that part of my interest in Forrest is to look
at  different approaches to these sort of problems.





>
> Hope these few examples help illustrate some of the power uses of
> site.xml (doesn't preclude a simple default setting as you describe though).
>
> Ross
>
>

Mime
View raw message