Return-Path: 
 <dev-return-70660-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 31103 invoked from network); 24 Jan 2005 13:10:46 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 24 Jan 2005 13:10:46 -0000
Received: (qmail 64339 invoked by uid 500); 24 Jan 2005 13:10:40 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 64302 invoked by uid 500); 24 Jan 2005 13:10:40 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 64282 invoked by uid 99); 24 Jan 2005 13:10:39 -0000
X-ASF-Spam-Status: No, hits=-10.0 required=10.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from minotaur.apache.org (HELO minotaur.apache.org)
 (209.237.227.194)
  by apache.org (qpsmtpd/0.28) with SMTP; Mon, 24 Jan 2005 05:10:39 -0800
Received: (qmail 30974 invoked from network); 24 Jan 2005 13:10:38 -0000
Received: from localhost.hyperreal.org (HELO ?127.0.0.1?) (127.0.0.1)
  by localhost.hyperreal.org with SMTP; 24 Jan 2005 13:10:38 -0000
Message-ID: <41F4F451.5060601@apache.org>
Date: Mon, 24 Jan 2005 14:12:49 +0100
From: Carsten Ziegeler <cziegeler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
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>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: localhost.hyperreal.org 1.6.2 0/1000/N
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

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.
> 
> 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? 
Yes :)

> e.g. I like to use chained input 
> modules (i18n issues) or my own constants input modules.
> 
Hmm, the question is: how can a pluggable object model work - or how can 
it be extended? What about using...input modules for exactly this? We 
create a way of "mounting" input modules into the object model, like this:
<object-model>
   <mount input-module="skin" path="cocoon.skin"/>
</object-model>

And then you can simple access the info by ${cocoon.skin.something}.

Carsten