Peanut Butter Thoughts http://pbking.com/blog Thoughts of a Flash Geek Tue, 25 May 2010 18:12:10 +0000 en hourly 1 http://wordpress.org/?v=3.0 Grails Post Complete http://feedproxy.google.com/~r/ThePeanutButterThoughts/~3/M7fuZbi-3Kg/ http://pbking.com/blog/?p=260#comments Tue, 25 May 2010 18:12:10 +0000 Jason Crist http://pbking.com/blog/?p=260 I started to do a bunch of writing about Grails and Blaze and the like. Then life got in the way. I had a lot planned but I just had too much work going on to complete the posts. I’m sorry that I left any of you hanging.

Fortunately somebody else has realized the awesome power the stack has and has started writing a great series on it.

If you are still interested in the Grails/Blaze/Flex stack then I highly reccomend you check out Sébastien Arbogast’s posts:
Part 1
Part 2

]]> http://pbking.com/blog/?feed=rss2&p=260 0 http://pbking.com/blog/?p=260 The Blazing Grail – Part 3 http://feedproxy.google.com/~r/ThePeanutButterThoughts/~3/Nt0siQsWxgE/ http://pbking.com/blog/?p=252#comments Tue, 23 Mar 2010 18:12:26 +0000 Jason Crist http://pbking.com/blog/?p=252 Now that we have a working server it’s time to lock it down! The first thing we need is the ACEGI security plugin (Spring Security). These quick-start tutorials were very helpful to get started.

To install type:

grails install-plugin acegi
. . .
grails create-auth-domains User Role Requestmap
 . . .
grails generate-manager
. . .

Now that it’s installed we need to lock down our services. This is a good place to understand a bit about using security with spring-blaze.

It took me a while to realize that for this you HAVE to code to an Interface. That’s good practice right? For my proof-of-concept I really didn’t care about best practices so there was no interface involved. I finally figured it out though.

So lets create an interface. I guess standard Java way is for the interface to be the “ObjectName” and the implemented version “ObjectNameImpl” or some such. Whatever. You’ll get the idea.

I now have an AmfService.groovy

package com.pbking

interface AmfService {

    String getSomeString();
    String getSomeOtherString();
}

and an AmfServiceImpl.groovy

package com.pbking

class AmfServiceImpl implements AmfService
{
    boolean transactional = true

    String getSomeString()
    {
      return "Peanut Butter is Awesome"
    }
   
    String getSomeOtherString()
    {
      return "Peanut Butter and Banana Sandwiches are the Best!"
    }
}

Wait . . . where did my annotations go?! Well so far I haven’t been able to get security to work with annotations; interfaces or no. Likely it’s just something I’m doing wrong; if you have a working example I would love to see it. But I DID get XML configuration working so that’s what I’m showing here.

The next step is to define the login command in the /project/web-app/WEB-INF/flex/services-config.xml that was created in the previous post. If you copied my XML then it should already be displayed. If you’ve got the XML generated by the blazeds plugin then you need to modify this file so that the security node looks like this:

    <security>
        <login-command class="flex.messaging.security.TomcatLoginCommand" server="Tomcat"/>
    </security>
 

The next change is to the flex-servlet.xml; this is where the bulk of the work is. You’ll have to add a few things:

Add the security namespace to the root node:
xmlns:security="http://www.springframework.org/schema/security"

add the security schema locations:
http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring-security-2.0.4.xsd

entry-point and bean nodes:
    <security:http entry-point-ref="preAuthenticatedEntryPoint"/>
    <bean id="preAuthenticatedEntryPoint"
class="org.springframework.security.ui.preauth.PreAuthenticatedProcessingFilterEntryPoint"/>

some sample users:
    <security:authentication-provider>
        <security:user-service>
            <security:user name="admin" password="admin" authorities="ROLE_USER, ROLE_ADMIN"/>
            <security:user name="user" password="user" authorities="ROLE_USER"/>
        </security:user-service>
    </security:authentication-provider>

enable annotations (in case I figure out how to make it work):
    <security:global-method-security secured-annotations="enabled" jsr250-annotations="enabled"/>

and finally we will mark the message-broker as secured:
  <flex:message-broker>
    <flex:secured/>
  </flex:message-broker>
 

If you want to just lock down the whole AMF channel and be done with it then you can do this:

  <flex:message-broker>
    <flex:secured-channel channel="my-amf" access="ROLE_USER" />
  </flex:message-broker>
 

Lastly I comment out the context nodes and add a bean node to represent the service class. In that node I mark which methods need to be secured:

  <bean id="amfService" class="com.pbking.AmfServiceImpl">
    <flex:remoting-destination/>
    <security:intercept-methods>
      <security:protect method="getSomeString" access="ROLE_ADMIN" />
    </security:intercept-methods>
  </bean>

  <!–
  <context:annotation-config />

  <context:component-scan base-package="com.pbking" />
  –>
 

