forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [RT] plugin infrastructure
Date Thu, 11 Nov 2004 10:16:52 GMT
>>>> 3 - extra data to be put on a page
>>>>      Since we have to aggregate, we need to specify a new section
>>>>      for information nuggets. This is to make all skins able to render
>>>>      them.
>>>>      The question is: how to add things to the nugget section?
>>>>      Seems like the last point of this mail is getting more
>>>>      important :-)
>>> This is more a problem of for skins than plugins. If we can solve the 
>>> matching problem above, and the skins can give us a way to hook into 
>>> them we have this solution.
>>> I think this last one is probably going a step too far at this stage. 
>>> Maybe we should put it on the back-burner for now - the solution may 
>>> turn out to be creating a portal plugin from the Cocoon Portal 
>>> Framework. (now it's time for someone to stop me!)
>> Stop! :-)
>> I thought about this today, and I think that we can start solving the 
>> problem by making it possible for the aggregate to have multiple 
>> metadata and nugget sections.
>> Instead of:
>> <skinconf/>
>>  <metadata>
>>    <item .../>
>>    <item .../>
>>  </metadata>
>>  <tabs/>
>>  <site/>
>>  <nuggets>
>>    <nugget/>
>>    <nugget/>
>>  </nuggets>
>>  <content/>
>> We make this:
>>  <skinconf/>
>>  <metadata-item .../>
>>  <tabs/>
>>  <metadata-item .../>
>>  <nugget/>
>>  <site/>
>>  <nugget/>
>>  <content/>
>>  <nugget/>
>> that can be easily (if ever needed) be transformed back to the nested 
>> format above, but is easy to create with multiple aggregates.
>> Question: how do we make it possible for *multiple* plugins to add 
>> content? Make every page the result of an xinclude of all plugin 
>> responses to the page request... isn't this too heavy?
> See Thorstens recent RT: 
> Does it work here?


Yes. That is the perfect use case for forrest-templates and my RT.

    <contract name="branding-trail-path"/>
    <hook name="intro">
      <contract name="grouplogo"/>
      <contract name="projectlogo"/>
      <contract name="search-input"/>
      <contract name="nav-main"/>
      <contract name="nav-main-sub"/>
      <contract name="openofficeplugin">
        <metadata name="param" value="some value"/>

That means every plugin delivers a contract that is registered in our 
contract list. I am working on a xml file that contains all contracts.

Every plugin can provide functionality that is stored as functionality 
nuggets (or as I use to call them "function-bit (fct-bit)").

One fct-bit or nugget can store the default output for different formats 
(including plugins) within it.

An example for a fct-bit can be found

The example above extends my RT a wee bit because I added
      <contract name="openofficeplugin">
        <metadata name="param" value="some value"/>

This should show the possibility to pass variables into the output. It 
better should be like:
      <contract name="openofficeplugin">
        <metadata name="param" value="$param"/>


By now I am using a directory generator (dir2contracts.xsl) to get all 
the fct-bits that are aviable within the fct-bits directory. That can be 
changed to some internal match.

I stated in
" <!--
1. check all aviable fct
2. check which fct are needed
3. check where to place them
4. output the xhtml

Until now I just played a wee bit around by copy the sitemap and xsl's 
into cocoon. I had a look at some plugins and would like to create a 
leather plugin.

The aim is that this plugin will be able to offer a hook mechanism that 
other plugins can use to provide new code. The outcome of this plugin 
should be IMO plain xml insted of xhtml like stated above.

The only problem that I have is 2. I would use something like fct.xml to 
define which fucntions are needed because matching them in skinconf is 
not really efficient due to the naming of the elements. I will have to 
implemend for each function a new match because they are not sharing 
some common name in skinconf. e.g. <disable-xml-output/> and <trail/>

It would be more efficient if we can use something:
   <fct-bit name="openofficeplugin" select="true"/>
   <fct-bit name="xml-content" select="false"/>

If we use contracts instead of the
<metadata-item .../>

we will be more flexible in the future because with the <tabs/> approach 
we saying something about the place and functionality of the plugin, but 
this should be more explicit. The other problem I see with that approach 
it is not easily extensable because we have named the elements 
tab,site,... This should be more abstract.

*Open issues*
The question is how to include/register new plugins. In the long run 
this should be done by Corium. The user can configure the skin with 
his/her forrest webapp. In the short term we should include it manually.


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

View raw message