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 12:57:52 GMT
El jue, 11-11-2004 a las 12:59, Nicola Ken Barozzi escribió:
> Thorsten Scherler wrote:
> > <snip/>
> ...
> > <forrest-template>
> >    <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"/>
> >      </contract>
> >    </hook>
> > </forrest-template>
> > 
> > That means every plugin delivers a contract that is registered in our 
> > contract list.
> Ok, but how will forrest render the open office plugin, contract?

Just thinking out loud:
1) A plugin has to be published to be integrated in forrest. When
publishing a plugin the author has to define contracts for the output.
Looking on xhtml that would be some functions that have some html code.
This contract then can be used for displaying the result.
2) The actual functionality is coming (is stored in) from the plugin.
Like the fct-bits/ dir in leather every plugin should contain such a
3) The last xsl of leather will render something like site for
site2xhtml.xsl. Then the actual skin will take the ft (forrest-template)
and render into the disered output. BTW maybe we should extend the ft a
wee bit more like:
<forrest-template output="xhtml" id="common"/> or
<forrest-template output="pdf" id="frontpage"/>

> ...
> > 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 
> >
> ...
> I am happy that we came to needa similar system from different starting 
> points. It means that something like this is really needed.
> I'll check your code ASAP.

Be aware that is total sandbox!!! I just started but could not keep on
because I had some other work to do. :(

> > If we use contracts instead of the
> > ....
> > <tabs/>
> > <metadata-item .../>
> > <nugget/>
> > <site/>
> > 
> > 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.
> I don't see that big value in this, but it seems reasonable :-)
> What puzzles me is that you seem to envision new contracts; I prefer to 
> keep not too many contracts, so that skins can render them... am I 
> missing something?

Contracts are already in our skins but we never took the time to name
them. That is not really true e.g.  <div id="skinconf-pdflink"/> is a
function with a given name but we have to write them down that we know
which functionality is aviable. The plan should be to harmonize this
naming with contracts.

Yes the skin has to take care of rendering them. Still we need to
capsulate the functions to reuse them whithout scanning to all skin xsl.

> > *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.
> Please expand.

The problem is what you wrote above "Ok, but how will forrest render the
open office plugin, contract?" by now we will have to add this manually
in the ft. I mean the 
<contract name="openofficeplugin">
   <metadata name="param" value="some value"/>
part. This should be normally done by adding a new plugin:

add plugin -> plugins adds the default contract and metadata to the ft
-> user can alter the ft -> user can implement his own implementation of
the contract

The other thing is that every plugin has to deliver a default output for
the skin. This is a fallback mechanism if the user do not want to
implemend his own implementation of the functionality.

The whole concept can be compared with the interface concept from java.
The interface is the contract. We will deliver a default implementation
of the contract.

I hope that explains it a wee bit more. ;-)


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

View raw message