cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] Flow as a block
Date Wed, 19 Mar 2003 14:46:36 GMT
Stefano Mazzocchi wrote:
> 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.
> 
Not exactly. Yes, I don't want to have the rhino jar (and possibly others
only used by flow). But I also want to have meaningful error messages,
if I use flow in the sitemap but does not have "installed" flow. 
And if, for example, flow would be implemented by "a lot of classes" in
Cocoon, I also don't want to have this overhead.
So, in the end: if I don't want to use flow in my app, I simly don't want
any part of it, neither any jars nor any compiled cocoon flow stuff. :)

> Now, if my sitemap doesn't use *any* flow elements, would the jar need 
> to be in the classloader?
I don't think that this is always working. If a flow class in Cocoon
directly references/uses one of the rhino classes, then this might cause
problems.

So, getting technically: the treeprocessor uses a selector that returns
for an element used in the sitemap the corresponding builder. I still
think, that this selector could return a dummy implementation, if the
required builder class is not available.
The flow would still be configured in the tree processor configuration
and I can leave out everything of the flow stuff if I don't need it.
And in addition: the dummy implementation can give meaningful error
messages.

What do you think?

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://radio.weblogs.com/0107211/

Mime
View raw message