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 - http://cocoon.apache.org/2.1/userdocs/concepts/errorhandling.html
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.
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.
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 http://forrest.apache.org/docs/dev/plugins/pluginInfrastructure.html#pluginTypes
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 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?
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.
Ross
