forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] plugin infrastructure
Date Thu, 11 Nov 2004 13:46:14 GMT
Thorsten Scherler wrote:
> El jue, 11-11-2004 a las 12:59, Nicola Ken Barozzi escribió:
>>Thorsten Scherler wrote:
>>>   <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>
>>>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
> dir.
> 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"/>

I am very sorry, but I don't think I understand it fully. :-(

(I'm leaving out the parts I understand and agree with)...

> 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"/>
> </contract>
> part. 

what does the above xml mean? Who writes it?

>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

User? Who are you referring to here? Our users are documentation writers.

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

Are we not mixing content (plugins) with style (skins) ?

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

Too generic, I don't understand. :-(   (yet ;-)

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message