Re: [HEADS-UP] fbits plugin is now org.apache.forrest.plugin.views
Thorsten Scherler wrote: On Fri, 2005-03-25 at 22:36 +, 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. 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. +1 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... ) Ross
Re: [HEADS-UP] fbits plugin is now org.apache.forrest.plugin.views
On Fri, 2005-03-25 at 22:36 +, Ross Gardler wrote:
...
> > c.
> > 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.
> > 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 +, [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
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:
mailto:[EMAIL PROTECTED] " >
Send DYNAMIC feedback about the website to:
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)
Re: [HEADS-UP] fbits plugin is now org.apache.forrest.plugin.views
On Fri, 2005-03-25 at 22:36 +, 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.
> > 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.
> > 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)
Re: [HEADS-UP] fbits plugin is now org.apache.forrest.plugin.views
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.
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.
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
