forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: [HEADS-UP] fbits plugin is now org.apache.forrest.plugin.views
Date Sat, 26 Mar 2005 01:36:30 GMT
On Fri, 2005-03-25 at 22:36 +0000, Ross Gardler wrote:
> 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?
> 

no! I just had it like that in my first sample pub. ;-)

Actually I have now
project.required.plugins=org.apache.forrest.plugin.pdf-output,org.apache.forrest.plugin.views

> 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.
> 

hmm, now you've got me thinking. ;-) 

The first plugin mentioned got as well mounted first?

I mean the views are right now only working for xhtml but I thought
about them format independent. Each contract can have different format
implementation. 

That would mean when we add pdf implementations that they got matched
after the default pdf-output, right? 

> 
> > 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?
> 

Yeah, agreed. We should rename it.

> > 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?
> 

Sorry, I can not say anything on that. 

Finding this as solution of my former problem of xsl:includes and
compile time I did not thought about that. ;-)

...but now that we know how it could be done, we can redefine the
architecture where appropriate.

> > 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.
> 

You would have give me an example but reading the above I think so. :)

I have not implemented yet but the idea is to pass some param with the
view to the templates. 

> > 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.
> 

Ok, you once told me to read everything before answering. ;-) 

Yeah, that leads use to the old skinconf discussion. ATM we are storing
the input for the feedback here but IMO that should go into the view as
properties.

> > 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?
> 

Yeah, I will try to provide an example.

> > 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.
> 

:)  

...ATM I see it more like a prototype. It shows the basic idea I was
always talking about. Whether it solves all problems we have to see. ;-)

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

You did!!! 

The basic ideas of enabling the views and templates are borrowed from
the concept we defined to plug the plugins into our main sitemap.

Thanks for the compliment that I can instantly return. 

> Ross

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


Mime
View raw message