Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 53384 invoked by uid 500); 22 Aug 2002 08:52:51 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 53366 invoked from network); 22 Aug 2002 08:52:48 -0000 Message-ID: <3D64A630.1090702@apache.org> Date: Thu, 22 Aug 2002 10:52:00 +0200 From: Nicola Ken Barozzi Reply-To: nicolaken@apache.org Organization: Apache Software Foundation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: New "module" terminology: WAS: Extending the build system for modules References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Giacomo Pati wrote: > On Wed, 21 Aug 2002, Nicola Ken Barozzi wrote: > > >>Giacomo Pati wrote: >> >>>On Mon, 19 Aug 2002, Nicola Ken Barozzi wrote: ... >>The contract/interface of a block is the union of all the descriptions >>of what it exposes: >> >> >> 1) Avalon component(s) >> >>Not exposed, but Cocoon must be able to merge the supplied xconf with >>the Cocoon one. > > Merging is one way, a hierarchy of Containers/CM/SM the other. Yes. "Merge" conceptually. Though maybe in the beginning we can make a quick working system out of simple merging. I try to find the easiest solution ATM to get it working quick. >>In the future we should separate them from cobs and have Cocoon work ala >>Merlin via dependency descriptors. > > No, they are part of cobs. IMHO no. Avalon components can be used in other containers other than Cocoon, and so must be used as-is. The cob in the future should define he dependency in the descriptor, but not /necessarily/ contain the Avalon component itself. It will still be able to do contain them though, if they are tied to the Cocoon component ala couplet. >>But if we buy in this too soon we would just loose time, without real gain. > > Can you explain? If we try to build complete cob support from the start we will be doing a lot of work without knowing the impact, and use a lot of time and effort without knowing the outcome. I prefer baby-steps if possible, so that we can quickly have a working system, gain feedback, make it better, etc. >> >> 2) Cocoon component(s) >> >>Cocoon components will be automatically available as declared in the >>root sitemap.xconf. > > You think of a new config file (siteamp .xconf)? Cocoon components aren't > defined in sitemap.xmap but in cocoon.xconf. You are confusing me. ^^^^^^^^^^^^^^^^^ ... >>Similar to what done with the Avalon ones. >> >> >> 3) resources >> >> 4) examples >> >>Simply an URI set of values for the files and the list of the sitemap >>snippets that can be called, with human-readable description of what >>these do. >> >> >>All this would make the system usable right away without big problems, >>refactoring or design discussions. -- Nicola Ken Barozzi nicolaken@apache.org - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org