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 Tue, 15 Apr 2003 07:18:09 GMT

Jeff Turner wrote, On 15/04/2003 7.15:
> 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?

Xinclude. But this is a tamporary hack. It will become a resources.xml 
descriptor as we said some months ago, that tells Forrest where to get 
sources (and eliminate the forrest properties for source dirs).

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

Of news, yes. What news, no. You don't decide what tabs to show in the 
sitemap, as I don't decide on news there.

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

And pages live in pages, the sitemap says *if* I want news in page x. 
Now *which* news, as not *which* tabs.

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

Very simple: not extensible without fiddleing with the skin. If I want 
to change skin I have to hand-craft it every time.

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

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

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

So all content has to have its place in an aggregate? I disagree. Not 
extensible without touching the sitemap.

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

Wrong, it places metadata with the data. It adds info on how to deal 
with stuff inside the content. Instead we should pass it as stylesheet 
parameters, that are the correct push metadata feature of xslt.

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

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

So Forrest becomes as complex as Cocoon.

> - Hide the sitemap, and add intermediate layers that provide a 'user
>   friendly' interface to structural concerns.

Which is what we have been doing till now.

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


Mime
View raw message