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/
