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.
