forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [DISCUSS] feeder plugin contract in the view
Date Thu, 31 Mar 2005 13:53:51 GMT
Thorsten Scherler wrote:
> 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. 
>>>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)
>>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?

In that case Cocoon throws an error which we can trap in the error 
handling of the sitemap -

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

That is only the case because that is the way you have implemented it at 
present. In need not stay that way if it causes problems.

I would argue that content should never be described in the view. It 
should only be described in the site contents. The feed descriptor is 
content, or at least it is meta-data telling us where we can find the 
final content. It certainly is not presentation information which is all 
a view should be concerned with.

Before you moved it to the view it was in 
{project:content.xdocs}/{1}.xml. I see no need to move it, simply refer 
to it via the URI in the view:

<forrest:contract name="feeder">
   <forrest:properties contract="feeder">
     <forrest:property name="feeder" nugget="get.nugget.feeder">

Now instead of pulling the descriptor out of the nugget and transforming 
it with a stylesheet in the feeder plugin we simply generate 
cocoon://feeds/somefeed.xml and let the feeder plugin do the work.

More on this later.

>>The content to go in the RSS Feed box is still generated by requesting 
> no, in our case we cannot do it, better said I do not how. ;-) Any idea
> how?

In my view we have to find out how, otherwise we end up mixing content 
with layout, that is bad.

Unfortunately, I still haven't been able to fully understand your work 
so far, so I'm just throwing out ideas. However, the benefit of this is 
that I am not trying to mold my ideas to your implementation, only to 
the concept you have created. The result may be a completely different 
implementation but it may help solve some of the problems you have come 
across so far.

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

When referring to XDoc I was referring to the Forrest internal format. 
I'm happy to start the move to XHTML alongside the move to views. But 
first lets work out how views will work. That means for this test case 
we will should work with XDocs.

When we have 0.7 out the door then we can think about moving to XHTML.

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

You raise a good point.

Lets think about what Forrest does:

Input data -> FORREST -> Output data

The plugin architecture is designed to support each of the stages in 
this process. See

We are in a transition stage at present that has skins in the core, but 
they should really be in the output stage.

You point out that moving skinning out of core is only *partly* what 
this work is about.

However, in the process we have introduced a new concept. That of a 

You say "a forrest:view is comparable with a view on a table of a db. It 
is a subset of data" and you say skinning "that is not the main focus of 

I would agree that forrest:views are akin to database views, but I would 
go a step further in the distinction between skinning and a view.

Skinning has *nothing* to do with views. It is a totally separate issue 
altogether. We can see this by looking back at the diagram in the above 
linked document:

                            internal plugins
                        (site.xml, abs-linkmap etc.)
           input format --> intermediate format --> output format
                         .                       .
                        /|\                     /|\
                         |                       |
                    input plugin            output plugin
                      (**.xml)         (**.html, **.pdf etc.)

Examining this diagram we see that views do not belong in output 
plugins, instead they belong in internal plugins. Only skinning should 
be in the output plugin.

OK, so is the plugin infrastructure incorrect or is it the current 
design of views that are incorrect?

Lets return to your observation that "a forrest:view is comparable with 
a view on a table of a db. It is a subset of data". The key thing about 
a view in a database is that it does not contain any data, it only 
contains information about what data should be presented.

However, in your current implementation you have data in the view. To be 
more accurate you have meta-data in the view. This meta-data is used to 
retrieve the real data, but it is still user data, it has no right in an 
output plugin.

Similarly it has no right in an internal plugin.

All data and meta-data must be available to Forrest at the very start of 
the pipeline, that is as an input format. There is the exception of 
dynamically generated meta-data such as indexes, but we are not dealing 
with that kind of data here.

To summarise I believe:

The project data directories contain the data and meta-data about the site

The input plugins convert the input data into the internal format

The views contain information that describes what data should be 
displayed in response to a specific request

The output plugins are responsible for skinning the data for display

So it would appear that the plugins architecture is correct and that we 
have to split the views from the skinning.


View raw message