cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Flow as a block
Date Wed, 19 Mar 2003 14:01:46 GMT
Stefano Mazzocchi wrote:

> 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? 


Nope, since the flow-related treeprocessor classes deal with flow 
interfaces rather than with the JS implementation. So we need the 
flow-related interfaces (only o.a.c.c.flow.Interpreter AFAICS) to be 
present in the core, but can perfectly live without the implementation jars.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



Mime
View raw message