Announcement Announcement Module
No announcement yet.
event system Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • event system

    is there any plan to include some kind of event system in SAS?
    I'd love to be able to use metadata to add listeners.

    i like the simplicity of the Swiz approach for ex. They use a tag [Mediate=eventName] to add listeners to a global eventdispatcher (bound to the Stage). You then just bubble your events. (Problem being that Swiz targets flex-only projects).
    Is there anything similar in SAS? (existing or planned)

  • #2

    Looking at Swiz they have have done many things right.

    Still loving the unmatched power of the SAS IoC container though and it will be my choice
    for the next project.

    But here another suggestion for the future roadmap:
    Swiz uses mxml for the container which has 2 big advantages:
    - editor support (code completion / error checking etc)
    - no hassle with including classes by hand
    The drawbacks:
    - no config changes without recompiling
    - flex only.

    But investigating more frameworks i stumbled upon Parsley which gives you the choice. Both are supported. That is pretty flexible and suits different needs.

    My question is how hard would it be to add this? For pure actionscript you would still use xml, but for flex you can choose (or even mix...) I know you guys are working really hard so i don't want to sound like a lazy bastard just requesting features.

    Just my 2 cents,



    • #3
      just to clarify my question: please keep the flash AND flex route. This is what got me to this framework. I m sick of having to change my flow on every new project.

      My question was more: i'm sure that everybody who use SAS has to choose a way to work with events so why not provide a general (non-intrusive) way to handle them?


      • #4
        Hi guys,

        thanks for your valuable feedback. Here are some answers:

        - we currently do not have support for Mediate metadata. We do have a global/application level event system in the "mvcs" package. Please see the SVN version for more info and don't hesitate to ask any questions about this. The mvcs package is meant to be(come) a set of base classes for architecting your application. I wouldn't necessarily call it a framework on it's own, but it will certainly provide you a guideline.

        - implementing MXML configuration might be quite easy actually. I haven't tried it, but it doesn't seem impossible to fit into the framework. I'm thinking of a MXMLApplicationContext. If anyone has time to experiment with this, I'd be happy to hear about the results.



        • #5
          thanks Christophe.
          i had a look at the ApplicationEvent class (and surroundings..)
          Is there any integration possible with the rest of SAS?
          Or do you just use it as a "normal" eventdispatcher?
          am i right in thinking that each view would need a reference to the global dispatcher in order to dispatch an event?


          • #6
            There is currently no extra support/integration with SAS since we don't want to couple these base classes to much to the core container. However, it is perfectly possible to integrate parts of the mvcs package in the container.

            The views don't really need a direct reference to the central dispatcher. The ApplicationEvent has a dispatch method that will globally dispatch the event vs. the dispatch event of the display list that will bubble the event. So you can choose how you deal with application events. (globally or locally)


            • #7
              ok thanks.

              i think what i'd like to do is:
              - have a global dispatcher bound to the stage
              - use a metadata ("Mediate" or something else) to register listeners to this dispatcher
              - use some kind of magic so that any added view is automaticaly scanned for this metadata (so that you don't have to reference any single ui element/view in the xml context).

              so that from the views you can just dispatch usual events, which would bubble down to global dispatcher (no coupling), or from a non-visual element you just use a ref to the global dispatcher to dispatch events.

              (best would be to be able to define multiple dispatchers each bound to a "floor" element so that you could create mini-mvcs and intercept some bubbling events).

              a kind of mix between SAS, Swiz and Mate

              point 1 should be quite easy, for point 2 i ll have a look at the Autowire configuration to see if i understand something... and if someone has any idea for point 3 i'd be glad to hear them



              • #8
                Injecting mxml components into Spring beans.

                One thing I really like about the Swiz framework is the "view autowiring" feature.

                A Swiz bean may have a method with "[autowire(view='true')]" annotation. When Swiz is initialized, it sets up a listener for objects added to the stage, and if those objects matches the rules for view autowiring, then the annotated method is called, allowing the object to be "injected" with a view component.

                What I like is that Swiz allows for view components to be injected into beans. To me, this makes it easy to move code that needs to coordinate multiple view components out of mxml, into an ActionScript class.

                Reading the Reference Documentation, I don't see a way to inject a bean with view components.

                What's the thought on this? Could it be something useful?


                • #9
                  its in v0.8

                  The technique you mention is part of the upcoming version 0.8 release:


                  The current online documentation isn't complete either, it'll be updated when 0.8 is released officially.




                  • #10
                    I might be missing something here (or just misinterpreting jlcheng's post), but I think this request is for autowiring ActionScript objects with view components. As far as I know, we only support the other way around (inject object into view, not view into object).


                    • #11
                      Originally posted by cherreman View Post
                      I might be missing something here (or just misinterpreting jlcheng's post), but I think this request is for autowiring ActionScript objects with view components. As far as I know, we only support the other way around (inject object into view, not view into object).
                      Hi Christophe,

                      Wiring ActionScript objects with view components is exactly what I mean. What is your take on this functionality? Would it be something Spring ActionScript would be interested in adding? Would it fit within the design of Spring ActionScript?


                      • #12
                        oops, misread...


                        yea, now that I re-read the post I guess I misunderstood. Yet, implementing this doesn't seem to be awfully complicated. We already have the stage listener in the applicationcontext wiring the view components, I see no direct complications in injecting those instances into any of the object defined in the configuration.


                        • #13
                          new stage interception

                          Alright, I think I've managed to whip something up to will do exactly what you mention. (At least I think so hehe)

                          I just committed a new IObjectPostProcessor called StageComponentInterceptionPostProcessor, this postprocessor can evaluate components and objects based on the approval of a separate IObjectSelector and when approved inject the specified component into another object.

                          I've also added a namespace handler for it so you can use some shorthand markup like this:

                          <si:stageinterceptor target-object="stageRegistry" target-method="register"
                                               object-selector="registrySelector" id="stageInterceptor"/>
                          Source and documentation have been committed, if anyone would like to try it out, please feel free to do so and give some comments.