cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Blocks, Flow and Dependencies [was RE: Splitting xconf files step 2: the sitemap]
Date Tue, 11 Jan 2005 14:57:13 GMT
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.

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 

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)

Now, blocks have different composition patterns:

  - dependency
  - 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.

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.

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() {
    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

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

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


View raw message