cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
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 
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)

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

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.

-- 
Stefano.


Mime
View raw message