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. :)
Well, it is pretty evident from all these discussions that flow is not a block but a module and modules represent *aspects* of the core and can't be removed without major refactoring/rearchitecting.
currently the flow in simplemented with a some 50Kb of java+javascript files inside cocoon.jar. I don't think those 50kb will kill anybody.
If you don't use them, you can avoid shipping rhino with it (there is nothing else used by the flow).
As for meaningful messages, the treeprocessor should give *meaningful* messages for everything that is missing, not only flow.
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.
If the treeprocessor doesn't pre-load instances of the interface that define those components, there is no direct reference. if this is not the case, it's a bug and it's easily fixed.
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.
This needs a specially crafted cocoon component manager or a treeprocessor-specific wrapper around it.
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?
Why can't se simply postpone module-creation this after 2.1? I don't think it's worth delaying further for a simple 50kb less of cocoon.jar
Stefano.
