You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by David Crossley <cr...@apache.org> on 2005/11/01 00:26:19 UTC
improving menus and linking (Was: vague issues with Forrest use)
Paul Bolger wrote:
> > >> - A simple, intuitive way for non-XMLers to add things to site.xml
> > >
> > > Have you any suggestions about what this may look like?
>
> Not sure how technically possible this is, but how about a directory
> parser which builds the site nav? In other words the user would create
> a directory structure, arrange their source files where they want them
> to appear in the site map, and the parser would build the site
> structure in site.xml as a mirror of that directory structure.
> I realise that this would sacrifice flexibility, but I think a lot of
> users would use a 'quick and dirty' site design method (particularly
> one where rejigging the site structure would be as simple as moving
> the source files).
I have never used it, but i think that that is already
possible. Look in a forrest.properties from a seed site:
#project.menu-scheme=tab_attributes
#project.menu-scheme=directories
The former is the default.
http://forrest.apache.org/docs_0_80/linking.html#other-menu-selection
Directory-based selection
However site.xml has two functions: menus and linking.
-David
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Paul Bolger wrote:
>
>>>>>- A simple, intuitive way for non-XMLers to add things to site.xml
>>>>
>>>>Have you any suggestions about what this may look like?
>>
>>Not sure how technically possible this is, but how about a directory
>>parser which builds the site nav? In other words the user would create
>>a directory structure, arrange their source files where they want them
>>to appear in the site map, and the parser would build the site
>>structure in site.xml as a mirror of that directory structure.
>>I realise that this would sacrifice flexibility, but I think a lot of
>>users would use a 'quick and dirty' site design method (particularly
>>one where rejigging the site structure would be as simple as moving
>>the source files).
I've implemented this in a few different ways but never been totally
happy with the results. The problem is in a dynamic environment where
caching seems to get in the way, for a static site they qork well.
Because I'm not happy with them they remain undocumented. If someone
were to play with them an improve them it would be great.
One of my experiments was reasonable succesfull and is in SVN:
Directory Reader
================
This is almost exactly what you describe. You can see it in the Resume
plugin in whiteboard. In particular:
<map:match pattern="team/all.source.xml">
<map:generate type="directory"
src="{project:content.xdocs}/team/resume">
<map:parameter name="include" value=".*.xml$"/>
</map:generate>
<map:transform src="resources/stylesheets/directory2resumes.xsl"/>
<map:transform type="cinclude"/>
<map:serialize type="xml"/>
</map:match>
<map:match pattern="resume.site.snippet.xml">
<map:generate src="cocoon:/team/all.source.xml"/>
<map:transform
src="resources/stylesheets/resumes2resumeSiteSnippet.xsl"/>
<map:serialize type="xml"/>
</map:match>
Now just add a cinclude to site.xml for the "resume.site.snippet.xml"
and you get an index of all resumes in the /team/resume directory.
The main problem with this is that the resumes have to go in a specified
directory - not flexible, as you observe, but very easy to use.
Since writing that plugin we have made the locationmap actually work, we
now have a level of flexibility over the location of the files we want
to generate an index for without having to touch the plugin sitemap. So
this approach can be improved considerably now.
Ross
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Paul Bolger wrote:
>
>>>>>- A simple, intuitive way for non-XMLers to add things to site.xml
>>>>
>>>>Have you any suggestions about what this may look like?
>>
>>Not sure how technically possible this is, but how about a directory
>>parser which builds the site nav? In other words the user would create
>>a directory structure, arrange their source files where they want them
>>to appear in the site map, and the parser would build the site
>>structure in site.xml as a mirror of that directory structure.
>>I realise that this would sacrifice flexibility, but I think a lot of
>>users would use a 'quick and dirty' site design method (particularly
>>one where rejigging the site structure would be as simple as moving
>>the source files).
>
>
> I have never used it, but i think that that is already
> possible. Look in a forrest.properties from a seed site:
> #project.menu-scheme=tab_attributes
> #project.menu-scheme=directories
>
> The former is the default.
>
> http://forrest.apache.org/docs_0_80/linking.html#other-menu-selection
> Directory-based selection
I don't think this does what Paul is suggesting, I think this is about
which parts of the menu are shown when a particular tab is slected. I
could be wrong though ;-)
Ross
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> David Crossley wrote:
>
>
>>I have never used it, but i think that that is already
>>possible. Look in a forrest.properties from a seed site:
>>#project.menu-scheme=tab_attributes
>>#project.menu-scheme=directories
>
>
>>The former is the default.
>
>
>>http://forrest.apache.org/docs_0_80/linking.html#other-menu-selection
>>Directory-based selection
>
>
>>However site.xml has two functions: menus and linking.
>
>
> As far as I was able to find out, that option will only influence what
> tab is _selected_ depending of the directory that the current page is
> in. It does _not_ make Forrest generate a directory-tree-based navigation
> structure.
>
> Yet I remember that Ross was pretty close to finishing a plug-in
> for doing that last summer. Ross???
>
Just in case you missed my overlapping reply (in this thread), it's in
the resume plugin in whiteboard. My reply here describes how it works.
Ross
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ferdinand Soethe <fe...@apache.org>.
David Crossley wrote:
> I have never used it, but i think that that is already
> possible. Look in a forrest.properties from a seed site:
> #project.menu-scheme=tab_attributes
> #project.menu-scheme=directories
> The former is the default.
> http://forrest.apache.org/docs_0_80/linking.html#other-menu-selection
> Directory-based selection
> However site.xml has two functions: menus and linking.
As far as I was able to find out, that option will only influence what
tab is _selected_ depending of the directory that the current page is
in. It does _not_ make Forrest generate a directory-tree-based navigation
structure.
Yet I remember that Ross was pretty close to finishing a plug-in
for doing that last summer. Ross???
--
Ferdinand Soethe
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ross Gardler <rg...@apache.org>.
Ferdinand Soethe wrote:
> Ross Gardler wrote:
>
>
>>As for mangling the names to get the right order - it makes me shudder!!
>>But if users would prefer it then it could be made an option.
>
>
> Keeping it simple is sometimes more important than fancy architecture.
>
> And it doesn't hurt to provide such a simple plugin as an alternative
> approach to get started.
>
Wow, can you beleive it, McPlugin forgot how easy it is to create
plugins. I even suggested, some time ago, that we could have seeds for
different types of users that would adopt the relevant plugins. So we
could have a "quick start" seed that used this site.xml generator.
Anywone care to create this internal plugin? It's only really a matter
of adapting what I have already done in the resume plugin.
Ross
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ferdinand Soethe <fe...@apache.org>.
Ross Gardler wrote:
> As for mangling the names to get the right order - it makes me shudder!!
> But if users would prefer it then it could be made an option.
Keeping it simple is sometimes more important than fancy architecture.
And it doesn't hurt to provide such a simple plugin as an alternative
approach to get started.
--
Ferdinand Soethe
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Paul Bolger <pb...@gmail.com>.
not sure what happened there - Gmail hiccup! My apologies.
On 11/3/05, Paul Bolger <pb...@gmail.com> wrote:
> > As for mangling the names to get the right order - it makes me shudder!!
>
> Although I've found for big sites it's not a bad idea to use the ISO
> date-of-creation/page-subject-event as the first part of your file
...........
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Paul Bolger <pb...@gmail.com>.
> As for mangling the names to get the right order - it makes me shudder!!
Although I've found for big sites it's not a bad idea to use the ISO
date-of-creation/page-subject-event as the first part of your file
name anyway, particularly for content such as news stories, press
releases, articles.
If your page titles and headings are being used properly the filenames
should be of minor importance to the audience.
>
> > 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.
>
> The problem with the 'CSS to exclude stuff' approach is that you are
> using bandwidth to send informaition that is not being displayed. This
> may not be significant in low traffic sites (like my own). But for
> something like the Apache sites it mounts up very quickly, that is 1
> million lots of 100 extra bytes adds up to lots of bandwidth.
>
> The reduction of bandwitdh use is one of the goals of the project.
I agree, to a point. If you take a look at the actual code weight of
doing a trick like that - assuming that it's laid out properly, as an
unordered list - it doesn't come close to the sort of bloat which a
WYSIWYG web authoring program can generate. Dreamweaver can turn four
rollover buttons into three screens of code.
...but this segues nicely into another Forrest issue I think we should
be looking at: cleaning up the html output, and probably attempting to
make it xhtml.
I think another thread is called for.
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
>>As for mangling the names to get the right order - it makes me shudder!!
>
>
> Although I've found for big sites it's not a bad idea to use the ISO
> date-of-creation/page-subject-event as the first part of your file
> name anyway, particularly for content such as news stories, press
> releases, articles.
> If your page titles and headings are being used properly the filenames
> should be of minor importance to the audience.
I agree, antoher concern is that not everyone speaks English, I'm amazed
at the internationalised sites that stick with English page names in
URLs - what is the point?
>
>>>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.
>>
>>The problem with the 'CSS to exclude stuff' approach is that you are
>>using bandwidth to send informaition that is not being displayed. This
>>may not be significant in low traffic sites (like my own). But for
>>something like the Apache sites it mounts up very quickly, that is 1
>>million lots of 100 extra bytes adds up to lots of bandwidth.
>>
>>The reduction of bandwitdh use is one of the goals of the project.
>
>
> I agree, to a point. If you take a look at the actual code weight of
> doing a trick like that - assuming that it's laid out properly, as an
> unordered list - it doesn't come close to the sort of bloat which a
> WYSIWYG web authoring program can generate. Dreamweaver can turn four
> rollover buttons into three screens of code.
Yes, but that's comparing apples to oranges. Forrest is not a WYSIWYG
bloat system and if you feed content into it that is generated with such
a system it strips much of the bloat. Every byte counts.
> ...but this segues nicely into another Forrest issue I think we should
> be looking at: cleaning up the html output, and probably attempting to
> make it xhtml.
> I think another thread is called for.
+1
Prior to the other thread starting I'll say:
I was hoping this would be part of the XHTML2 move, but that seems to
have completely stalled as it is constantly waiting for some other thing
to happen first. This is another good reason to just get on with it.
Ross
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Paul Bolger <pb...@gmail.com>.
> As for mangling the names to get the right order - it makes me shudder!!
Although I've found for big sites it's not a bad idea to use the ISO
date-of-creation/page-subject-event as the first part of your file
name anyway, particularly for content such as news stories, press
releases, articles.
If your page titles and headings are being used properly the filenames
should be of minor importance to the audience.
>
> > 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.
>
> The problem with the 'CSS to exclude stuff' approach is that you are
> using bandwidth to send informaition that is not being displayed. This
> may not be significant in low traffic sites (like my own). But for
> something like the Apache sites it mounts up very quickly, that is 1
> million lots of 100 extra bytes adds up to lots of bandwidth.
>
> The reduction of bandwitdh use is one of the goals of the project.
I agree, to a point. If you take a look at the actual code weight of
doing a trick like that - assuming that it's laid out properly, as an
unordered list - it doesn't come close to the sort of bloat which a
WYSIWYG web authoring program can generate. Dreamweaver can turn four
rollover buttons into three screens of code.
...but this segues nicely into another Forrest issue I think we should
be looking at: cleaning up the html output, and probably attempting to
make it xhtml.
I think another thread is called for.
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
>>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.
Yes, that is why, in the resume plugin, the technique is only used for
the list of resume's for people. It makes sense to sort these
alphabetically. But not for most other content.
As for mangling the names to get the right order - it makes me shudder!!
But if users would prefer it then it could be made an option.
>>Here are a couple of advantages (there are others I am sure):
...
> 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.
The problem with the 'CSS to exclude stuff' approach is that you are
using bandwidth to send informaition that is not being displayed. This
may not be significant in low traffic sites (like my own). But for
something like the Apache sites it mounts up very quickly, that is 1
million lots of 100 extra bytes adds up to lots of bandwidth.
The reduction of bandwitdh use is one of the goals of the project.
Ross
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Paul Bolger <pb...@gmail.com>.
> 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
>
>
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Ross Gardler <rg...@apache.org>.
Paul Bolger wrote:
> Not quite sure why this is off in a different thread, but: (continuing
> the 'vague issues with Forrest use' discussion)
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!
> 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?
---
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
Re: improving menus and linking (Was: vague issues with Forrest use)
Posted by Paul Bolger <pb...@gmail.com>.
Not quite sure why this is off in a different thread, but: (continuing
the 'vague issues with Forrest use' discussion) 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?
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.
I have never used it, but i think that that is already
> possible. Look in a forrest.properties from a seed site:
> #project.menu-scheme=tab_attributes
> #project.menu-scheme=directories
>
> The former is the default.
> http://forrest.apache.org/docs_0_80/linking.html#other-menu-selection
> Directory-based selection
>
> However site.xml has two functions: menus and linking.
>
> -David
>
--
Paul Bolger
19 Raggatt St
Alice Springs
NT 0870
08 8953 6780