forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [VOTE] Sitemap user visibility and scope in Forrest
Date Tue, 15 Apr 2003 09:22:18 GMT

Jeff Turner wrote, On 15/04/2003 11.16:
> On Tue, Apr 15, 2003 at 09:22:27AM +0200, Nicola Ken Barozzi wrote:
>>The last discussion on nuggets has shown that there are two possible 
>>roads that Forrest can take.
>>(a) Make the sitemap a central concept to Forrest, as it is for Cocoon.
>>   Encourage users to edit the sitemap to change the structure of their
>>   site.
>>(b) Hide the sitemap, and add intermediate layers that provide a 'user
>>   friendly' interface to structural concerns.
>>Till now, we have mainly gone the route of (a), by creating mechanisms 
>>to keep the sitemap away from users.
> Did you mean (b) here?  

Yes, sorry.

>AFAIK we have not created any intermediate layers
> on top of the sitemap.

all the informal skin definitions

>>This makes it easier for them, and 
>>most important makes Forrest easily upgradeable. If users touch the 
>>sitemap, they will have to reedit the one of the new Forrest, going out 
>>of synch and possibly not upgrading Forrest because of it. I don't want 
>>that to happen.
>>Thus, I ask to vote on this.
>>Should Forrest pursue the goal of "hiding" the sitemap as in case (a)?
> Again, don't you mean (b) "Hide the sitemap"?


>>This does not block users to do it, just ensures that we don't *require* 
>>it to happen.
> Not sure exactly what you're asking a vote about.  

Never to require users to fiddle with sitemaps to config a standard 
Forrest feature.

> Currently, everything
> 'structural' about a site is determined in the sitemap.  This includes:
>  - URI structure (*.xml pipelines define most pages, plus special cases
>    like {todo,changes}.html)
>  - page structure (each page composed of menu + tabs + body).

Ok, so?

> Now with 'nuggets', it seems you want to make page structure configurable
> in something other than the sitemap.  

No, no, no. I want to make the nuggets structure configurable.

I say:
  1 Forrest *has* a nuggets ection in its structure -> sitemap
  2 this site uses these nuggets -> config

1 is fixed, decided, as we decided to have tabs. And as I configure 
which tabs to show out of the sitemap, I will do so with nuggets too.

> Seems conceptually wrong to me, but
> does have the advantage of not requiring a sitemap edit.  

You wrongly assume that all content decisions are taken in the sitemap. 
Well, content decisions are on disk. The sitemap creates rules and big 
page structure. Configs tell what to show.

> If you can
> explain exactly what you propose (I've made several wrong guesses
> already) that would help.

Have that our page layout, that now comprises of header, tabs, 
navigation, body and footer, also can contain "nuggets", that is small 
pieces of information. These can be newsfeeds, infos, logos, publicity, 
whatever. They are not central to a page but are also on it.

As we configure tabs out of the sitemap, i want to configure nuggets out 
too, in the same way. Hence I will have a section:

    <nugget src=""/>
    <nugget src=""/>
    <nugget src=""/>

AS we have a tabs.xml, shall we have a nuggets.xml? Dunno, that's yet to 
decide later . What I want to decide now is that we decide if we want to 
require users to edit sitemaps to get standard features. This impacts 
heavily as you have seen on the nugget system design.

The first iteration of nuggets will *not* have newsfeeds, just include 
pages that are in the uri space of the site in the nugget section. For 
the news and other stuff, it's another thread, part of the 
status-todo-etc thread.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message