Update on 8/16/10: With the release of Swiz RC1, I released an updated version of this example application.

With the release of the 1.0 Beta of the Swiz framework, I've updated my Swiz example application to the latest version. You can also view the source code if you like. I'd like to point out a few things that I had to change from the example based on version 0.6.4:

  • The instantiation of the framework has changed in order to support multiple instances of Swiz, primarily for Flex module support:
    <swiz:SwizConfig id="mySwizConfig"
                     eventPackages="com.briankotek.swizdemo.event"
                     viewPackages="com.briankotek.swizdemo.view"
                     defaultFaultHandler="{genericFault}" />
    
    <swiz:Swiz id="mySwiz" beanProviders="{[Beans]}" config="{mySwizConfig}" />
    		
  • The static methods on the Swiz class have been removed, due to the fact that there can now be multiple instances of Swiz. This means that instead of doing something like Swiz.dispatchEvent( event ), you now want to inject a dispatcher object into your non-view objects and dispatch events through it instead. The two main ways to do this are to inject the dispatcher in your BeanLoader/BeanProvider, or by having your class implement the IDispatcherAware interface, which will instruct Swiz to inject the dispatcher automatically.
  • The [Autowire] metadata tag has been deprecated in favor of the more industry-standard [Inject]. [Autowire] will still work for now, but be aware that this may be removed in a future release.
  • The use of the earlier CommandChain has changed to support more robust and extensible chains, as well as supporting internal Flex event-based chains on top of the existing support for chains that make server calls. For example:
    var chain : CommandChain = new CommandChain();<br>
    chain.addMember( new AsyncChainStepCommand( delegate.deleteUser, [user], userDeleteHandler ) );<br>
    chain.addMember( new AsyncChainStepCommand( delegate.deleteUserProfileImage, [user], userProfileImageDeleteHandler ) );<br>
    chain.addEventListener( "chainComplete", userDeleteCompleteHandler, false, 0, true );<br>
    chain.start();
    		
Anyway, that's all for now, but I'll be posting more about the Swiz updates soon. If you're interested in seeing more about 1.0, have a look at Sam Ahn's demo of Swiz using AS3Signals. A very cool use of the brand new custom metadata support now available in Swiz!

Comments Comments (25) | del.ico.us del.icio.us | Digg It! Digg It! | Linking Blogs Linking Blogs | 10579 Views

