forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
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:

<site>
  <div class="body">
    ...
  </div>
  <div class="menu">
    ...
  </div>
  <div class="tabs">
    ...
  </div>
  <div class="nugget1">
    ...
  </div>
  <div class="nugget2">
    ...
  </div>
  ...
</site>

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.

Cool.

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

There are only two options to making Forrest sites structurally
extensible:

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


--Jeff


> 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