PureMVC for Flex. A Flex Builder-induced Gotcha

I've blogged previously about a Flex application, on which I am currently working, that is backed by .NET Web Services. Other than the Authentication Service, the other Web Services require an authentication Token in order to execute.

Before working on this application, I never worked with Web Services as my data source in Flex (I've typically used Flash Remoting via a ColdFusion server). As such, I am no expert in SOAP requests and responses.

One of the things I had trouble with was getting the data from the SOAP response header's XML. Typically, most the data I need is in the Body of the SOAP response. However, when a user in the application is authenticated, the Token object's details are contained in the SOAP header:

  
    
      4511ec65-e25b-4c08-8f94-478df913692c</Id>
      bbd12fa7-f292-4bc5-a37f-06234e877ad8</UserId>
      user_name</UserName>
      e6b3998c-13d9-49fe-a13e-7af27c8229fd</ApplicationId>
    </Token>
  </soap:Header>
  
    
      true</AuthenticateResult>
    </AuthenticateResponse>
  </soap:Body>
</soap:Envelope></pre>
As you can see from the code above, the body's response is true (meaning we've been authenticated...naturally, this would be false if authentication failed). However, in order to make another call, I need to extract the Token XML object from the soap:Header element and store it in a Flex object (also called Token). 

The problem was that I could not take the E4X approach to XML because the SOAP namespace caused problems (I could not traverse the XML). Here's what I did previously to get around this problem (it works but I know it is 'wrong'):

private function onAuthenticateSuccess( e:ResultEvent ):void
{   
 var respXML:XML = e.headers[0] as XML;
 token = new Token0();
 token.Token = new Token();   
 token.Token.Id = new Guid(respXML.children()[0].toString());
 token.Token.UserId = new Guid(respXML.children()[1].toString());
 token.Token.UserName = respXML.children()[2].toString();
 token.Token.ApplicationId = new Guid(respXML.children()[3].toString());
}

The slightest change in the SOAP Response's Header XML would kill this (i.e., if the element ApplicationId was moved up to the 3rd spot (array index 2) and UserName was moved to the final spot). Plus, it's not only ugly to look at this code but also goes against all the goodness of E4X in AS3.

In one of my iterations, since bagged, I used a Regular Expression to manually remove the namespace from the XML. This sort of worked but when there were multiple namespaces in use, I still ran into problems. So, I stuck with my crappy approach (above).

While working on migrating this application to Flex 4, I started digging into the Flex LiveDocs again today. In so doing, I came across an entry about working with XML data. Specifically, it related to parsing XML data in RSS feed.

While this wasn't directly related to what I was doing, I found a tidbit on namespaces in XML. In short, I learned how to simply reset the XML namespace to a blank namespace (i.e., remove the namespace altogether). As soon as I did this, I was able to use the E4X approach to XML in my ActionScript to cleanly and clearly extract the Token object from the SOAP response's header XML.

Note:
The following code is a little different from the previous block in that it's from Flex Builder 4 (Gumbo), which parsed the Web Services in a different manner than Flex Builder 3 does/did. Specifically, Gumbo produces a cleaner Token object than Flex Builder 3 did. As a result, I did not need to create sub-objects (above is token = new Token0() and then token.Token = new Token()).

private function authResult( evt:ResultEvent ):void
{
 var tokenXML:XML = new XML(evt.headers[0]);
 if( tokenXML.namespace("") != undefined )
 {
  default xml namespace = tokenXML.namespace("");
 }
 token.ApplicationId = tokenXML.ApplicationId;
 token.Id = tokenXML.Id;
 token.UserId = tokenXML.UserId;
 token.UserName = tokenXML.UserName;
}

The key to this solution starts in the second line of the above function (the if statement). I check to see if the XML from the SOAP header has a namespace: if it's not undefined, then we've got a namespace in play. If we find a namespace, the default XML namespace is set to a blank string. Once that's taken care of, it's easy to take the E4X approach, treat my XML (tokenXML) as an object and grab the values from the XML and store in the respective properties of the Token object. This code is SO much cleaner and it has the added benefit of not caring about the order of the XML in the SOAP Header. The server-side developers can make changes and, so long as the properties do not change, my code doesn't care. 

I realize this is pretty basic stuff for many who've worked with Web Services in Flex as their data model/source over the years, however, my hope is that it might save someone new to this part of the Flex world a bit of time!</div>
Comments


Anonymous

This comment has been removed by a blog administrator.


Craig Kaminsky

@anon: Thanks for your comment. 

In FB3, I did use the WSDL introspection tool, which does indeed create the classes like you describe (I had a problem with the Auth service classes that the WSDL introspection created, which is why I had to go to the XML--there were no classes to get the Token object from the header). 

In FB4, it's a bit different. You select an option to "Connect to a Web Service" and then enter the WSDL. However, it does not create these classes any longer. Through the Data/Services view, you are supposed to be able to set the return data type from the service. 

In fact the content property of the headers object doesn't exist in FB4! I can see it, however, in FB3. Its interesting where there going with data services in Gumbo and, for the most part, it seems like a major improvement but I'm still trying to figure it all out :)


Anonymous

Craig,

I noticed that you mentioned that Flex Builder parsed yr webservices and was wondering if you meant the WSDL introspection tool in FB3/4.

