Return-Path: 
 <dev-return-13743-apmail-forrest-dev-archive=forrest.apache.org@forrest.apache.org>
Delivered-To: apmail-forrest-dev-archive@www.apache.org
Received: (qmail 5128 invoked from network); 11 Nov 2004 12:01:40 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 11 Nov 2004 12:01:40 -0000
Received: (qmail 53940 invoked by uid 500); 11 Nov 2004 12:01:39 -0000
Delivered-To: apmail-forrest-dev-archive@forrest.apache.org
Received: (qmail 53704 invoked by uid 500); 11 Nov 2004 12:01:38 -0000
Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@forrest.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@forrest.apache.org>
list-post: <mailto:dev@forrest.apache.org>
Reply-To: dev@forrest.apache.org
Delivered-To: mailing list dev@forrest.apache.org
Received: (qmail 53693 invoked by uid 99); 11 Nov 2004 12:01:38 -0000
Received-SPF: pass (hermes.apache.org: domain of
 cjxaf-forrest-dev-1@m.gmane.org designates 80.91.229.2 as permitted sender)
Received: from [80.91.229.2] (HELO main.gmane.org) (80.91.229.2)
  by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 11 Nov 2004 04:01:38 -0800
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1CSDdt-00025E-00
	for <dev@forrest.apache.org>; Thu, 11 Nov 2004 13:01:33 +0100
Received: from 62.156.150.201 ([62.156.150.201])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <dev@forrest.apache.org>; Thu, 11 Nov 2004 13:01:33 +0100
Received: from nicolaken by 62.156.150.201 with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <dev@forrest.apache.org>; Thu, 11 Nov 2004 13:01:33 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: dev@forrest.apache.org
From: Nicola Ken Barozzi <nicolaken@apache.org>
Subject: Re: [RT] plugin infrastructure
Date: Thu, 11 Nov 2004 12:59:43 +0100
Lines: 72
Message-ID: <cmvkak$29e$1@sea.gmane.org>
References: <cmab28$uo$1@sea.gmane.org> <4188E497.4080803@apache.org>
 <cmdast$dd0$1@sea.gmane.org> <418BB394.3090909@apache.org>
 <cmi7tb$7ls$1@sea.gmane.org> <418F92EC.2050205@apache.org>
 <cmspvi$r72$1@sea.gmane.org> <419252D1.4010103@apache.org>
 <cmve6j$fi4$1@sea.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 62.156.150.201
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
In-Reply-To: <cmve6j$fi4$1@sea.gmane.org>
Sender: news <news@sea.gmane.org>
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

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