How to mediate non visual elements
I'm using publish/subscribe messaging to listen for messages with specific subtopic topics from a server. I'm creating an object to have a number of Consumers objects for listen for specific topics. This object is effectively a View but has no visual elements and I want to setup a meditator for it.
This object would be in fx:Declarations in the main view, but what would this object inherit from (EventDispatcher??) and how would it or the main view trigger the creation and wiring of the meditator?
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by Ondina D.F. on 18 Aug, 2014 01:42 PM
Hi Chris,
In my opinion Consumers and Producers belong to the Service layer, not to a View.
You could wrap your Consumer in a Service class, that has an IEventDispatcher injected into it.
Anyway, if you want to have your Consumer inside a View, you can do the following:
Inside your View (SomeView), instead of having the Consumer within a Declaration tag, you create an injection point for a class extending Consumer (SomeConsumer), like this:
You inject the shared event dispatcher into SomeConsumer:
You can send and/or listen for context events through the shared eventDispatcher. Beware of the fact that you won't have access to the eventDispatcher in SomeConsumer's constructor.
In your config:
This way SomeConsumer will be injected into SomeView, where you can access SomeConsumer methods.
SomeConsumer can communicate with SomeMediator or other framework-actors through the shared eventDispatcher. No need for a "mediator".
Hope that helps.
Ondina
2 Posted by Chris on 21 Aug, 2014 01:13 AM
In the last paragraph, what do you mean by No need for a "mediator"? Because it sounds like you are suggesting I create a mediator for each consumer?
Also, I don't understand your config:-
What is being injected into the view, every singleton?Does the injector.map(Class).asSingleton() create the instance of Class without the need to explicitly inject it into something? I ask this because in thinking about your suggestion to use a service. If the consumer class was automatically instantiated, it would set itself up, connect to the server and wait for a message. And the config would specify the command to map the event the consumer would dispatch. Then I wouldn't have to write any code outside of defining the consumer class and the message processing command and the configuration mapping. Is this possible?
Support Staff 3 Posted by Ondina D.F. on 21 Aug, 2014 10:22 AM
No, no. I wasn't suggesting to create a Mediator for any Consumer. SomeMediator, in my example, is mediating SomeView, not SomeConsumer! SomeConsumer is a standalone class with an injected shared event dispatcher. You can inject it anywhere you want, or instantiate it as explained further down in this post. With "No need for a Mediator" I meant to say, that SomeConsumer was able to communicate with other classes by itself through the shared event dispatcher. As I said, Consumers and Producers shouldn't be part of a View anyway. I just gave you a solution for using them in a View, because you asked ;)
If you needed different Consumers, each Consumer would have to be mapped separately.
This mapping:
would give you the same instance of SomeConsumer every time you ask for one, i.e. every time you create an injection point like this, in one or several classes:
The ViewProcessorMap creates a rule for the Injector:
Because of this rule, when SomeView is added to the stage, the Injector inspects it and resolves its dependencies, defined as injection points ([Inject] metadata tags), in our case SomeConsumer.
Here is more about viewProcessorMap:
https://github.com/robotlegs/robotlegs-framework/tree/master/src/ro...
Until recently, a mapping alone wasn't enough to create an instance of the class.
The Injector has been instantiating classes only on request (where [Inject] is the request ). Or if you explicitly asked it to do so:
The latest changes to Swiftsuspenders make it possible to determine when the instance should be created. Take a look at asSingleton method in InjectionMapping:
https://github.com/robotlegs/swiftsuspenders/blob/master/src/org/sw...
Summarizing:
It is a very good decision to use a service!!
Yes, that's the way to go. I would suggest to use interfaces for your Service classes.
Chris closed this discussion on 01 Sep, 2014 03:21 AM.