forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
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"/>
      </map:match>

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:transform>
  <map:serialize type="xml"/>
</map:match>
 
<!--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"/>
</map:match>

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

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

salu2
-- 
thorsten

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


Mime
View raw message