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 16:57:18 GMT
On Thu, 2005-03-31 at 14:53 +0100, Ross Gardler wrote:
> 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. 
> >>>
> >>
> >></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?
> 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 
> >>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!
> 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">
>        <url>/feeds/somefeed.xml
>      </forrest:property>
>    </forrest:properties>
> </forrest:contract>
> 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.


very nice. I will implemented like that.

> More on this later.
> >>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?
> In my view we have to find out how, otherwise we end up mixing content 
> with layout, that is bad.

You just described how. ;-)

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

Your feedback is perfect, this way we implement the best solution. :)

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

Me too.

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


I think the former skins mechanism has to be split into an internal and
output plugin.

The internal plugin will pull the content (needed for the view) and
deliver it to the output plugin which looks up the implementation for
the specified format and displays it.

> However, in the process we have introduced a new concept. That of a 
> forrest:view.
> 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 
> views"
> 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?

The current design of views. ;-)

Ok. The skinning now takes place in the forrest:templates. 
Here we are storing the stylesheets that are needed for the last stage (transforming the content

and serialize it to the requested output format). 
They belong in a output plugin. 

The default.fv now defines which contracts should be rendered but as well defines which data
is needed.

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


...but you can parse params to the view to specify which sets of data
you want have returned, right?

> 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

Does this mean that:
<forrest:properties contract="feeder">
  <forrest:property name="feeder" nugget="get.nugget.feeder">

Should go there as well? 
Or do you think that can be compared with passing param to a view (see

> 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

<forrest:view type="xhtml"/> -> for xhtml requests

Agree, but right now it contains as well information about the placing
of elements.
<forrest:hook name="branding">
 <forrest:contract name="projectlogo"/>
 <forrest:contract name="searchbox"/>
 <forrest:contract name="nav-main"/>

<forrest:hook/> is a method to add design information to the outcome. It
will be render as <div id="{forrest:hook/@name}"/>. 

Would that be ok? If not what do you suggest?

> The output plugins are responsible for skinning the data for display

Agree. That means all the *.ft that we have now in the view would have
to go to a new output plugin, right? 

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

:) ok agree

One question, can I use the view.fv as config file for the skinning
stage as well?

project data -> input plugins -> views -> output
Request/response circle:    
1) The CLIENT requests an url
2) The url is linked to a view which will request 
3) the content from an input plugins, which will request the 
4) project data
5) then the view sends the aggregation of 3/4 to the 
6) skinning stage which will
7) response the CLIENT

The next steps would be to move the contracts pipes and implementations
to an output plugin. Change the views plugin to an internal plugin. 


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

View raw message