Actor, IActor, Event Dispatcher.

Rasheed Abdul-Aziz's Avatar

Rasheed Abdul-Aziz

08 Nov, 2009 08:00 PM

I expect there to be an IActor with an interface for the eventDispatcher getter/setter.

Resoning:

When I test any ISomeService i need to test it for async responses.

ISomeService currently adds the interface for eventDispatcher.

ConcreteService is always an Actor

ISomeService would always be an IActor.

I'm happy to be told why this might be a bad idea.

  1. Support Staff 1 Posted by Shaun Smith on 10 Nov, 2009 12:21 AM

    Shaun Smith's Avatar

    There is no IActor interface because the abstract Actor doesn't guarantee any kind of API. Extending Actor just provides some handy dependencies internally, it is up to your concrete class to implement the interfaces appropriate for it's API.

    You'll notice that Actors have dispatchers, they aren't dispatchers themselves. If you want a common interface for all your actors that provides access to their EventDispatchers, you could make an interface called: IEventDispatcherProvider that declares a method like getEventDispatcher().

    Does that help clear things up? Or have I misunderstood your question?

  2. 2 Posted by Rasheed Abdul-A... on 10 Nov, 2009 03:46 AM

    Rasheed Abdul-Aziz's Avatar

    I do realise that Actors have dispatchers. And I think I see your
    suggestion, but let me work this through more clearly with a hypothetical:

    IMyService has one method loadThings.

    ConcreteServiceA implements this method, and by way of convention (because
    we can't add events to our interfaces) it issues forth and event
    ServiceEvent.LOADED through the dispatcher. "dispatcher" comes free by
    extending 'Actor'

    ConcreteServiceB does exactly the same thing (implementation details
    differing of course)

    In the RL/MVCS implementation, the presence of the 'dispatcher' is
    immaterial, I just call Actor.dispatch by way of inheritance.

    However when I go to test my services, I should be able to use the same Unit
    Tests and Flex Unit 'Theories' on either concrete implementation via it's
    interface. In fact i'm testing all concretions of IMyService. The only
    shortfall is, I can't strictly infer that the IMyService implementation i'm
    testing has a 'dispatcher' which i need to listen to for
    ServiceEvent.LOADED.

    I first thought, no bother, I'll create an IDispatcher and add a
    getter/setter interface for dispatcher:
    function get dispatcher():IEventDispatcher;
    function set dispatcher(value:IEventDispatcher):void;

    I had my IMyService implement this interface, but it failed to compile,
    because in Actor, dispatcher is a field and not a property.

    If in Actor, dispatcher were a property, then I'd have no issue with the
    statement: "Extending Actor just provides some handy dependencies
    internally, it is up to your concrete class to implement the interfaces
    appropriate for it's API"

    These 'handy internal dependencies" _are_ the mechanism for my service to
    broadcast events. Or am I missing something?

    On Tue, Nov 10, 2009 at 1:21 PM, Shaun Smith <
    [email blocked]<tender%[email blocked]>
    > wrote:

  3. 3 Posted by Rasheed Abdul-A... on 10 Nov, 2009 03:53 AM

    Rasheed Abdul-Aziz's Avatar

    FYI, I have patched Actor to get the behaviour I want. I didn't create an
    IActor because of some discussions I found after my first post, so instead
    decided to make it possible to wrap Actor's handy addition of the shared
    internal plumbing into Interfaces of concrete actors:

    Index: src/org/robotlegs/mvcs/Actor.as
    ===================================================================
    --- src/org/robotlegs/mvcs/Actor.as (revision 12805)
    +++ src/org/robotlegs/mvcs/Actor.as (working copy)
    @@ -34,7 +34,15 @@
      public class Actor
      {
      [Inject]
    - public var eventDispatcher:IEventDispatcher;
    + public function get eventDispatcher():IEventDispatcher {
    + return _eventDispatcher;
    + }
    +
    + public function set eventDispatcher(value:IEventDispatcher):void {
    + _eventDispatcher = value;
    + }
    +
    + private var _eventDispatcher:IEventDispatcher;

      protected var _eventMap:IEventMap;

    ===================================================================

    On Tue, Nov 10, 2009 at 4:46 PM, Rasheed Abdul-Aziz <
    [email blocked]<tender%[email blocked]>
    > wrote:

  4. Support Staff 4 Posted by Joel Hooks on 10 Nov, 2009 04:01 AM

    Joel Hooks's Avatar

    You can completely replace actor with some implementation that fits
    your use-case. no need to be limited by the classes that are there.
    Make a concrete Service and IService for your app.

  5. 5 Posted by Rasheed Abdul-A... on 10 Nov, 2009 04:56 AM

    Rasheed Abdul-Aziz's Avatar

    I do appreciate that perspetive. Lock in can suck, but I am also
    trying, at least in the early stages, to follow the conventions and
    best practices closely.

  6. Support Staff 6 Posted by Shaun Smith on 11 Nov, 2009 01:26 PM

    Shaun Smith's Avatar

    Aha! At first I wasn't really following what you were trying to achieve. I think I get it now. Interesting. The fact that Actor has a public property for the eventDispatcher makes it difficult to test Actor for events by Interface (golly, I'm not doing a great job at explaining it either!).

  7. 7 Posted by Rasheed Abdul-A... on 11 Nov, 2009 07:42 PM

    Rasheed Abdul-Aziz's Avatar

    No that sounds about right. and is eloquent. I'm glad I'm making some sense
    too, I started to feel like "the guy who just didnt get it"

    Yes, the MVCS reference implementation keeps testability in mind, and I do
    in fact end up with testable Concrete services through the concrete
    service's API. However achieving the same thing with the Service's Interface
    is stumped by the use of the framework pipeline dispatcher for "results".

    On Thu, Nov 12, 2009 at 2:26 AM, Shaun Smith <
    [email blocked]<tender%[email blocked]>
    > wrote:

  8. Support Staff 8 Posted by Shaun Smith on 07 Dec, 2009 02:25 PM

    Shaun Smith's Avatar

    Hi Rasheed,

    Just a quick follow-up:

    In the v1.0 release, Actor now has a getter/setter for eventDispatcher. We don't have an IActor interface, but you can at least declare the eventDispatcher getter in your own interface for the purposes of testing. Hopefully this solves your issue?

  9. Support Staff 9 Posted by Shaun Smith on 07 Dec, 2009 03:02 PM

    Shaun Smith's Avatar

    I'm going to mark this issue as Resolved, but if you feel it hasn't been properly addressed, please feel free to re-open it.

  10. Shaun Smith closed this discussion on 07 Dec, 2009 03:02 PM.

  11. Rasheed Abdul-Aziz re-opened this discussion on 07 Dec, 2009 06:42 PM

  12. 10 Posted by Rasheed Abdul-A... on 07 Dec, 2009 06:42 PM

    Rasheed Abdul-Aziz's Avatar

    That sounds like it will resolve it without any trouble.

  13. Shaun Smith closed this discussion on 11 Dec, 2009 02:53 PM.

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