forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: [RT] Enhance Forrest sites homepage
Date Tue, 15 Apr 2003 05:15:47 GMT
On Mon, Apr 14, 2003 at 06:14:38PM +0200, Nicola Ken Barozzi wrote:
> >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

How does this work?  Editing the sitemap?

> - 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.
> >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.

_Structural_, not presentational.  Take tabs for example; their presence
or absence is determined by the <map:part src="cocoon:/tab-{1}.xml"/>
line in the sitemap.  The skin stylesheets then determine what the tabs
look like.

Structural things go in the sitemap.  Presence/absense of news is a
structural issue.

> 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.

Tabs live in tabs.xml, and the sitemap says *if* I want it in page X.

> >>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.

If site2xhtml.xsl gets HTML looking like:

  <div class="body">
  <div class="menu">
  <div class="tabs">
  <div class="nugget1">
  <div class="nugget2">

What's wrong with that?

> >>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. 

Can you paste what the snippet would look like?

> 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

It's metadata that we want to display on the website, and therefore
becomes content.

> ATM we get metadata via sitemap modules and the document() function
> in stylesheets.

The use of document() in Cocoon XSLTs is usually a sign that SoC is
being broken.  A component is _pulling_ info that ought to have been
_pushed_ to it.  The map:aggregate snippet above fixes this,

> >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.

Yes it does, so we don't do it currently.

> If a user wants extra features, then he can use a user.xml pipeline
> that gets mounted before or after ours.

Not really possible, as new pipelines need to plug into the old ones

There are only two options to making Forrest sites structurally

- 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
- Hide the sitemap, and add intermediate layers that provide a 'user
  friendly' interface to structural concerns.


> 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         
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------

View raw message