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. 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.
The content to go in the RSS Feed box is still generated by requesting "rssFeed.xml", we still get XDoc back. All that needs to change is how we skin it.
Ross
