forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [RT] Enhance Forrest sites homepage
Date Mon, 14 Apr 2003 16:14:38 GMT

Jeff Turner wrote, On 14/04/2003 16.58:
> On Mon, Apr 14, 2003 at 02:31:23PM +0200, Nicola Ken Barozzi wrote:
> 
>>
>>Jeff Turner wrote, On 14/04/2003 14.05:
>>
>>>On Mon, Apr 14, 2003 at 09:32:42AM +0200, Nicola Ken Barozzi wrote:
...
>>>>
>>>>-> get site.xml
>>>>-> transform each nugget to an include
>>>>  -> process the include
>>>>    -> aggregate with the main page
>>>
>>>
>>>Mm.. sounds a bit hacky to me.  Does this magic apply to all pages, or
>>>just index.html? 
>>
>>I was starting to ask this too on this list ;-)
>>As for KISS, sinece I need it on the main page, and in many sites it's 
>>only on the main page or on all, I would make it "mainonly||all||none".
> 
> The hack deepens ;P

:-DD

>>>What if I want to pull a RSS feed into my news.html page instead of
>>>index.html?
> 
> ^^^ You missed an opportunity here to deepen it further.. might I
> suggest:
> 
> "mainonly || newsonly || all || none ||" ?

:-DDD  But my proposal is to include content in the page.

>>>Or if I want to do some RSS preprocessing
>>>(perhaps merge multiple feeds)?
>>
>>This is another thing. I want to display nuggets of information on the 
>>site, taken from document11DTD files. It's up to Cocoon to provide them, 
>>so I can have normal pages, rss feeds, or whatever.
>>
>>What is needed is is to make Forrest render rss feeds as document11DTD 
>>pages, but that's easy.
> 
> So let's say I want to pull in my RSS feed into index.html.  How would it
> work?  I'm guessing:
> 
>  - Define a news.xml pipeline which does a HTTP GET of my RSS and applies
>    rss2document.xsl
>  - Edit site.xml/skinconf.xml and add a:
>    <nugget>.....  src="cocoon:/news.xml".....</nugget>
>  - Edit skinconf.xml (?) and switch nuggets to "mainonly"

Nope, a newsfeed is exactly like any other page for Forrest; we have 
faq, changes, todo, etc and now we would also have a news DTD.

So what we need is to make a page with the news DTD, and Forrest will 
pick it up. Here (in your example) the caveat is that the page is 
external, so it would be something like:

- make a page with the name I want
   mynews.xml
- include in it the feed I need
- ask for it in Forrest

No skinconf need; the skinconf nugget thing is to *include* page parts 
in the page, not to render them. Each nugget can contain a page content, 
be it a normal page, a newsfeed, todos, changes, whatever.

> If so, what's wrong with:
> 
>  - Define a news.xml pipeline which does a HTTP GET of my RSS and applies
>    rss2document.xsl
>  - Edit the <map:aggregate> and throw in a <map:part
>    src="cocoon:/news.xml"/>.

The above seems easier to me.

Overmore, I don't want users to touch our pipelines, because it becomes 
later a PITA to update Forrest.

>>>Why not just let users add a <map:part src="cocoon:/news.xml"/> to the
>>>sitemap's <map:aggregate>
>>
>>I think it's not immediate enough for most users.
> 
> I'm +1 on automatically copying sitemap.xmap to src/documentation/ on
> 'forrest seed' if this makes the sitemap more 'immediate'.

I'd say no... what if/when we change it? IMHO we should not encourage 
normal users to hack the pipeline.

>>Besides, nuggets sould be a standard feature, exactly like the logos we
>>can show-hide, etc.
> 
> A news panel is _content_, not presentation.  It shouldn't be controlled
> from the presentational part of Forrest (skinconf, site2xhtml.xsl), but
> from the content aggregation part, namely the sitemap.

Hmmm, I disagree. The news panel *is* content, but saying if I want it 
in the main page is presentational.

I already explained to you how the content is in a file with its name; 
in here I only say *if* I want it in the side panel.