Comments

  • # Posted By Raymond Camden | 3/5/10 10:08 AM

    For the most part, this makes sense, but I'm not quite getting bullet point #2. Can you call out how you've done that in your example app, or perhaps provide a link with more details?

    Got to say - on a first (quick, not fair, etc) look - it seems like Swiz is getting much more complex than it used to be.

  • # Posted By Brian Kotek | 3/5/10 10:52 AM

    Ray, it just means that in my code, rather than doing Swiz.dispatchEvent(), I'm doing dispatcher.dispatchEvent(). The static methods HAD to be removed, because now that an application can have more than one instance of Swiz (in modules, separate AIR windows, etc.), it would be impossible to call a static method and have Swiz know which context should handle the event. So this change was not only necessary, but is much better from a design perspective. It means you don't have code that is coupled to Swiz any longer.

    Other than this change, the rest of Swiz works pretty much as it always did. I didn't have to modify much to adjust to the 1.0 changes. It really hasn't gotten any more complex. Is there some specific thing that is bothering you regarding the changes?

  • # Posted By Raymond Camden | 3/5/10 10:56 AM

    Thanks Brian - I see the dispatcher now.

    Ignore my second comment - I think your example was just a bit much for me right now. ;) Any idea when the documentation will be complex for 1.0?

  • # Posted By Brian Kotek | 3/5/10 11:03 AM

    Glad it makes sense. Regarding docs, we'll be working on it as we build towards the 1.0 final release!

    Also just a quick note, for some reason, Flash Builder added some odd bits to the source code when I exported the project. For example, I see [Inject("true" )] in some places. No idea why it did that but the "true" is unnecessary and doesn't mean anything. It should just be [Inject]. Sorry for that, I'll yell at Flash Builder today.

  • # Posted By Swiz noob | 3/5/10 11:08 AM

    I think you guys have done a great job on this but I am looking forward to some documentation for those of us who are not already expert flex programmers. When you say "you now want to inject a dispatcher object into your non-view objects" I don't know how to do that. Can you update your example to show how?

    Thanks

  • # Posted By Raymond Camden | 3/5/10 11:13 AM

    I'd like to ditto Swiz noob. To me, Flex suffers from the 'what to do past Hello World' syndrome. By that I mean Flex is INCREDIBLY easy when you are starting out. But once your apps begin to grow and get a bit more complex, it becomes a bit harder (for some, obviously, not all) to understand how best to handle communication/navigation/etc between multiple parts of the application. I think Swiz could go a LONG way to helping _those_ Flex developers, especially those who may not have a strong background in OO.

    I'd like to see simple demos that focus on those problems and come from the perspective of the less experienced developer.

    Joe's video (http://www.firemoss.com/index.cfm/2009/10/21/Swiz-...) I think does a damn good job of this.

  • # Posted By Brian Kotek | 3/5/10 11:19 AM

    Sure guys, you can see it in the UserController (which extends AbstractController), where I am getting an instance of the dispatcher injected because AbstractController implements IDispatcherAware. When Swiz sees a bean that implements this interface, it injects the proper dispatcher automatically.

    You can also see this in the UserPresentationModel. If you look at the Beans.mxml, you can see I'm passing a reference to the dispatcher into this object.

    I guess since I've been using Flex for a while, I'm used to this sort of thing. It really isn't complex at all, but I can understand that to a newcomer, some of this will take a bit of time to understand. That said, understanding how Flex interfaces work and understanding how to pass and bind properties to components that you instantiate is a fundamental element of programming in Flex (and AIR), so it's something that is best tackled early in your learning. I hope that helps?

  • # Posted By jeremy | 3/5/10 11:25 AM

    I've been multi-tasking too much and see that there are already responses. I'll post this anyway. @Ray -- Quite the opposite... Swiz, to me, is getting less complicated. With the removal of the public static swiz instance, swiz is easier to garbage collect (with a couple more functions added to core.swiz) at a 'child-view' level (memory management was a huge issue we had 3 years ago when this project started -- rolling 20 years of code into a new front-end).

    To answer your question re: the 2nd bullet point. What Brian is saying is you can use the [Inject] metadata tag to inject the instance of the dispatcher of the 'document' (parent) -- the document/parent of the swiz instance (most all are using the imxmlObject).
    OR, have your not-on-the-display-list class implement IDispatcherAware, and it will get an instance of that parent dispatcher after swiz init() is called and the beanFactory runs handleSwizInterfaces(). Certainly there are another 1/2 dozen other ways to get access to the dispatcher, but these two are the quickest and easiest.

    In any case, as of this week, our company is actually using swiz... it's much better, cleaner, and follows OO-happiness than Ben's first attempt at an open-source flex library project (flexmdi). Bravo say-eth me and my coffee that hasn't yet kicked in.

  • # Posted By Raymond Camden | 3/5/10 11:32 AM

    @jeremy - to be clear, I hope it didn't sound like I was putting down Swiz. It's just been a while since I used it, so it's going to be a learning experience for me. Unfortunately, some learning is more painful than others. ;)

  • # Posted By John Gag | 3/5/10 12:43 PM

    I cant wait to dive in and play with it. I am almost done with a project using a previous Swiz build but I am def going to look at the newer build with my next project. Thanks guys!

  • # Posted By Otto | 3/11/10 12:00 PM

    Hi Brian,

    1.0 looks sweet. Unfortunately I can't get the sample going, I the following error: http://pastebin.org/109924

    Did I miss something?

  • # Posted By Otto | 3/11/10 12:01 PM

    I forgot to write that I'm running the v1.0.0-beta-patched-externalSDK version.

  • # Posted By Brian Kotek | 3/11/10 1:45 PM

    Hi Otto, out of curiosity, is this Flex 3.5 or Flex 4?

    The problem is probably caused by a bug in either the Flex 3.5 SDK or targeting Flash 9, where a setter and a getter cannot have different access modifiers. Chris had added a package-level getter for the dispatcher property in the AbstractController, and since the setter is public but the getter is package, it triggers this error.

    This has been fixed in the source to account for the bug. I will also update my example. So if you like you can either build from the Swiz source using the updated compiler args to keep the metadata:

    -keep-as3-metadata+=Inject,Autowire,Outject,Mediate,Dispatcher,PostConstruct -namespace http://swiz.swizframework.org manifest.xml -include-namespaces http://swiz.swizframework.org

    Or a new build should be coming shortly. Thanks, and sorry for the confusion (darn Flash bug!)

  • # Posted By Brian Kotek | 3/11/10 2:38 PM

    I've updated the example to work with the latest source from Git. If you won't/can't build from the source, an updated beta version will be released shortly. Thanks!

  • # Posted By Otto | 3/11/10 3:44 PM

    I'm using Flex 3.5. I'll wait for a new beta, thanks for the quick reply.

  • # Posted By ToddK | 3/11/10 6:57 PM

    I'm missing something. I downloaded your source code, loaded it up in FlexBuilder 3.

    I changed the Required Flash Player version to 10.0.0 because without it I got the error:
    1046: Type was not found or was not a compile-time constant: Matrix3D.

    I have one error (three instances) left that I cannot get rid of:
    1120: Access of undefined property dispatcher.
    UserController.as Line 80 (line 92, line 97)

    I'm using Flex 3.2 SDK, and am still in my noob stage of developement.

    Any ideas?

  • # Posted By ToddK | 3/11/10 7:03 PM

    Crud, I forgot to mention I just downloaded swiz-v1.0.0-beta.swc

    I also tried adding swiz-v1.0.0-beta-patched.swc and swiz-v1.0.0-beta-patched-externalSDK.swc (first one at a time then both together) and still had no luck.

  • # Posted By Brian Kotek | 3/11/10 7:04 PM

    Hi Todd, yes, the issue with the dispatcher is the same issue I was talking about above. The source code in Git has been updated to deal with this known bug in the 3.x SDK, and an updated version of the .swc will be released shortly. If you're familiar with building Flex library projects you can build the framework from the source code in Git, but if not your best bet is to wait for the next beta release (which will be very soon).

  • # Posted By Brian Kotek | 3/11/10 7:10 PM

    This is a good overview of how to build Swiz from the source code: http://www.eonflex.com/?p=352

  • # Posted By Robert Boyd | 4/3/10 7:18 PM

    Thanks for this. It has really helped me, and others I'm sure. I managed to build Swiz framework from source in Flex Builder using the instructions in the link from your comment above (eonflex). I first upgraded to Flex SDK 4.

    After paying special attention to setting the namespace and the manifest, the library project built fine and all that was left was to search/replace MockDelegateUtil => MockDelegateHelper as this class was renamed in commit 89fbdcbb9dae40c7675aaeb2a0ca12f8bf46e153 on 3/31.

  • # Posted By Julien | 4/19/10 9:30 PM

    In addition to renaming the MockDelegateUtil => MockDelegateHelper, I had to rename AsyncChainStepCommand => AsyncCommandChainStep in UserController.as.

    I hope this helps.

  • # Posted By Philip Bedi | 6/4/10 8:02 AM

    Hi Brian,

    I am getting following error:

    Severity and Description   Path   Resource   Location   Creation Time   Id
    1067: Implicit coercion of a value of type org.swizframework.utils.logging:SwizLogger to an unrelated type mx.logging:ILogger.   ManagerApp/src   ManagerApp.mxml   line 32   1275656473960   62545

  • # Posted By Brian | 6/4/10 9:45 AM

    Sounds like you're running the 1.0 RC version with this example, which was built on the 1.0 beta. Have a look at the updated version of the app at http://www.briankotek.com/blog/index.cfm/2010/5/19...

  • # Posted By Philip Bedi | 6/4/10 10:29 AM

    Thanks Brian,

    I will give it a try tonight.

    Regards

    Philip

  • # Posted By Mike Haggerty | 10/11/10 11:00 AM

    @raymond -- in regards to the 'Swiz in 20 minutes' video you posted above, that URL is now dead. The video is on Vimeo, though.

    http://vimeo.com/7166397