Over 10 years of community discussion and knowledge are maintained here as a read-only archive.
puremvc_multicore\ # <- gem root lib\ puremvc\ multicore\ core\ patterns\
a_hash = Hash.newa_hash[nil] = "not nil at all"a_hash[false] = "might be true"a_hash["key"] = "value"a_hash[:key] = :another_value
Mediators hinder ruby's meta-programing strength.
class Proxy < PureMVC::MultiCore::Proxy Reference = :proxy_reference # notification constant def initialize(name, data) super(name, data) end def distribute_reference facade.send_notification(Proxy::Reference, self) end end
class ClassicMediator < PureMVC::MultiCore::Mediator def initialize(name, view) super(name, view) end def list_notification_interests [Proxy::Reference] end def handle_notification(note) case note.name when Proxy::Reference handle_proxy_reference(note) end end def handle_proxy_reference(note) p "Hello from mediator #{self} handler method, notified by proxy #{note.body}" end end
class AlternativeMediator < PureMVC::MultiCore::Mediator def initialize(name, view) super(name, view) end def initialize_mediator # super calls this, while initializing add_notification_handler(Proxy::Reference, :handle_proxy_reference) end # we can omit list_notification_interests and handle_notification because super-class handles them def handle_proxy_reference(note) p "Hello from mediator #{self} handler method, notified by proxy #{note.body}" end end
module ProxyAware def self.extended(mediator) # constructor-like method, called when this module extends an object mediator.add_notification_handler(Proxy::Reference, :handle_proxy_reference) end def handle_proxy_reference(note) p "Hello from mediator #{self} handler method, notified by proxy #{note.body}" end end
class ModuleExtendedMediator < PureMVC::MultiCore::Mediator def initialize(name, view) super(name, view) extend ProxyAware # we extent our instance via module ProxyAware end end
facade = PureMVC::MultiCore::Facade.new(:facade)proxy = Proxy.new(:proxy, nil)facade.register_proxy(proxy)facade.register_mediator(ClassicMediator.new("classic", nil))facade.register_mediator(AlternativeMediator.new("alternative", nil))facade.register_mediator(ModuleExtendedMediator.new("module", nil))proxy.distribute_reference
# => "Hello from mediator #<ClassicMediator:0x2e398cc> handler method, notified by proxy #<Proxy:0x2e39930>"# => "Hello from mediator #<AlternativeMediator:0x2e397c8> handler method, notified by proxy #<Proxy:0x2e39930>"# => "Hello from mediator #<ModuleExtendedMediator:0x2e39750> handler method, notified by proxy #<Proxy:0x2e39930>"
Mediators typically retrieve and cache references to their Proxy collaborators in the onRegister method. There usually isn't a need for a Proxy to send itself to a Mediator inside a notification. And when would the Proxy send this notification containing itself? What would trigger it? It can't be at or immediately after construction, as the Model is generally prepared before the View. This allows the Mediators to retrieve the Proxies they want to collaborate with. This would require an extra mechanism to tell the Proxies to send themselves AFTER Model and View preparation.
One of the big benefits of this framework is that its best practices aren't platform specific. They dictate the collaboration patterns of the actors, who exist in an abstract realm that is portable to many languages. So one of the dangers when porting is that we break the generally applicable best practices when we alter the framework implementation in order to take advantage of some platform specific magic.
I agree with adhering to platform conventions such as use of lower_case_and_underscore for method names as opposed to camelCase, if that's what developers are used to in the target platform/language. This is a trivial choice and none of the meaning is lost either way.
But best practices governing things like how a Mediator works and how the PureMVC actors collaborate need to remain as similar to the reference as possible, or confusion will reign.
There is currently only one Best Practices document, with AS3 examples, but the advice should remain valid for all ports without exception. The framework is simple enough in scope and implementation for this to be possible.
And while ostensibly all the contributors are supposed to tend their forums, the reality is I do the bulk of the support here. I'm in it for the long haul. So, when someone asks me a question about how to move data around in their application, I need to be able to dispense advice based on the core best practices without a lot of disclaimers about how the Frobnitz++ port does things differently and since I'm not a Frobnitz programmer I'm not sure I understand much about it.
And a developer (or team) using more than one port of the framework, should not find themselves having to apply two different approaches when they build or migrate their applications. They will find it particularly frustrating.In short, my vote is to veto these platform-specific mediator implementation alterations for the sake of of maintaining the core roles, responsibilities and collaborations of the reference.
I'm aware that there is no need to do this, but if i had chosen an example which incorporated wxruby, it would have been more complex to understand.
Agreed, but since ruby is all about open classes and duck-typing in which modules play an important role, i thought it would be a good idea to allow rubyists their daily dose of syntactic sugar
What about package-structure and naming?
Okay, i could refactor this into a separated "utility" to clearly distinguish between default behavior and additional features, but this is just for clarity and a little bit overkill.