Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 50269 invoked from network); 13 Jul 2007 21:06:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Jul 2007 21:06:48 -0000 Received: (qmail 69580 invoked by uid 500); 13 Jul 2007 21:06:49 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 69334 invoked by uid 500); 13 Jul 2007 21:06:49 -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 List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 69322 invoked by uid 99); 13 Jul 2007 21:06:49 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jul 2007 14:06:49 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [216.86.168.179] (HELO mxout-04.mxes.net) (216.86.168.179) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jul 2007 14:06:46 -0700 Received: from [192.168.0.129] (unknown [80.240.191.89]) by smtp.mxes.net (Postfix) with ESMTP id B2B37A3233 for ; Fri, 13 Jul 2007 17:06:24 -0400 (EDT) Message-ID: <4697E949.20702@apache.org> Date: Fri, 13 Jul 2007 23:06:17 +0200 From: Grzegorz Kossakowski User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Clarification on converter concept References: <468AA7E9.7020902@tuffmail.com> <468AC988.60809@gmx.de> <468C2397.9060105@apache.org> <468F2540.2070109@gmx.de> <469397E9.20900@apache.org> <4695653A.9060605@gmx.de> <46977D9C.2080409@apache.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Joerg Heinicke pisze: > Grzegorz Kossakowski apache.org> writes: > >> I mentioned that snippet as an example how registry could work; my aim was to >> show that we use declarative approach instead of registering converters/ >> property editors manually. > > Ah, got it. :-) Though the names are a bit irritating. Aren't the > ExpressionCompilers actually the factories and isn't the ExpressionFactory more > of a registry? It's also a bit strange that the Expressions must be aware of the > prefix they are mapped to (Expression.getLanguage() + constructors of > implementations). Any reason for that? Good point about names. I'll consider to rename this classes since I don't consider them as any public API (it was used in template block only to date). When it comes to prefix and getLanguage() method, I don't know really. Eclipse tells me that this method is not us anywhere in Cocoon so I think it redundant. Before removing it I'll try to search archives. This stuff is really work in progress and comes as legacy so I don't know answers for all questions... > Something similar exists for the PropertyEditors, the PropertyEditorRegistrar > [1]. You are only supposed to implement it yourself which more or less means to > add the PropertyEditors programmatically. Since I did not want to do this, I > wrote a MapBasedPropertyEditorRegistrar (matching more or less > DefaultExpressionFactory) which I could at least configure from Spring. > spring-configurator's BeanMap seems to go one step further and searches for all > implementations of a particular interface in the application context. How your MapBasedPropertyEditorRegistrar knows path at which particular editor should be registered? Spring configurator stuff is really handy and has no Cocoon dependencies so its wise to use it. Joerg, you seem to sit inside Spring community, have you considered giving Carsten a present by promoting his stuff? I really think it should get more attention. :-) -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/