If so, then you won't be needing to deal with XML at all really. The introspection strong types all the available elements declared in the WSDL of the web service allowing you to treat that Token soap element as the generated Token class. But you have to use the generated Service classes as well in order to be able to take advantage of those benefits. I noticed the typed ResultEvent and assumed you are not, because the response events are also typed to classes and use a naming scheme like AuthenticateResultEvent, where the result property is of course typed. In this case would be a boolean.

If you choose to use the generated services, you can simply access the already typed return token via the headers property of the result event like so:

evt.headers[0].content

If the only returned header is indeed the authenticated token, then can always expect an object of that class, without have to create it yrself.

Yesterday, while working on a Flex project, I had to significantly alter how I was using a particular DataGrid in the application. Originally, this DataGrid allowed an authenticated user the opportunity to associate other users in the system with their particular project.

The process was, at the time, simple: adding a user simply meant clicking a button and editing the default information in the grid. Removing was just as easy. Select the user in the grid and press the button for remove.

However, the Web Service on the back-end was not fully designed for this feature and how it would play out in "real life". The documentation indicated that you simply pass in the grid data (converting said data to the appropriate objects for the service to process) and the Service would handle the rest.

As we flushed out this service more (this is the first project where I haven't control the server-side code...it's weird), we decided to make some good changes. The way out changes played out in the DataGrid was that I needed a way to track what users were added to or removed from the grid.

For a newly associated user, the process was easy. I added a property, named "Add", to the Value Object (VO) I use as the basis for the DataGrid. When a new user is added to the grid, I set the value of the "Add" property to "true". An existing user in the grid's value for this property was already set to "false".

But what about removing a user? If I removed them from the grid as in the previous approach (above), I was left with no simple way to track the removed user. So, I decided (in the interest of time) to add a Remove property to the VO. Not surprisingly, the Remove property defaults to "false". This property's value would be best set/unset in the grid itself...but how?

I decided to use an Item Renderer in the grid for this property and chose a checkbox (mx:CheckBox). It seemed easy enough to do this. In fact, the code to use a mx:Checkbox component as an item rendered in the DataGrid is as easy as this:

Pretty easy. However, I needed a way to dispatch an event when the checkbox was clicked/selected. Along with this event, I needed to pass the row number in the grid of the selected item so that I could properly set the Remove property to "true". The Web Service does not accept boolean values, only string, hence why I am using "true" and "false" and not actual boolean values.

 
  
  
           
    
     
     --CDATA opening 'tag' removed for code sample
      import com.nci.asa24.admin.control.events.ColumnSelectedEvent;
      private function sendClick( evt:Event=null ):void
      {
       var event:ColumnSelectedEvent = new ColumnSelectedEvent( ColumnSelectedEvent.COLUMN_SELECTED, this.listData.columnIndex, this.selected );
       dispatchEvent( event ); 
      }
    --CDATA closing tag removed for code sample
     
    
   
  
 

An important thing to note is that when you use an item renderer in this way, it runs in its own scope, unaware of what's going on in the containing component (the mx:DataGrid, etc.). This really threw me and is why you see the mx:Script block in the renderer.

Additionally, check out the listData property of "this". I never knew about this property before (the things I don't know and keep learning about Flex/AS3 constantly amaze me!). In short, it references the containing grid and its details. Very, very handy! It's also how we get the currently selected row number to use when updating our property.

You'll also notice in the code above that I imported a custom event (this event was taken from the Flex 3 Cookbook). Here's that event class, for those interested:

package com.
{
 import flash.events.Event;

 public class ColumnSelectedEvent extends Event
 {
  public var colIndex:int;
  public var isSelected:Boolean;
  
  public static const COLUMN_SELECTED:String = "ColumnSelected";
  
  public function ColumnSelectedEvent( type:String, colIdx:int, isSelected:Boolean )
  {
   super(type,true,false);// note that I set bubbles (param 2) to true...this is a must!!   
   this.colIndex = colIdx;
   this.isSelected = isSelected;   
   
  }
  
  override public function clone():Event
  {
   return new ColumnSelectedEvent( type, colIndex, isSelected );
  }
  
 }
}

This event captures two key pieces of data: the currently selected row in the grid and whether or not the checkbox is selected. I'll use the later to determine the correct value to apply to the Remove property.

NOTE In the comments of the code snippet for the custom event above, I note that I set the bubbles property of the event to true. This was crucial for me. Without having the event bubble up, the listener for the DataGrid never heard the event. Do not forget to check that (bubbling property) if you are in this situation!!

In order to "hear" the checkbox being clicked, I added an event listener to the mx:DataGrid element. To do so, I assign a function to the creationComplete handler in the mx:DataGrid's attributes (creationComplete="assignListener()") that will setup the listener. That function follows:

private function assignListener():void
{
 this.dg.addEventListener( ColumnSelectedEvent.COLUMN_SELECTED, removeSelected );
}

Pretty simple, really. Now, here's the "removeSelected" function that gets called when the event is captured.

private function removeSelected( evt:ColumnSelectedEvent ):void
{
 if( evt.isSelected )
 {
  this.dg.dataProvider[evt.colIndex].Remove = "true";
 }
 else
 {
  this.dg.dataProvider[evt.colIndex].Remove = "false";
 }
}

With this code in place, I am able to easily have the value of the VO's remove property set to the strings true or false.

I hope that this post can save someone (anyone, really :) ) a little time if you're in a similar position with your application.