So with all of these changes my flex-servlet.xml looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:security="http://www.springframework.org/schema/security"
  xmlns:flex="http://www.springframework.org/schema/flex" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:context="http://www.springframework.org/schema/context"
  xsi:schemaLocation="
    http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
    http://www.springframework.org/schema/security
    http://www.springframework.org/schema/security/spring-security-2.0.4.xsd
    http://www.springframework.org/schema/flex
    http://www.springframework.org/schema/flex/spring-flex-1.0.xsd
    http://www.springframework.org/schema/context
    http://www.springframework.org/schema/context/spring-context-3.0.xsd">

  <security:http entry-point-ref="preAuthenticatedEntryPoint"/>

  <bean id="preAuthenticatedEntryPoint"
        class="org.springframework.security.ui.preauth.PreAuthenticatedProcessingFilterEntryPoint"/>
         
  <security:authentication-provider>
      <security:user-service>
          <security:user name="admin" password="admin" authorities="ROLE_USER, ROLE_ADMIN"/>
          <security:user name="user" password="user" authorities="ROLE_USER"/>
      </security:user-service>
  </security:authentication-provider>

  <security:global-method-security secured-annotations="enabled" jsr250-annotations="enabled"/>

  <flex:message-broker>
    <flex:secured/>
  </flex:message-broker>
 
  <bean id="amfService" class="com.pbking.AmfServiceImpl">
    <flex:remoting-destination/>
    <security:intercept-methods>
      <security:protect method="getSomeString" access="ROLE_ADMIN" />
    </security:intercept-methods>
  </bean>

  <!–
  <context:annotation-config />

  <context:component-scan base-package="com.pbking" />
  –>

</beans>
 

And that’s it! Your services are locked down! I’ve updated my super-simple flex app to demonstrate that they are. There is a button to call getSomeString (a secured method) getSomeOtherString (a wide open method) and another to login as admin (so that you can successfully call getSomeString).

That app now looks like this:

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
         xmlns:s="library://ns.adobe.com/flex/spark"
         xmlns:mx="library://ns.adobe.com/flex/halo">
 
  <fx:Declarations>
    <s:RemoteObject id="ro"
            endpoint="http://localhost:8080/blazing-ahead/messagebroker/amf"
            destination="amfService"
            fault="resultLabel.text = event.fault.faultString;"
            result="resultLabel.text = event.result.toString();"/>
  </fx:Declarations>
 
  <s:VGroup>
    <mx:Button label="login" click="ro.channelSet.login(‘admin’, ‘admin’);" />
    <mx:Button label="getSomeString" click="ro.getSomeString();" />
    <mx:Button label="getSomeOtherString" click="ro.getSomeOtherString();" />
    <mx:Label id="resultLabel" />
  </s:VGroup>
   
</s:Application>
 

With that you should be able to fire up your server (grails run-app) and hit it with the Flex app to see the restrictions.

Hope that helps you out!

]]> http://pbking.com/blog/?feed=rss2&p=252 4 http://pbking.com/blog/?p=252 The Blazing Grail – Part 2 http://feedproxy.google.com/~r/ThePeanutButterThoughts/~3/blSemsebXHs/ http://pbking.com/blog/?p=238#comments Tue, 23 Mar 2010 05:07:51 +0000 Jason Crist http://pbking.com/blog/?p=238 Hopefully you read the “into” to this short series.  If not go ahead.  I’ll wait . . .

Ok, so to begin at the beginning, let’s create a new Grails project.  (I’m assuming you’re at least a little familiar with Grails.  If not then read the Quick Start article; that should be enough to get you started.)

grails create-app blazing-ahead

If you’re an Eclipse user (like me) then you can import this project right into Eclipse. The groovy plugin would probably be helpful and I’ve been pointed to the SpringSource Tool Suite (with the Grails extension) as a good tool to use (it’s what I’m currently using).  Notepad2 is working pretty well for me right now too though.

From here you could either use Sébastien’s plugin which will install a nightly snapshot of BlazeDS4 and Spring-Blaze.

grails install-plugin blazeds


This is what I suggest doing. If you do you can skip the next little bit where I explain how to do it by hand.

If you’re familiar with setting up these libraries then this is probably redundant. I wasn’t (I’m not a server guy remember) so I had to figure it out on my own. (This is a good read to help you along). Keep in mind that everything that follows can be accomplished by typing the above command (except you can’t pick the version of the libs that you use) so the only reason I would say to do it is to know what happens behind the scenes or to use Blaze 3 instead of 4.

First you’ve got to get the BlazeDS jars and drop them in your /project/libs folder. I just downloaded the latest binary distro, unzipped the .war and grabbed all of the included JARs and dropped them in.

Then I grabbed the latest release of spring-flex and likewise unpackaged it and dropped the included .jar in my libs folder.

Next you have to modify the web.xml file to get things setup. But wait . . . there isn’t a web.xml file anywhere! What to do . . .

