cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Ezkovich <>
Subject Re: Blocks, Flow and Dependencies [was RE: Splitting xconf files step 2: the sitemap]
Date Tue, 11 Jan 2005 15:47:04 GMT
I really hate to say anything about this but ...

On Jan 11, 2005, at 8:57 AM, Stefano Mazzocchi wrote:

> Reinhard Poetz wrote:
>>>> Answer: It depends on the order of declaring your scripts in 
>>>> <map:flow/>. The first helper() method declared will be found.
>>> But there is only one helper() method per block!?
>> Yes. Therefore we need something more sohpisticated than imports.
> I'm having a hard time following this conversation, as it seems to me 
> that this is another instance of something that is becoming an 
> anti-pattern: "stating the solution before stating the problem".


> The problem is that you want to use some functionality defined in 
> another block.
> Fair enough, since that's what blocks are: isolated service providers.
> One of the design decisions with blocks is that *NO FILE* will ever be 
> exposed by the blocks directly.

I took this to mean through the file system directly. I believe in all 
my examples I used a block pseudo protocol to locate the javascript 

> There is practically no way in the world you are going to change my 
> mind on that, so consider it a permanent -1 for a block to expose 
> direct file access.
> Blocks *may* expose their sitemap pipelines but nobody said that they 
> couldn't expose flow functions too (which are the flow equivalent of 
> sitemap pipelines)

I think the issue was how they would expose these functions. I see it 
as a relatively simple matter of block configuration, loading the 
functions and designing the functions properly for use by other blocks. 
If the javascript functions were not intended for this purpose they 
should not be exposed.

> Now, blocks have different composition patterns:
>  - dependency
>  - extension

Do you mean 2 types of dependency, composition and extension?

> the two will, IMO, result in different ways of composing flow 
> functions.
> Dependency can make available, either implicity or explicitly thru a 
> cocoon.importDependencies() the block's dependencies.

I don't understand what you mean here. Do you mean that, say in the 
flowscript instead of using load we use importDependencies defined in 
the blocks configuration?

> Since javascript has no notion of "private/public" for functions, we 
> could specify that functions that start with _ are "private", while 
> the other ones are "public". Or something like that.

it works for me, but is this an issue we can solve or does this depend 
on Rhino?

> For extension, we could have automatic overload, so that if block A 
> has flow with function blah() and block B extends block A with 
> function blah() you can do
>  block b:
>   blah() {
>    cocoon.super()
>    print "blah b"
>   }
>  block a:
>   blah() {
>    print "blah a"
>   }
> if block b extends block a, calling blah() on b will result in
>  blah a
>  blah b

Since when does javascript have an extension mechanism? Are you sure 
this is necessary or even a good idea. If you wish to use extension and 
overloading use Java flow.

> There is *NO* need for direct file access and there is *NO* need for 
> namespaces in javascript.

umm.. packages would be nice ;-) One of the many reasons I hope to 
convert to Java flow.

> I understand the above might not be easy to implement, but 
> implementation difficulty should *never* drive design decisions.

This isn't about design its about functionality. Its about what one 
should be able to do with javascript functions defined in a foreign 
block. The design you are talking about here is designing an extension 
hack for javascript, not an architectural design of the system that 
implements it. In this case difficulty should play a role in the 
decision on whether to attempt this.

> -- 
> Stefano.

Glen Ezkovich
HardBop Consulting
glen at

A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to 
worry about answers."
- Thomas Pynchon Gravity's Rainbow

View raw message