forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [DISCUSS] feeder plugin contract in the view
Date Thu, 31 Mar 2005 12:08:25 GMT
On Thu, 2005-03-31 at 01:55 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > I wrote a feeder contract for the view plugin. 
> > 
> > The feeder plugin provide a way to display feed as xdoc. 
> >
> </snip>
> > 
> > WDYT?
> > 
> > Please discuss that because we should find a solution that has framework
> > character. IMO the implemented solution can be too inflexible.
> Hmmm... my solution seems far too simple and since I have not had the 
> time to get into your views work yet I think I must be missing 
> something. But here goes anyway...
> Use Case
> --------
> Create a page like this:
> _______________________________________________
> |         |                   |               |
> |         |                   |               |
> |         |                   |   RSS Feed    |
> |         |                   |               |
> | Menu    |                   |               |
> |         |                   -----------------
> |         |    Content                        |
> |         |                                   |
> |         |                                   |
> |         |                                   |
> |         |                                   |
> |         |                                   |
> -----------------------------------------------
> The Problem
> -----------
> How does the view get the RSS content without knowing how to render it 
> *and* without having a dependency on the plugin that does the rendering 
> (in this case the feeder plugin)
> Implementation
> --------------
> First let us consider what would happen if we were simply requesting a 
> page where the RSS feed was the main content.
> Forrest would make a request for rssFeed.xml. This request would be 
> examined by each plugin in turn, skipping over ones that do not know how 
> to generate an XDoc response for the "rssFeed" document. Eventually we 
> come to the feeder plugin, which says "hey, I can deal with this 
> request". It reads a file, processes it with some XSL and returns an XDoc.
> This Xdoc is then processed by the skinning system. First it turns it 
> into XHTML, then it adds the navigation sections and we are done.
> OK, so no problem so far. 

Hmm, what happens if that is not matching?

> Now we want to embed the nugget of RSS data 
> into a separate part of the page, the main content is no longer the RSS 
> data.
> However, if we look carefully at this we see that it isn't really any 
> different at the generation stage, it is only at the skinning stage that 
> things need to change.

Maybe I am to focused.

>>From the feeder plugin:
     <map:match pattern="feeder/*.xml">
        <map:generate src="{project:content.xdocs}/{1}.xml"/>
        <map:transform src="resources/stylesheets/feedDesc2RSS20.xsl"/>
        <map:transform src="resources/stylesheets/rss2document.xsl"/>
        <map:serialize type="xml"/>

The generation state needs here a feedDescriptor. This descriptor now
exists *only* in the view. It is NOT in {project:content.xdocs}/{1}.xml!

from the Views plugin:
    Get the nugget (xml) of the requested contract.
This will e.g. produce the feedDescriptor.
<map:match pattern="resolve.nugget.*.*">
  <map:generate src="cocoon:/prepare.view.{2}"/>
  <map:transform src="resources/stylesheets/nugget.xsl">
    <map:parameter value="{1}" name="contract"/>
  <map:serialize type="xml"/>
<!--This will now transform the e.g. feedDescriptor-->
<map:match pattern="get.nugget.*.*">
  <map:generate src="cocoon://resolve.nugget.{1}.{2}"/>
  <map:transform src="resources/nuggets/{1}.fn"/>
  <map:serialize type="xml"/>

What happen here is that I first prepare the generation stage by
extracting the descriptor from the view and then transform this
descriptor. The result will be saved as new forrest:property for the
final skinning page.

> The content to go in the RSS Feed box is still generated by requesting 
> "rssFeed.xml", 

no, in our case we cannot do it, better said I do not how. ;-) Any idea

> we still get XDoc back. All that needs to change is how 
> we skin it.

The part with delivering xdocs back is as well different in the view
contract. IMO we should take the change and move to 
a subset of XHTML2 for the views and not base it on xdocs.

I guess my definition of view is a wee bit different then yours. For me
a forrest:view is comparable with a view on a table of a db. It is a
subset of data that then get returned. The forrest:views decides which
data are needed. True the last stage is the skinning but that is not the
main focus of views.


"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

View raw message