grails install-templates

That will create a /templates folder in your /project/src folder. Inside of that you’ll find /war/web.xml which you can edit. Grails takes this file and modifies it to create the web.xml file that actually get’s deployed.

To that you will need to add:

…
<listener>
  <listener-class>flex.messaging.HttpFlexSession</listener-class>
</listener>
…
<servlet>
  <servlet-name>flex</servlet-name>
  <display-name>Spring-Flex Dispatcher Servlet</display-name>
  <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
  <load-on-startup>1</load-on-startup>
</servlet>
…
<servlet-mapping>
  <servlet-name>flex</servlet-name>
  <url-pattern>/messagebroker/*</url-pattern>
</servlet-mapping>
…
 

Next, to your project/web-app/WEB-INF/ folder add a flex-servlet.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:flex="http://www.springframework.org/schema/flex"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:context="http://www.springframework.org/schema/context"
  xsi:schemaLocation="
    http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
    http://www.springframework.org/schema/flex
    http://www.springframework.org/schema/flex/spring-flex-1.0.xsd
    http://www.springframework.org/schema/context
    http://www.springframework.org/schema/context/spring-context-3.0.xsd">

  <flex:message-broker>
    <flex:remoting-service default-channels="my-amf"/>
  </flex:message-broker>
 
  <context:annotation-config />
  <context:component-scan base-package="" />
  
</beans>
 

Lastly create the folder /project/web-app/WEB-INF/flex and drop in a services-config.xml file that looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<services-config>

    <services/>

    <security>
        <login-command class="flex.messaging.security.TomcatLoginCommand" server="Tomcat"/>
    </security>

    <channels>
        <channel-definition id="my-amf" class="mx.messaging.channels.AMFChannel">
            <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf"
                  class="flex.messaging.endpoints.AMFEndpoint"/>
        </channel-definition>
    </channels>

    <logging>
        <target class="flex.messaging.log.ConsoleTarget" level="Info">
            <properties>
                <prefix>[BlazeDS] </prefix>
                <includeDate>false</includeDate>
                <includeTime>false</includeTime>
                <includeLevel>false</includeLevel>
                <includeCategory>false</includeCategory>
            </properties>
            <filters>
                <pattern>Endpoint.*</pattern>
                <pattern>Service.*</pattern>
                <pattern>Configuration</pattern>
            </filters>
        </target>
    </logging>

    <system/>

</services-config>
 

And at this point you should be on par with what the plugin got you.


Now that we’re all together now lets move on . . .

So let’s create a service that can be called.

grails create-service com.pbking.amf

That will create the file /project/grails-app/services/com/pbking/AmfService.groovy Open that file and make it look like this (or some variance):

package com.pbking

import org.springframework.flex.remoting.RemotingDestination;
import org.springframework.flex.remoting.RemotingInclude;

@RemotingDestination
class AmfService {

    boolean transactional = true

    @RemotingInclude
    def getSomeString()
    {
      return "Peanut Butter is Awesome"
    }
}
 

You also have to change the /project/web-app/WEB-INF/flex-servlet.xml file to have this:

<context:component-scan base-package="com.pbking" />
 

If you wanted to use XML configuration instead of annotations you could drop the @stuff in the service, get rid of the two context: nodes and instead do this in the flex-servlet.xml file:

<bean id="amfService" class="com.pbking.AmfService">
   <flex:remoting-destination/>
</bean>
 

And . . . that’s it! Your server is ready to connect to with your Flex client! just type

grails run-app

to get your server fired up. If you are using the plugin and plan to use FlashBuilder 4′s data connection plugin then you’ll have to use

grails run-war

instead. It’s not quite ready for this so I don’t use it yet.

Now you just need a Flex client to do some communicatin’. There are a dozen ways to get this connection made and I’m not about to discuss the pros and cons of each here. I have my favorite and if you ever hire me you’ll find out what that is. ;) But below is about the SIMPLEST Flex4 application that will do the deed.

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
         xmlns:s="library://ns.adobe.com/flex/spark"
         xmlns:mx="library://ns.adobe.com/flex/halo">
 
  <fx:Declarations>
    <s:RemoteObject id="ro"
            endpoint="http://localhost:8080/blazing-ahead-plugin/messagebroker/amf"
            destination="amfService"
            result="resultLabel.text = event.result.toString();"/>
  </fx:Declarations>
 
  <s:VGroup>
    <mx:Button label="call" click="ro.getSomeString();" />
    <mx:Label id="resultLabel" />
  </s:VGroup>
   
</s:Application>
 

And that, my friends, is that. Make go forth and make some kick-ass Grails backends for your Flex applications.

Here are a couple of assets that might save you a bit of typing (or copy-pasting as the case may be).

In the next post I’ll talk about where I spent most of my time . . integrating Spring Security!

]]> http://pbking.com/blog/?feed=rss2&p=238 6 http://pbking.com/blog/?p=238 The Blazing Grail – Part 1 http://feedproxy.google.com/~r/ThePeanutButterThoughts/~3/NxdfZf_tu-Q/ http://pbking.com/blog/?p=233#comments Tue, 23 Mar 2010 03:23:46 +0000 Jason Crist http://pbking.com/blog/?p=233 I’m not a server guy.  I know just enough Java to get into trouble.  I’ve paid bills writing PHP but I’ve never really felt “comfortable” with how things turned out; they worked and the client was happy so I got paid.  But I often have to have things happen “back there”.  I think rich clients are great; it makes sense to me (as a Rich Client Developer) to keep the logic where it happens.  But sometimes that means that that happens up there on the server and I don’t always have a JavaMan handy to take care of it for me.

A short time ago a friend of mine (Ron Haberle) introduced me to Grails.  And for me it sure is the holy grail.  ”Convention over Configuration” makes sense to me (when, that is, I don’t have to BEAT the convention configuration into submission like using Maven with Flex projects).  But for writing the simple server side logic that I’ve got to write, Grails is awesome.

Since what I do is Flash it made sense to me to get Grails setup with some kind of AMF transport.  XML worked for me out of the box but what I really wanted was AMF and some of the other niceties that those technologies offer.  The options I found readily available were the flex plugin (originally introduced to me when I was introduced to Grails) the GraniteDS plugin and Grails Flex Scaffold plugin.

The GraniteDS plugin seemed really great.  It’s just that . . . I don’t use GraniteDS.  I’m sure it’s great technology, it’s just that I have gotten familiar with BlazeDS and until there is something that I can’t do with BlazeDS that I can do with another technology I’m just not eager to spend time learning it.  It seems solid and I tried very hard to get it to work but it just didn’t work out.

And the flex plugin was more of a “look what I can do!” than an actual plugin.  It was also missing an important piece: Spring-Blaze integration.  Since Grails is so Spring-driven it really makes sense to get the Blaze install as “springy” as possible.

The Grails Flex Scaffold plugin was definitely interesting.  But I didn’t like that it (like the others actually) expected that the Flex bits were going to live in the Groovy project.

Eventually I discovered a series of great posts by Sébastien Arbogast that culminated in the creation of his own plugin for BlazeDS4.  That helped me to understand what had to happen to get everything to work together.  It had a fresh (perhaps a bit too fresh?) version of Blaze, Spring-Flex and it was just a step away from nicely integrating Spring Security.  Another thing I liked about his approach was that his Flex project would NOT be a part of the Grails project.  That’s just not how I roll.  My Flex project is my Flex project.  My Server project is my server project.  They get together for drinks but they’re just friends; they don’t sleep together.

I actually ended up not using any plugins.  Nightly builds are great to play with but I actually need to build a server that’s a LITTLE more stable.  I decided to use the latest version of Blaze and Spring-Blaze library.  With a little tiny bit of customization and configuration (you can’t avoid it completely) I was also able to get Spring Security to work with my services.

In the next few posts I’ll let you know how I did that!  I’ve got some other things I hope to try as well as I journey through this server setup and I might get a chance to talk about those too!  There are a lot of info about these topics out there but I had to bounce all over the interwebs to get all of the information I needed.  So maybe this will help somebody else out there save an evening or two and jump right into their own projects.

Part 2 – Setting up Grails, installing Blaze/Spring-Blaze & creating a Flex Project to talk to it.

Part 3 – Installing the Spring Security Plugin and locking down the services.

Parts 4 through n – Facebook?, Google App Engine?

]]> http://pbking.com/blog/?feed=rss2&p=233 0 http://pbking.com/blog/?p=233 PhxFPUG Assets http://feedproxy.google.com/~r/ThePeanutButterThoughts/~3/jb1yzjj86KQ/ http://pbking.com/blog/?p=228#comments Wed, 27 Jan 2010 23:41:36 +0000 Jason Crist http://pbking.com/blog/?p=228 If you’re coming to the Phoenix Flash Platform User Group meeting tonight (and I hope you are!) or you are there now, or maybe you heard about how cool it was then these things might be helpful for you.

The two tools we’ll be talking about are RobotLegs and Swiz.  Here are the links to their respective locations on the interweb.

http://www.robotlegs.org/

http://swizframework.org/

If you’re playing along then you might want to download the projects I’ll be demoing.  Please keep in mind that these projects attempt to demonstrate how these tools work; NOT NECESSARILY BEST PRACTICES.  They are only meant to give you a basic understanding of the principals.

FPUG Projects

If you just want to download the .swc files (which are included in the projects as necessary) then you can grab them here.

RobotLegs 1.0.2

Swiz 0.6.4 (for Flex 3)

Facebook AS3 lib 3.4

And if you want to “borrow” my Facebook App key and secret you can use these values (they are going to get changed after tonight and it’s a sandbox app anyway so you won’t be able to do anything fun with it anyway).

API Key: abcdefghijlkmnopqrstuvwxyz

Secret: nowiknowmyabcsnexttimewontyousingwithme

Lastly, if you care to follow along with my slides you can download those here.  You probably won’t get much without me standing in front of them being awesome, but you are welcome to them if you want ‘em.

PFUG DI Preso

]]> http://pbking.com/blog/?feed=rss2&p=228 2 http://pbking.com/blog/?p=228 Klok – This stuff shouldn’t be free http://feedproxy.google.com/~r/ThePeanutButterThoughts/~3/7H38CKxwgDM/ http://pbking.com/blog/?p=225#comments Mon, 25 Jan 2010 21:17:23 +0000 Jason Crist http://pbking.com/blog/?p=225 Klok 2I recently started testing the new version of Klok.  Klok is an Air app used to track your time.  Version 1.5 has been out for quite a while and I didn’t work without it running.  I tend to jump around my projects quite a bit and I usually have to keep track of how much time I spend on which tasks, etc.  Klok has always been a great tool to let me do that.  And it’s a free application!  Version 1.5 is available now and 2.0 is under active development and has made some FANTASTIC improvements.  This thing is, it SHOULDN’T be a free application.  I really think it’s that good.  I won’t go over all of the features that make it awesome cause this is a short post and I’ve got lots of actual work to do (yes, I’m logging the time I’m spending to write this blog post).  There’s lots of great time keeping apps out there and I’ve used lots of them.  This is the one I like the best.

Right now you can’t download the 2.0 beta unless you donate to the project.  So ACT NOW while the application isn’t free.  It’s totally worth it.

Now back to the work I get paid to do . . .

]]> http://pbking.com/blog/?feed=rss2&p=225 1 http://pbking.com/blog/?p=225 FlashVar manager using Swiz or RobotLegs http://feedproxy.google.com/~r/ThePeanutButterThoughts/~3/0yXRb2njTbo/ http://pbking.com/blog/?p=220#comments Fri, 22 Jan 2010 20:21:44 +0000 Jason Crist http://pbking.com/blog/?p=220 I use FlashVars a lot. Sometimes I need to open or launch something from my application on startup. Sometimes I just need to know some authentication credentials and that’s the way they are passed to me. Something that I have found that has made this easier for me has been to create a FlashVarManager for my projects.

FlashVars are gleaned from a LoaderInfo object and it is just a dynamic Object. (loaderInfo.properties to be exact). But you probably knew that. Being a fan of strongly typedness I usually create some getters on my manager that will fetch a specific flashVar from the .properties object and if there isn’t one give me a default. Since I always did this for Flex projects the most straightforward way to grab what I needed was through the Application instance. My manager would look something like this.

package com.pbking.demo
{
  public class FlashVarManager
  {
    private static var:_instance:FlashVarManager;
    private var _flashVars:Object;    

    public static function getInstance():FlashVarManager
    {
      if(!_instance)
      {
        _instance = new FlashVarManager();
        _flashVars = Application(Application.application).loaderInfo.properties;
      }
      return _instance;
    }

    public function get flashVars():Object
    {
      return _flashVars;
    }

    public function get specificFlashVarValue():String
    {
      if(flashVars[‘specificValue’] != undefined)
        return flashVars[‘specificValue’];
      else
        return "someDefaultValue";
    }
  }
}

Something like that.

So if ever my flashVars had to change I could just change this class. I will often perform logic in here too; sometimes create a faux “flashVar” that is based on a number of flashVars. I find it pretty handy.

But I’m trying to eliminate Singletons wherever I can. Not necessarily Singletons in the “one instance exists” sense, but more in the .getInstance() sense. RobotLegs and Swiz are really helping me out with that. But how to construct my FlashVarManager with those tools? How do you get to the loaderInfo of the app (without using the messy Application() hack)?

Pretty simple really. Swiz will allow you to mark a controller as an IDispatcherBean. That means that it passes in an IEventDispatcher upon which you can dispatch events into the framework’s event bus. Well that IEventDispatcher just happens to be a DisplayObject from which you can grab the loaderInfo. (The exact item passed in in 0.6.4 and 1.0beta are different but the execution is the same.) Then you just have to include that puppy in your beanmap so that it can be injected wherever it’s needed.

That would look something like this:

package com.pbking.demo
{
  public class FlashVarManager implements IDispatcherBean
  {
    private var _root:DisplayObject;
    public function set dispatcher(newVal:IDispatcher):void
    {
      _root:DisplayObject = DisplayObject(newVal);
    }

    public function get flashVars():Object
    {
      return _root.loaderInfo.parameters;
    }
. . .
 

Doing the same with RobotLegs is even easier. You can have injected into an Actor the “root display” of your context. Pull the loaderInfo out of that and rock and roll. Just map that class into your context and Bob’s your uncle.

package com.pbking.demo
{
  public class FlashVarManager
  {
    [Inject]
    public var contextView:DisplayObjectContainer;

    public function get flashVars():Object
    {
      return contextView.loaderInfo.parameters;
    }
. . .
 

Enjoy!

]]> http://pbking.com/blog/?feed=rss2&p=220 2 http://pbking.com/blog/?p=220 Signals may spell the death to my Commands as I know them http://feedproxy.google.com/~r/ThePeanutButterThoughts/~3/ul__JCYGJsg/ http://pbking.com/blog/?p=211#comments Wed, 20 Jan 2010 04:01:28 +0000 Jason Crist http://pbking.com/blog/?p=211 Back when I wrote my Command library I was doing a lot of calling of commands.  It actually stems from the Commands/Delegates I created for the Facebook AS3 API (which have since been removed; which I think is a shame).  Essentially the greatest benefit I got from my commands with the ability to do this:

commandInstance.addCallback(onComplete);
function onComplete(commandInstance:CommandClass):void
{ // do stuff }
 

instead of this:

commandInstance.addEventListener(Event.COMPLETE, onComplete);
function onComplete(e:Event):void
{
  var commandInstance:CommandClass = e.target as CommandClass;
  commandInstance.removeEventListener(Event.COMPLETE, onComplete);
  //NOW I can do stuff
}
 

That got rid of a lot of code for me and made me very happy.

Boss: Jason, how many lines of code did you write today?
Me: (proudly) Negative two-hundred-sixty-nine!

Just kidding. My boss has never asked me how many lines of code I wrote.

But the less code I have to write the more time I get to spend blogging. Or playing Super Mario Bros Wii. Or closing bugs. And the easier it is to tell what the HELL is going on. And the less likely I’ll be to forget to remove listeners. All good stuff right?

Well the benefit only worked if I was extending one of my AsyncCommand classes. Which worked pretty well since most of the stuff that I wanted to work that way was “business logic” stuff that I stuck in a command. I would execute and wait for the result.

If the result was bad then I could just check the .success property and put a little logic in the callback handler. But wouldn’t it be cool if I could do that for all KINDS of events? And by “events” I mean “Stuff Happening” not dispatchEvent(new Event());

Well Robert Penner’s Signals is almost exactly that. Imagine an object that has a number of things that could happen. Probably not hard; most of you have pretty good imaginations. For the case of my commands it could be complete and error. That command would then have a .completeSignal object and a .errorSignal object. These are Signal objects to which I can subscribe. Usage would be something like this:

asyncCommand.completeSignal.add(completeHandler);
asyncCommand.errorSignal.add(errorHandler);
 

Then when the command has finished running the completeHandler is called. And it’s not passed an event from which I have to glean what tossed the event and type it. it’s the strongly typed command that dispatched the signal . . . just like my addCallback() method did!

So I’m thinking, since being able to listen for lots of things happening is better than listening for ONE thing to happen . . . well that might just spell the end to the Peanut Butter Commands. At the very least I think I might re-factor things to use Signals instead of my own home-grown callback handling logic. I’m just beginning to play with Signals but I’m already very pleased with how it makes my code look.

I’m beginning to question the idea of calling commands directly anyway. I mean it sure is damn handy. I hate tossing events to get stuff to happen; it just seems like a lot more code to me. Usually, in the software I write, the ONLY thing that cares about when a command is finished is whatever called the command in the first place. And besides I can always let people know that a command finished (via an event or a signal) right?

There has been some active talk on the RobotLegs group about combining the powers of the Legs and Signals. It sounds like it’s going pretty well and I’m really interested in playing with it (once I get a bit more code written that I’m paid to write). My distaste for Events drives me to find any solution I can to get rid of them in as many places as I can.

By the way, nice work Robert.

]]> http://pbking.com/blog/?feed=rss2&p=211 1 http://pbking.com/blog/?p=211 Swiz vs RobotLegs LIVE! http://feedproxy.google.com/~r/ThePeanutButterThoughts/~3/JbY6IDFAWZo/ http://pbking.com/blog/?p=209#comments Wed, 13 Jan 2010 17:46:03 +0000 Jason Crist http://pbking.com/blog/?p=209 Since I began my DI framework journey I have used these two tools a lot.  I’ve gone back and forth and back and forth over which I like better.  Strangely, it’s usually the one I’m NOT currently using that I favor.  The things I miss always stand out when I can’t use them.

Well on Wed Jan 27th I’m going to be hashing these two frameworks out live at the Phoenix Flash Platform User Group.  For those unfamiliar with Dependency Injection frameworks I’ll go over the basics of how to get started with both Swiz and RobotLegs and how they are the same.  It will be a “lab” session and my plan is to walk everyone who is interested through the process of building a working sample.  Check back here the day of the presentation for links and resources to help us along.  It MAY help to have a Facebook account and SOME familiarity with building Facebook apps with the AS3 API.  I’m thinking of doing that as the example apps.  What do you think?

Then I’m going to talk about how the two frameworks are different.  I’m going to try very hard to be impartial.  I LOVE both of these frameworks.  There are a few points about them that I’m planning to go over (besides the basics of how to set them up).

  • What is a Context and why does it make my hair look better?
  • Will Swiz 1.0 alpha make by teeth whiter than 0.6.4?
  • What if I want to process my own MetaData?  Can any of this help me?
  • I REALLY like to use PatternX instead of Pattern42 when dealing with my views.  Can I do that?
  • Commands vs Controllers on WWF SmackDown.  Who’s logic will win?
  • Does/should a 1.0 version really matter? (Yes, I want to talk about this one, but probably only AFTER the meeting once the booze has started flowing).

My question to you, the concerned reader is what else should I discuss?  Are there any benefits or differences that you would like to see that I point out?  Please leave your comments here (in a timely manner) and I will do my best to get the points into the presentation.  I know there are other similar frameworks out there (Parsley is actually one I like a lot too) but these are the two I use daily and am most familiar with.  They are the ones I decided to put into my toolbox so they are the ones I will talk about.

I will try to tape the presentation or at least make the slides available so maybe that can help others out there who want to get started.

]]> http://pbking.com/blog/?feed=rss2&p=209 11 http://pbking.com/blog/?p=209 Swiz vs RobotLegs http://feedproxy.google.com/~r/ThePeanutButterThoughts/~3/ZY8T1bUfJuk/ http://pbking.com/blog/?p=203#comments Wed, 04 Nov 2009 09:27:44 +0000 Jason Crist http://pbking.com/blog/?p=203 Recently I spent some time converting a medium-sized project first to Swiz and then to RobotLegs.  The following is my take on the two frameworks and how I chose a winner.  Right now there are definitely a lot of things I like about both frameworks, and I wish I could pick and choose the features I like best.  I would call it the Peanut Butter Framework Mashup Extraordinaire.

I have considered giving Mate and Parsley a similar go but Swiz and RobotLegs were the two that definitely interested me the most so I’ve done them first.  I’m pretty familiar with Cairngorm and don’t personally like it.  I think I’ve read and tinkered with PureMVC enough to know that it isn’t my ball of wax either.

Keep in mind that I am refactoring an EXISTING project to use these frameworks.  I am not starting a project from scratch.  If I were then I might feel differently.  Maybe.

What is important to me?

The most important things about a development tool, be it an IDE, a library, a repository or a framework is:

  1. How quickly can it help me get the job done?
  2. How quickly can it help me add new features?
  3. How quickly can it help me find and squash bugs?
  4. How little code can I write to get the job done?

And that’s it really.  I want to write as LITTLE easily understandable code as possible and I want to be able to easily fix it and add to it.

Don’t code it ’till you need it.

For me writing code is not always a task of reuseability.  If I build something for a project then it’s for THAT project.  If I see that some piece of code could be helpful elsewhere then I will take the time to make that piece a project and allot it its own time.  By carefully choosing what gets “bumped up” into reuseability land I am able to get the job done faster and with less effort.

With that in mind it’s important that the framework I’m using allow me to do that; write code quickly.  That isn’t to say I’ll settle for spaghetti code just because it closes the job ticket faster.  I know I’ll also be the one adding features to this puppy and fixing bugs.  So I want it to stand the test of time.  So the framework will also need to gently guide me to do that as well.

Map Commands vs Mediate Methods

One difference between Swiz and RobotLegs seems to be how they handle “triggered logic”.

Using Swiz you define instances of Controllers in your Bean Map.  In those controllers you will have a number of methods that get called when an event is fired that Swiz captures (mediates).

You can use events to trigger calls to methods in RobotLegs as well but only in certain siturations (Mediator classes).  It seems to instead suggest that you map Commands to Events, a technique which I was first introduced to in Cairngorm.  The WAY this happens is different than Cairngorm, but the idea is roughly the same: When X happens this Command Class is created and executed.

That’s actually how the project was working before the conversion (though it was using a home-rolled solution for that).

Now I LOVE commands.  I really like to use my own command library.  I don’t always want to have to link a command up to an event.  With my library I can play with my commands from anywhere in my code.  Generally I don’t care when a command starts, finishes, etc except from where I actually called the command.  This helps me keep my code-base as small as possible; needless custom events aren’t created when only one place cares about something happening.  When I DO find that event information is helpful elsewhere then I can just dispatch some informative events from the command itself (using whatever the framework of the day is).  With this in mind any tool that lets me to easily continue working in this manner is a win for me.

Using RobotLegs I’m able to map an Event to a Command.  Awesome.  I can even inject some data into it.  Cool.  But the Command needs to be an ICommand.  And I couldn’t find ICommand in the library so AFAIK the commands actually have to extend robotlegs.Command.  Not cool.  I have dozens of commands already written and tied to another library.  I could just change the Commands that need to be triggered by events but that sounds like a royal pain-in-the-ass and additional work == bad thing.

Using Swiz I’m not able to map the commands to events.  I don’t like that.  However I CAN create and execute the commands from the Controller.  The Controller is mapped from the same BeanMask that the model objects are mapped in and it just contains a bunch of methods that get called when events fire (defined by MetaData).  That actually gives me a little more control.  I can inject the dependencies into my existing commands if I want to.  But in my project all of my commands actually have constructor parameters.  So I just inject properties into my Controller and using that and the properties on the dispatched events I handle the execution of the commands.  It’s not incredibly elegant but it gets the job done and there isn’t much code to write or change.

Getting Events Out There

Bubbled events are cool right?  Sure they are technically “expensive” and there are the rare cases of apps fighting each other over bubbled events that they throw at each other.  A “Bubble Fight” I call it.  Personally I’ve never witnessed one.

RobotLegs is very strict about NOT relying on the DisplayObject tree as a means to move event messaging back and forth (bubbling).  Swiz lets you do just that.  Bubble an event up from any attached view and any methods assigned to that event will be called.  Easy-peasy.   That’s another win for Swiz.

Singletons are Awesome

No their not.

Fortunately both frameworks allow you to more elegantly handle Singletons and actually ALL the data that exists in a project.  Using DI (Dependency Injection) you can have objects that the framework is aware of injected right into your classes.  Both use some type of MetaData to define that.  [Autowire] is Swiz’s and [Inject] is RobotLegs, but it comes down to the same thing.

DI allows you to do away with the classic “Singleton” pattern.  Class.getInstance() sucks.  Even when you don’t care about reuseability it still sucks.  As far as the injecting/tagging goes I can’t say that I’ve got a preference.  But for registering these items I like Swiz better.

In RobotLegs you have a class that kind of “kick starts” things.  One popular place to put the items to be injected is there.  I understand, however, that you can actually do this in a number of places in a number of ways.  That sounds like trouble to me.

In Swiz the accepted way of doing this is in an (M)XML document; the BeanMask.  This document will define all of your “model” objects.  These are the objects that can be [Autowire]d.  That seems clean to me and I like it.  You can have multiple Bean Masks if your project gets large, but at least you’ll know where to look for stuff.

Code from Behind vs Reach Around

I’ve got a number of views that are small.  Small enough that I just put the necessary view logic in a <Script/> tag.

Sometimes that logic will grow and grow and I’ll just pull it out into it’s own class.  Usually I just do a code-behind.  (The MXML class extends an ActionScript class which has all the logic in it.)

Previously I had a “Global Event Dispatcher” that my views listened to.  Methods were called when those events were dispatched from that “Global Event Dispatcher”.

RobotLegs doesn’t like that.  I need to have a Mediator class for my logic.  Then I need to bind that mediator class to the view.  But not actually IN the view.  Or even in the mediator (though the mediator should have a REFERENCE to the view).  The binding takes places somewhere else.  If I don’t play by those rules then I don’t get the benefit of mediated methods for my view.

Swiz doesn’t care.  I can just stick [Mediate] on any public view method (<Script/> or code-behind) and it will work just fine.  I’m not opposed to mediator classes.  I think that is a fine (and cleaner) alternative to a code behind.  But I don’t want to HAVE to do it that way.  Unfortunately, that method DOES need to be public, which I DON’T like.  I think I can get over that, but it’s essentially an event handler.  It’s not something that anyone outside of that view needs to know about.

Services

Ok, I honestly didn’t put either framework through the paces when it came to working with my Services.  All of my service handling is already done in a way that is already clean and I saw no need to change that at all.  This wasn’t an important part of either framework for me.

Best Practice vs Get ‘er Done

Shaun Smith had a great piece about “why RobotLegs”.  And I couldn’t help but get fired up about his reasons.  They are good ones.  But they seem like good reasons on paper, not necessarily in practice.  Like I said, if I had started this project out fresh instead of trying to port it then I might feel differently.  But when I look at all the code I would have to change/add using RobotLegs that shows me that there might be a lot of code that I shouldn’t have to write.

When I ported everything to Swiz it took me a couple of hours and I had things rolling.  I was able to change just a portion of my application to rely on the framework.  It worked alongside what I already had.  But it took me the better part of some valueable sleepy-time to get RobotLegs working.  And even then I still had mountains of Mediators to create before the app was truly “working”.  Don’t think I’m a hater.  I DO really like what RobotLegs is all about.  But it’s just not for me; it doesn’t fit my workflow or my coding style.

Swiz does.

It’s late

If I’ve gotten anything wrong describing the usage of either of those frameworks then please correct me.  I admit that I am a total n00b at both of these.  I tried to keep it general and relatively vague; there are plenty of other resources that explain how these things actually work much better than I could.

Sleepy time.

]]> http://pbking.com/blog/?feed=rss2&p=203 14 http://pbking.com/blog/?p=203