Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 13836 invoked by uid 500); 19 Mar 2003 13:48:18 -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 13818 invoked from network); 19 Mar 2003 13:48:17 -0000 Received: from unknown (HELO pulse.betaversion.org) (217.158.110.65) by daedalus.apache.org with SMTP; 19 Mar 2003 13:48:17 -0000 Received: (qmail 28188 invoked from network); 19 Mar 2003 13:48:17 -0000 Received: from unknown (HELO apache.org) (stefano@80.105.91.155) by pulse.betaversion.org with SMTP; 19 Mar 2003 13:48:17 -0000 Message-ID: <3E787532.5040106@apache.org> Date: Wed, 19 Mar 2003 14:48:34 +0100 From: Stefano Mazzocchi User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [RT] Flow as a block References: <3E7839A1.8030400@anyware-tech.com> In-Reply-To: <3E7839A1.8030400@anyware-tech.com> 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 Sylvain Wallez wrote: > Carsten Ziegeler wrote: > >> Sylvain Wallez wrote: >> >> >>> But won't work :-( >>> >>> >> >> :) >> >> >> >>> Why ? Well, yes, a sitemap element = a builder class. But the >>> configuration file that defines them is used to feed a >>> ComponentSelector, which will try to load the class and the result is >>> that you will get an Exception in the initialization phase of the >>> TreeProcessor... >>> >>> The only viable solution is for the declaration to be _not present_ in >>> the treeprocessor configuration. >>> >>> >> >> This is not the best solution, as it would required to change the >> treeprocessor conf for adding/removing flow. >> >> Could the treeprocessor check the availability of a class before feeding >> it into the selector? If the class is not available, a dummy >> implementation >> could be perhaps added that could - when used - throw a meaningfull >> exception. >> >> > > Well, this would mean rewriting a ComponenentSelector specifically for > this purpose, since the TreeProcessor does nothing more than delegating > all this stuff to a CS : see DefaultTreeBuilder.createBuilderSelector(). > > Mmmh... A good solution may be to have a FakeFlowNodeBuilder that > delegates to a RealFlowNodeBuilder if it's present in the classpath, and > otherwise fails with a nice error message saying that the flow isn't > installed. > > That way, we don't have to open wide the sitemap language definition, > which could lead to abuses : map:flow becomes an optional element that > is however pre-configured in the sitemap definition. Just drop in the > flow jar and it becomes available, without touching a single > configuration file. > > Thoughts ? I personally don't like it. Adding fake facades for just one thing doesn't sound right at all. I think that Carsten's problem is to have an external dependency on the rhino jar. Please, Carsten, correct me if I'm wrong. Now, if my sitemap doesn't use *any* flow elements, would the jar need to be in the classloader? Stefano.