Announcement Announcement Module
Collapse
No announcement yet.
How does the SAS 2.0 event handling config work? How to enable metadata config? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How does the SAS 2.0 event handling config work? How to enable metadata config?

    Hi all,

    I'm trying to switch my project from SAS 1.0 to 2.0, but I'm having a little bit of troubles with the (Static)EventBus handling.

    The problem is that in my Mxml config, the event handler config doesn't seem to work (maybe I'm missing a key part in the configuration) as I thought it would:

    PHP Code:
    <eventbus:EventHandler instance="serviceLayer">
        <
    eventbus:EventHandlerMethod name="findAllHandler" eventName="{AppEvent.FIND_ALL}"/>
    </
    eventbus:EventHandler>

    <!--
    Service-->
    <
    sas:Object id="serviceLayer" clazz="{ServiceLayer}">
        <
    sas:ConstructorArg ref="dBService"/>
    </
    sas:Object>
    <
    sas:Object id="dBService" clazz="{DBService}">
        <
    sas:ConstructorArg ref="serverRemoteObject"/>
    </
    sas:Object
    With this configuration my "findAllHandler" doesn't get triggered.
    Though when I add the listener manually in my configuration it does seem to work:
    PHP Code:
    StaticEventBus.addEventListener(AppEvent.FIND_ALLfindAllHandler); 
    Also I can't seem to get the metadata config working (I do have my MXML config working in the project, maybe I also need to add something in there to activate metadata config options?):

    PHP Code:
    [EventHandler]
    public function 
    findAllHandler(event:AppEvent):void {
        
    log.debug("Received findAll event from EventBus: {0}", [event]);
    ... 
    This used to work in my previous SAS 1.0 config, but doens't get picked up atm...

    Thanks a whole lot in advance!

    Best wishes,

    Jochen

    PS: I also tried this kind of config, without succes:

    PHP Code:
    <!--Service-->
    <
    sas:Object id="serviceLayer" clazz="{ServiceLayer}">
        <
    sas:EventHandlerMethod name="findAllHandler" eventName="{AppEvent.FIND_ALL}"/>
        <
    sas:ConstructorArg ref="dBService"/>
    </
    sas:Object
    PPS: Using the EventRouterConfiguration on the dispatching side makes the previous EventHandlerMethod in the config block work:

    PHP Code:
    <sas:Object id="ebHelper" clazz="{EbHelper}">
        <
    sas:EventRouterConfiguration eventNames="{AppEvent.FIND_ALL}"/>  
    </
    sas:Object
    But only the events dispatched by the instance (as opposed to my static dispatching methods defined who dispatch on the static eventbus) get caught:

    PHP Code:
        //
    public function findAll(className:StringprocessString:String=nullcomplete:Function=nullerror:Function=nullretry:Function=null, ...retryparams):void{
        ...
        
    dispatchEvent(new AppEvent(AppEvent.FIND_ALL, [classNameprocessStringcompleteWrappederrorWrapped]));
    }
            
    public static function 
    findBy(classNameToFind:String,  instanceClassNamesToMatch:*, processString:String=null
                                          
    complete:Function=nullerror:Function=null
                                          
    retry:Function=null, ...retryparams):void{            
        
    StaticEventBus.dispatchEvent(event);

    Is this normal behavoir? Is the use of the static eventbus discouraged as opposed to routing "normal" events?
    Last edited by Dr.Drane; Sep 17th, 2012, 10:34 AM.

  • #2
    FYI: Scoping my service layer to remote breaks the EventHandlerMethod functionality:
    PHP Code:
    <!--Service-->
    <
    sas:Object id="serviceLayer" clazz="{ServiceLayer}" scope="remote">
        <
    sas:EventHandlerMethod name="findAllHandler" eventName="{AppEvent.FIND_ALL}"/>
        <
    sas:ConstructorArg ref="dBService"/>
    </
    sas:Object

    Comment


    • #3
      Hi Jochen,

      you are correct in your assumptions The <EventHandlerMethod> and <EventRouterConfiguration> need to be used together. A Spring Context actually has an eventbus instance of its own (so its not using the StaticEventBus), these configurations will make sure that the listeners and dispatchers are using the SAME eventbus instance.
      So, in your first attempt your handler method was listening to context's eventbus, while your event was dispatched through the static eventbus.

      If you still want to be able to use the StaticEventBus then simply add the context's eventbus as a listener to it:

      Code:
      StaticEventBus.addListener(applicationContext.eventBus);
      That way all events sent through the static eventbus get routed through the context's eventbus as well.

      The reason why the context has its own eventbus is modularity. This gives the flexibility to load, for instance, two modules, each of whom have their own eventbus, and have them send and listen to events on their own eventbus without the danger of picking up on eachother's events. So, in general, I tend to discourage the use of the static eventbus for these reasons.
      Its still possible to let them communicate by adding eachother as listeners to each context's eventbus. When adding a context as a child context it is possible to have quite some fine grained control over how the eventbuses will be coupled. You can read more about this over here:

      http://www.springactionscript.org/do...ntext-children

      I hope that clarifies some things,

      please let me know if you have any more questions,

      Roland

      P.S. One more advantage for using the MXML config for eventbus stuff instead of the static eventbus is that the container keeps track of all of those eventbus listeners and dispatchers and cleans everything up neatly when the object gets destroyed. (In case of view components when its removed from the stage, in case of 'normal' instances when they are passed to the applicationContext.destroyObject() method).

      Comment


      • #4
        Hi there again,

        about the remote scope, are you sure about this? Do keep in mind that when an object is scoped to 'remote' the container does NOT instantiate it. Instead, you are responsible for instantiating it manually and then passing the instance to the applicationContext.manage() method, along with the correct name of the object definition that is associated with this class.

        In general I don't think you'd need to scope your services to 'remote' to be honest. Or please explain your use-case a bit further.

        cheers,

        Roland

        Comment


        • #5
          Addendum,

          I see I haven't updated the documation properly concerning the different scopes, I'll try to do that a.s.a.p.
          Sorry for the confusion

          Roland

          Comment


          • #6
            Hi Roland, thanks a lot for clearing this out!

            The event handling now seems to be working as I understand it should. w000p w000p

            Originally posted by 666shooter View Post
            Hi there again,

            about the remote scope, are you sure about this? Do keep in mind that when an object is scoped to 'remote' the container does NOT instantiate it. Instead, you are responsible for instantiating it manually and then passing the instance to the applicationContext.manage() method, along with the correct name of the object definition that is associated with this class.

            In general I don't think you'd need to scope your services to 'remote' to be honest. Or please explain your use-case a bit further.

            cheers,

            Roland
            I'm sorry, I misunderstood the 'remote' scope concept altogether.
            Re-reading your blog post made this clear.

            Do have some other module related questions, but will post them in a seperate thread.

            Comment


            • #7
              I think it is
              StaticEventBus.addListener(applicationContext.even tBus);

              Comment

              Working...
              X