On Fri, 2005-03-25 at 22:36 +0000, Ross Gardler wrote:
...
> > 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?
>
I changed all appearance of meta to properties/property.
> > 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?
>
hmm, I get heaps of
java.net.MalformedURLException: unknown protocol: cocoon
in the core.logs but the site renders fine.
Somebody an idea how to fix that?
> > 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.
>
BTW I found out that developing the f:t in a fresh seed project and not
the plugin itself saves the build time. ;-) Trying to say the project
specific implementations seems to working fine and useful. :)
> 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?
>
On Sat, 2005-03-26 at 04:32 +0000, [EMAIL PROTECTED] wrote:
> Author: thorsten
> Date: Fri Mar 25 20:32:38 2005
> New Revision: 159093
>
> URL: http://svn.apache.org/viewcvs?view=rev&rev=159093
> Log:
> example for a dynamic contract reading from the view properties.
The only different between the feedback-dyn and feedback is that I added
<xsl:param name="main"/> to the implementation and changed the matches
from $config to $main. You can see the commit message for further
changes. ;-)
You will have to add the following code to your forrest:view:
<forrest:contract name="feedback-dyn">
<forrest:properties contract="feedback-dyn">
<forrest:property name="main">
<feedback to="[EMAIL PROTECTED]"
href="mailto:[EMAIL PROTECTED] " >
Send DYNAMIC feedback about the website to:
</feedback>
</forrest:property>
</forrest:properties>
</forrest:contract>
The idea is to have one implementation of the contract but the
configuration is determined in the view.
We need to work on the nugget part of the plugin. The idea would be to
parse forrest:nuggets to the contracts directly.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
