Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41F4EFA0.3050704@nada.kth.se>
Date: Mon, 24 Jan 2005 13:52:48 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: FOM & input modules
References: <csrfka$lku$1@sea.gmane.org> <41F14560.9080100@apache.org>
 <41F17A62.4060600@mobilebox.pl> <41F237E3.9050708@apache.org>
 <41F2428C.9090804@mobilebox.pl> <41F243E1.1050307@mobilebox.pl>
 <41F27653.4040200@nada.kth.se> <csub51$t9l$1@sea.gmane.org>
 <41F3C092.8080208@nada.kth.se> <41F4960A.9080303@apache.org>
 <41F4CD21.50804@nada.kth.se> <41F4E09D.8000608@apache.org>
In-Reply-To: <41F4E09D.8000608@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Reinhard Poetz wrote:

> Daniel Fagerstrom wrote:
>
>>
>> Please note that I'm not suggesting to remove the current input 
>> modules. This is all about making Cocoon more coherent, not about 
>> introducing back incompability. If we find a good way to replace 
>> input modules I would suggest that we move them from core to an input 
>> module block so that they become optional.
>>
>> WDYT?
>
>
> Having only one input module that uses a Cocoon wide object model is 
> IMO a good idea. We should go through the list of all input modules 
> and look where it makes sense to extend the object model.

I wrote the slightly commented list of  input modules that you cutted 
away from my post in the hope of geting some input about that. I use 
modules that overlaps with FOM in nearly all of my sitemaps so I don't 
have much opinion about the more exotic modules.

The things that I need that not is part of FOM is some type of handling 
of global or sitemap specific data corresponding to e.g., DefaultsModule 
or GlobalInputModule. But it is rather the handling of application 
parameters than the actual input module solution that I need.

Also I have used the BaseLinkModule and some own module for URL 
rewriting purposes.

Both application parameters and better sitemap related URL handling 
could be part of the Context object IMO.

> Creating a modules block that contains all existing input modules for 
> backwards-compatibility sounds good to me too.
>
> One question remains: Should it be allowed to add your 
> project-specific extenstions to the object model? e.g. I like to use 
> chained input modules (i18n issues) or my own constants input modules.

Could you explain your use case a little bit more.

Considering allowing project specific object model extensions, if we add 
better URI and application parameter handling to e.g. the context 
object, I'm satisfied with that. For project specific extensions I think 
flowscript will be enough especially if we make it easier to use with 
(flow)script actions.

But Carsten seemed to see a need for plugable object model extensions 
and maybe other does. Please describe your use cases so that we can 
discuss how to solve them.

/Daniel