Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 66279 invoked from network); 31 Mar 2004 08:36:27 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 31 Mar 2004 08:36:27 -0000 Received: (qmail 93397 invoked by uid 500); 31 Mar 2004 08:35:57 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 93370 invoked by uid 500); 31 Mar 2004 08:35:56 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 93349 invoked from network); 31 Mar 2004 08:35:56 -0000 Received: from unknown (HELO smtp1.xs4all.be) (195.144.64.135) by daedalus.apache.org with SMTP; 31 Mar 2004 08:35:56 -0000 Received: from outerthought.org (otsrv1.iic.ugent.be [157.193.121.51]) (authenticated bits=0) by smtp1.xs4all.be (8.12.10/8.12.10) with ESMTP id i2V8a7PQ005139 for ; Wed, 31 Mar 2004 10:36:08 +0200 Message-ID: <406A82F6.6020303@outerthought.org> Date: Wed, 31 Mar 2004 10:36:06 +0200 From: Marc Portier Organization: Outerthought User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [cforms] Custom Binding. References: <40682D70.1010502@outerthought.org> <4068B8FB.1080306@gmx.de> <40691798.1010305@outerthought.org> <406A0CAA.5070202@gmx.de> In-Reply-To: <406A0CAA.5070202@gmx.de> 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 X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Joerg Heinicke wrote: > On 30.03.2004 08:45, Marc Portier wrote: > >> hm, if SoC is the argument, then shouldn't we consider the who is >> doing what discussion? >> >> my feeling is that touching the xconf is out of question to a lot of >> users? They could easily write up a custom-binding and be glad they >> never need to learn about the xconf in the first place? > > > I don't know if I follow this argumentation. Having configuration > splitted over multiple files might help the user at the beginning, but > can lead to a nightmare at the end. But maybe I just want to do anything > to perfect :) > nope, I think you are right, and I have to admit the xconf is not the real pain here, but I doubth it would help: the only config part that would make sense on the xconf level is the class-name, the rest would be local config that needs to be in the binding file anyway (like you say: why scatter it around in different places?) see: the big goal of this thingy would in fact to throw in a custom binding when the jxpath isn't helping out, this calls for a simple straightforward class IMHO (like the nested fb:javascript/on-save and on-load code) and only if people think they need the additional local-config then they should provide a factory method that nows how to deal with that at that moment I think jxpath and/or avalon dependencies are just over the top for the binding-problem the user wants to solve? wdot? -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ mpo@outerthought.org mpo@apache.org