cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <>
Subject Re: [RT] Flow as a block
Date Wed, 19 Mar 2003 17:12:35 GMT
Uh, Rhino isn't only used by the flow. It appears to also be used by:

Also, for what it's worth, although the jxpath jar is in lib/optional 
there seem to be dependencies on it elsewhere in the core (not just in 
flow code), e.g:


Do you hava a plan for removing the InputModule and XMLForm code from 
the core as well?



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. :)
>>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

View raw message