Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: forrest-dev@xml.apache.org
Message-ID: <4023D765.7060501@apache.org>
Date: Fri, 06 Feb 2004 14:05:25 -0400
From: Ross Gardler <rgardler@apache.org>
Organization: saafe.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.4) Gecko/20030624 Netscape/7.1
MIME-Version: 1.0
To: forrest-dev@xml.apache.org
Subject: Plugin Use cases (was: Re: [VOTE] Forrest adopting Alexandria?)
References: <c003bq$7om$1@sea.gmane.org> <4023A8DC.6080506@apache.org>
 <c00fe3$g2o$1@sea.gmane.org>
In-Reply-To: <c00fe3$g2o$1@sea.gmane.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
> 
>> Nicola Ken Barozzi wrote:
>>
>>>
>>> I think that moving it in Forrest would be beneficial both to the 
>>> Alexandria code, and to Forrest.
>>
>>
>>
>> +0
>>
>> My only concern is that this is pretty specific functionality of use 
>> to only a certain type of site, i.e. project sites. I have no problem 
>> with the functionality being there, it's just I don;t need it right now.
> 
> 
> It would be available initially as a separate subcode, and available as 
> a separate forrest run command (ie 'forrest code')

Cool, can't see that getting in the way of anything else. I'd be +1 but 
for time restrictions right now, I know I will use this at some point in 
the future.

>> Would such extensions be made available via some kind of plug-in 
>> framework (eventually). I ask because I have a number of extensions in 
>> my own work that would benifit specific use cases, but aren't really 
>> applicable to the core Forrest system.
> 
> 
> Plugins for the processing are planned, so it should be able in the 
> future to have a plugin add schemas that can be processed. What 
> extensions are they (it could help to refine the plugin usecase)?

Right now it is mainly stuff we have talked about in the past. For 
example, the generation of slides from my source document as well as 
normal HTML/PDF etc. My source documents are not always in a "usefull" 
format, for example, java code. I think this is a similar use case to 
creating, for example, the JavaDoc code from a java source file. What 
would happen is that some component would extract the key information 
from the Java code (marked up with comments).

Another would be the use of MathML or TeX to create mathematics markup 
(via SVG) as discussed in a recent thread. This may require the addition 
of a Cocoon component to Forrest, but most users will not need this 
component.

My requriements go further in that I need to be able to create a dynamic 
version of the site too (interactive tutorials for example). So, in most 
cases, I am wanting to put functionality into the version of Cocoon 
shipped with Forrest. Some of this will massively increase the size of a 
Forrest distribution and isn't applicable to most (current) Forrest 
uses. Therefore, it really needs to be separate from the core of Forrest.

Recently I've been thinking that I should be working from the other 
direction. That is I should be starting with Cocoon and bringing a 
Forrest generated webapp into that. I've not really sat down to work out 
the best route yet.

Ross