forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [DISCUSS] feeder plugin contract in the view
Date Thu, 31 Mar 2005 17:36:03 GMT
Thorsten Scherler wrote:
> 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

Mime
View raw message