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 Mon, 14 Apr 2003 14:58:36 GMT
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:
> >
> >>Jeff Turner wrote, On 11/04/2003 18.08:
> ...
> >>>Do I edit the sitemap, adding the
> >>>RSS feed inside a <map:aggregate>, or does Forrest provide a layer
of
> >>>abstraction above this?  I assume a 'layer of abstraction' implies using
> >>>CInclude or something, not <map:aggregate>?
> >>
> >>Yes. It's basically
> >>
> >>-> 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

> >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 ||" ?


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

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

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

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

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

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

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

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>


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,"


--Jeff

> As we can disable or not search, credits, etc, we shouold be able to do 
> it with nuggets.
> 
> Look at it from a user perspective, and it makes IMHO sense.
>
> -- 
> Nicola Ken Barozzi                   nicolaken@apache.org
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------

Mime
View raw message