[HEADS-UP] fbits plugin is now org.apache.forrest.plugin.views

[Thorsten Scherler <th...@apache.org>]

Hello devs,

I cleaned up the fbits plugin by moving all important stuff to
org.apache.forrest.plugin.views and deleting the fbits plugin.

The org.apache.forrest.plugin.views is overriding the last step of the
skin-it pipe. So far all needed resources (img,..) are stored in the
leather-dev skin. I am still using great parts of those skin pipes. The
default implementation of the css is based on the scale-dev css
enhancement of leather-dev.

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


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

(taken from SOME comments of the output.xmap of views)

This plugin has three components:
  1. fbits - delivers contracts in form of xsl:templates
  2. nuggets - delivers content that is used in the contracts
  3. views - prepares and transforms the requested contracts (fbits) 
     and populate them with the content (nuggets)


          request            request
+-------+<<--------+-------+-------->>+---------+
| fbits |          | views +          | nuggets |
+-------+-------->>+-------+<<--------+---------+
          response           response  


1. fbits
  This is the template producing factory.

a. <map:match pattern="resolve.contract.*"> -> Resolving factory
Project implementation of templates have priority before default ones.
If no implementation can be found we use the noFt (~ - no
forrest:template) implementation.

b. <map:match pattern="get.contract.*.*">
Get the xsl:templates of the requested contract and specific format.

c. <map:match pattern="get.contract-meta.*">
Get the forrest:properties of the requested contract. 
This will determine which templates (css, head, body) we have to call
later on

GENERAL:
Contracts are stored in forrest:templates ({contract-name}.ft) please
have look on
plugins/org.apache.forrest.plugin.views/resources/templates/*.ft do get
an idea how your own implementation have to look like.


2. nuggets
  This is the content producing factory.

NOTE: <map:match pattern="*.page">
The current factory uses the skin producing templates (e.g.
document2xhtml.xsl).
It is only exchanging the last step of a skin producing pipe
(site2xhtml.xsl) till now.
This will have to be changed in the future.


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

a.  <map:match pattern="prepare.view.*"> -> View config resolver
File specific views have priority before default ones.
If no view can be found in the project we use the default one of the
views plugin.

b.  <map:match pattern="prepare.include.*"> 
Aggregate the contract-templates requested by the view with xinclude.
The result is a stylesheet with all needed xsl:templates.

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.

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.

e. <map:match pattern="*.html"> -> Last processing step. 
Here we are overriding the default skin generation.

GENERAL:
Views are stored in forrest:view ({file-name}.fv) please have look on
plugins/org.apache.forrest.plugin.views/src/documentation/default.fv do
get an idea how your own implementation have to look like.

Known issues
************
- The generation of the linking is not working.
- Menu /innermenu templates are added directly. Add support for
additional templates support.
- Uses resources of leather (document2html.xsl defines the pdf/xml/...
link this have to be done by the template).
- The views are only working for html so far
- The css support and implementation is VERY basic
- Only first level files are working
- ...

Resume
******
The views plugin can be seen as prototype for the next generation
skinning of forrest. It is still in early stage but with the cleanup I
hope to make it easier for all devs (not only committer) to get the idea
and help to enhance it.

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. 

e.g. feedback contract:
<forrest:contract name="feedback" type="nugget"
  xmlns:forrest="http://apache.org/forrest/templates/1.0">
<description>
This function will output the html feedback information.
</description>

<forrest:template
xmlns:forrest="http://apache.org/forrest/templates/1.0"
format="xhtml" name="feedback" inputFormat="xsl" body="true"
head="false" css="true">

<xsl:stylesheet version="1.1" 
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">

<xsl:template name="feedback-css">
#feedback {
    color: black;
    background: #CFDCED;
    text-align:center;
    margin-top: 5px;
}
#feedback #feedbackto {
    font-size: 90%;
    color: black;
}</xsl:template>

<xsl:template name="feedback-body">
<div id="feedback"> Modified project implementation
<xsl:value-of select="$config/feedback"/>
<xsl:choose>
<xsl:when test="$config/feedback/@href and
not($config/feedback/@href='')">
  <a id="feedbackto">
    <xsl:attribute name="href">
      <xsl:value-of select="$config/feedback/@href"/>
      <xsl:value-of select="$path"/>
    </xsl:attribute>
    <xsl:value-of select="$config/feedback/@to"/>
  </a>
</xsl:when>
<xsl:otherwise>
  <xsl:value-of select="$config/feedback/@to"/>
</xsl:otherwise>
</xsl:choose>
</div>
</xsl:template>
</xsl:stylesheet>
</forrest:template>
</forrest:contract>

The @attributes (body="true" head="false" css="true") of the 
forrest:template defining which parts of the html page (head, head-css
and body) we have to render. The xsl:templates are following the simple
naming convention {@name}-(css|head|body).


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.

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


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 <th...@apache.org>]

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, thorsten@apache.org 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="webmaster@dyn-foo.com"
    href="mailto:webmaster@dyn-foo.com?subject=Feedback&#160;" >
     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)

Re: [HEADS-UP] fbits plugin is now org.apache.forrest.plugin.views

[Ross Gardler <rg...@apache.org>]

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.

+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

[Thorsten Scherler <th...@apache.org>]

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)

Re: [HEADS-UP] fbits plugin is now org.apache.forrest.plugin.views

[Ross Gardler <rg...@apache.org>]

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