cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Flow as a block
Date Wed, 19 Mar 2003 16:38:36 GMT
Carsten Ziegeler wrote:
> 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


View raw message