Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43C67E4C.20004@nada.kth.se>
Date: Thu, 12 Jan 2006 17:05:32 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Block deployment: working with blocks from a user's point of
 view
References: <43C57CFF.6060308@apache.org> <43C668CE.6050208@nada.kth.se>
 <43C677B0.6030209@apache.org>
In-Reply-To: <43C677B0.6030209@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Reinhard Poetz wrote:

> Daniel Fagerstrom wrote:
>
>> Looks good!
>>
>> I will restructure the cocoon-blocks-fw projects so that it contains 
>> sub projects, then we can move the Schema files and configuration 
>> model beans, so that we share a common implementation.
>
>
> yes, good idea.
>
> I will also synchronize the schema files as I changed them a bit 
> compared to the files in /trunk/src
>
> With configuration model beans you mean the classes generated by 
> Castor, don't you?
>
> Do you have the intention to use the Castor classes in core? I'm not 
> really convinced we should do this as Castor comes with some 
> dependencies and as core mostly (only?) needs reading access to the 
> configuration files, I think we should use something that doesn't 
> introduce so many (or any) dependencies.

Agree about not using Castor for the blocks framework. On the same time 
it would be better to have a common model, but I don't know how to best 
achieve that. And maybe there is so little in common for the needs in 
the blocks fw and the deployer so that it isn't worthwhile.

/Daniel