On Thu, 2005-03-31 at 14:53 +0100, Ross Gardler wrote:
Thorsten Scherler wrote:
<snip what="lots of agreed stuff"/>
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.
exactly.
...but you can parse params to the view to specify which sets of data you want have returned, right?
Lets keep it simple at first - no paramaters (yet).
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"> <url>/feeds/somefeed.xml </forrest:property> </forrest:properties>
Should go there as well? Or do you think that can be compared with passing param to a view (see
above)?
I guess it should be in the content since the user should be defining what is going to be displayed. However, it probably doesn't want to get all mixed up with the content.
How about:
content/documentation/xdocs content/documentation/views/default content/documentation/views/user content/documentation/views/guest
etc.
This should probably be taken to a vote so lets get something working now and we'll decide where it actually lives with a vote against your proof of concept.
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>
<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?
This feels like the skinning end of things. I can imagine a use case in which we define a "user" view and then allow each user to define their own layout.
Therefore, I suspect that it should be separated out. What do you think?
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?
From what I understand so far, yes.
One question, can I use the view.fv as config file for the skinning stage as well?
Since views are now an internal plugin we can define new document schemas for passing information down the pipeline since they will be part of the internal system. Therefore, I do not perceive a problem with that.
Resume:
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.
This is all starting to feel much more comfortable for me now. I think we are tuning this nicely :-))
We are witnessing the major addition for Forrest 0.8 (if only we could get 0.7 out ;-))
Ross