I can still see the news stuff on a single page without having to say it 
in skinconf.

>>>, and add some special handling for <div class="news"> content in
>>>site2xhtml.xsl?
>>
>>That sure. We need a special case for showing news in skins, and I
>>would do as you suggest.
> 
> Well if you want a physically separate 'panel' as shown in the HTML
> mockup, that needs to be done at the site2xhtml.xsl level: we don't have
> a <sidebar> tag in doc-v11.

Yes. In fact all our aggregated content is not doc-v11.

>>>It's more flexible, and control
>>>over page composition is kept in the sitemap where it belongs.
>>
>>Why more flexible? We are already aggregating the navigation without 
>>making our users tinker with it, and I would want the same for these 
>>"nuggest". They can also be other menus, help, whatever, not only news. 
>>That's why I call them nuggets.
> 
> I call them "content".  Just like body content, menu content, tabs
> content.  Those happen to be there by default.  Why not simply extend
> this mechanism (add more map:parts) rather than complicate things?

Because you have *one* navigation, and *many* nuggets on a single page.
I *will* aggregate the resulting right-panel, but it has to be result of 
diverse pages.

>>Our pages would have:
>>
>>- logos
>>- search
>>- navigation (tabs, navs)
>>- credits
>>- content
>>- nuggets
>>- footer
>>
>>All the above should be configured in the same manner. Hence since the 
>>other ones are in skinconf, we should put the nuggets there too for 
>>consistency, now that I think of it (not site.xml as I previously thought).
> 
> I think you're tripping up on the bogosity of skinconf.xml here.
> 
> skinconf.xml is full of project metadata that *ought* to be in a proper
> site descriptor like gump.xml.  The remainder of skinconf.xml
> are 'properties' of the Forrest rendering process, which ought to be
> moved out into a properties.xml file.
> 
> So skinconf.xml is a hack that ought to go away, and certainly not have
> more stuff added.

Well, put them in the new gump descriptor, I'm not fixed on skinconf. 
What I mean is that they remain where other similar configs are, that's 
all. Where they will shortly go is non-relevant WRT this discussion.

> By the way, once we do have a "site descriptor" like gump.xml, its
> content would be aggregated just like all other content:
> 
> 
> <map:pipeline match="siteinfo.xml">
>   <map:generate src="gump.xml"/>
>    ...
> </map:pipeline>
> 
> <map:aggregate element="site">
>   <map:part src="cocoon:/siteinfo.xml"/>  <!-- extra entry -->
>   <map:part src="cocoon:/tab-{1}.xml"/>
>   <map:part src="cocoon:/menu-{1}.xml"/>
>   <map:part src="cocoon:/body-{1}.xml"/>
> </map:aggregate>

Why would you do this? Siteinfo is not content, it's metadata; ATM we 
get metadata via sitemap modules and the document() function in stylesheets.

> And to twist your words slightly:
> 
>   "All the above should be configured in the same manner. Hence since the
>   other ones are in sitemap.xml's <map:aggregate>, we should put the
>   nuggets there too for consistency,"

I see this at the macro level:

  <map:aggregate element="site">
    <map:part src="cocoon:/tab-{1}.xml"/>
    <map:part src="cocoon:/menu-{1}.xml"/>
    <map:part src="cocoon:/body-{1}.xml"/>
    <map:part src="cocoon:/nuggets-{1}.xml"/>
  </map:aggregate>

Where tab is taken from site.xml, the menu is created as you know, body 
from the first available file with that name, and nuggets from a nugget 
pipeline.

What we *could* do, to solve both our needs, is to make a nuggets.xml 
pipeline that the users can tweak.

But I really think we should not let users mess with Forrest pipelines, 
because it would make updates to Forrest harder. If a user wants extra 
features, then he can use a user.xml pipeline that gets mounted before 
or after ours.

I just need a way of telling Forrest what pieces of info I want to 
*present* in the nugget space. I hope you won't get us aggregating all 
the news for every single page of the site ;-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message