forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [HEADS-UP] fbits plugin is now org.apache.forrest.plugin.views
Date Sat, 26 Mar 2005 10:33:43 GMT
Thorsten Scherler wrote:
> On Fri, 2005-03-25 at 22:36 +0000, Ross Gardler wrote:
>>Thorsten Scherler wrote:


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

The view for PDF should not be outputting PDF it should be outputting 
FO, this means that the **.pdf requests are handled by the pdf-output 
plugin and the **.fo requests by the view. So it doesn't matter what 
order they go in.

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

If it becomes an issue, we'll fix it. I'm not too familiar with Cocoon's 
internals but recently I have started to find myself in there. SO I'm 
learning about this stuff.

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


>>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, you clearly do what I do - reply as reading, it can be 
counterproductive sometimes, but I never seem to learn.

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

OK, so it is not possible, yet, but should be. We can come back to this 
when what you have done so far solidifies.

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

Yeah, Open Source is cool - it still amazes me how these things spring 
up out of nowhere. It was actually Nicola Ken that started all this with 
his introduction of the pass-through sitemap for individual projects. 
(not forgetting Forrest itself before that, and cocoon before that and... )


View raw message