forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [RT] plugin infrastructure
Date Thu, 11 Nov 2004 11:59:43 GMT
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?

...
> Every plugin can provide functionality that is stored as functionality 
> nuggets (or as I use to call them "function-bit (fct-bit)").
> http://svn.apache.org/viewcvs.cgi/forrest/trunk/main/webapp/skins/leather-dev/xslt/xml/fct-bits/

> 
> One fct-bit or nugget can store the default output for different formats 
> (including plugins) within it.
> http://svn.apache.org/viewcvs.cgi/forrest/trunk/main/webapp/skins/leather-dev/xslt/xml/fct-bits/fct-bits.txt?rev=56699&view=markup

> 
> 
> An example for a fct-bit can be found 
> http://svn.apache.org/viewcvs.cgi/forrest/trunk/main/webapp/skins/leather-dev/xslt/xml/fct-bits/c-fontsize-fct.xml?rev=56669&view=auto

...

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.

> 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?

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

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message