forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [HEADS-UP] fbits plugin is now org.apache.forrest.plugin.views
Date Fri, 25 Mar 2005 22:36:10 GMT
Thorsten Scherler wrote:
> I cleaned up the fbits plugin by moving all important stuff to
> org.apache.forrest.plugin.views and deleting the fbits plugin.

Bravo!!!

> If you are planing to use this plugin make sure you set your
> forrest.properties like follows (,... means all other plugins you need):
> project.skin=leather-dev
> project.required.plugins=org.apache.forrest.plugin.views,...

Does it *have* to go first? If so why?

The reason I ask is that in all the plugins I have built so far I have 
tried to avoid such things since if someone else builds a plugin that 
*has* to go first then there could be a compatability problem.


> How it works 
> ************

I can't wait to get my teeth into this.

> 3. views
>   prepares and transforms the requested contracts (fbits) and populate
> them with the content (nuggets).

...

> c. <map:match pattern="prepare.meta.*">
> Aggregate the forrest:properties requested by the *.fv.
> The result is an aggregation of properties which defines the templates
> to be call.

Why meta? Isn't this configuration data rather than meta data?

> d. <map:match pattern="prepare.xhtml.*">
> Aggregate all contracts-templates requested by the view.
> Create a xsl that can be used for the last step of the transformation of
> the view.

Dynamic XSL generation? How does this effect the performance of Cocoon? 
Can Cocoon still cache this and subsequent pipelines?

> Some basic and simple hints:
> a) If you want another implementation of a contract then create a folder
> "templates" in ${project.resources-dir} and it will be matched before
> the standard implementation. 

Cool.

Can we provide different contract implementations for different 
resources in the site? For example, I'd love to be able to create a set 
of contract implementations with some kind of matching mechanism 
deciding which is to be used at any given time.

> e.g. feedback contract:

For example, could your feedback contract example be made to provide a 
different feedback address for different sections of the site.

> b. If you want a default view for your project then copy the default.fv
> from the plugin to your ${project.conf-dir} and modify this file. When
> you want another view for a specific file (e.g. index.html) then copy
> the default.fv to your ${project.xdocs-dir} and renamed it to e.g.
> index.fv.

Ahhh.. perhaps this is how I would do the above, any chance of an 
example of how to do this?

> I am looking forward for your feedback and support. ;-)

As I keep saying, I am looking forward to playing with this. It looks 
like it potentially solves all the issues of per plugin configuration as 
you promised it would.

Great work - I just wish I could have dreamed of the plugins enabling 
something as cool as this.

Ross

Mime
View raw message