In January I had the opportunity to visit the Queen City to provide some Flex training to a great team of developers under the queen’s crown, and to spend time with some dear friends as well. They (the developers, not the friends) had a requirement to produce bubble charts that had labels inside the bubbles. It occurred to me that other people could probably use this feature, too, so I decided to polish it up a bit and make it available. The result is two classes, LabeledBubbleRenderer and LabeledBubbleSeries.
To implement the functionality, simply create a BubbleChart, and then put a LabeledBubbleSeries tag where you would normally put your BubbleSeries. You should never need to explicitly reference the LabeledBubbleRenderer, because the LabeledBubbleSeries class uses it as the default renderer.
<mx:BubbleChart>
<mx:series>
<rd:LabeledBubbleSeries />
</mx:series>
</mx:BubbleChart>
The primary departure from the standard BubbleSeries class is that the LabeledBubbleSeries has a fourth data field: In addition to xField, yField, and radiusField, there is also a labelField property. As the name suggests, this is the name of the field that stores the string that should be displayed in each bubble’s label.
<mx:BubbleChart>
<mx:series>
<rd:LabeledBubbleSeries labelField="name"
xField="leads"
yField="sales"
radiusField="commission" />
</mx:series>
</mx:BubbleChart>
Secondarily, there are also a couple of additional styles, which control the location of the text within the bubble. These values, of course, are passed on to the LabeledBubbleRenderer instances which draw the circles and display the text.
<mx:BubbleChart>
<mx:series>
<rd:LabeledBubbleSeries textAlign="center"
textVAlign="middle" />
</mx:series>
</mx:BubbleChart>
I have posted a very simple demo app that shows how this all fits together.
If you look at the code, you will see a rather tight coupling between the two classes. I did not view this as undesirable because I could not think of a reason why you would want to use one without the other. However, the code is free for you to modify as needed. If you do make a significant modification that you think might benefit others, please let me know, as I would like to integrate it.
Finally, a disclaimer: As you have probably already noticed, this code is not independent of Adobe’s Data Visualization components. So if you don’t have those, this won’t do you much good. But if you do have them, then you may find this to be a useful little enhancement. Enjoy!
This being the 17th of March, allow me to close with this wish: Erin Go Bragh.
In my first Flex/Alfresco webinar, I showed how you can log in to Alfresco from a Flex UI using Alfresco’s Flex SDK. That was nice, of course, but it was also sort of a tease: it left folks wanting to see the next step. Well, it took a while, but I finally recorded a new screencast that shows how to get content from an Alfresco repository and display it in Flex. You can watch the video and download the Flex source code here. You can also see the video directly on YouTube, but you can only get the code on the Rothbury site. Please let me know if you have any questions, suggestions, frustrations, cogitations, meditations, salutations, etc.
Stay tuned for Part 3, where I plan to show how I created the custom Alfresco web script.
(UPDATED LINKS ON 1/3/2011)
I was delivering Cairngorm training to a client’s development team, and the team lead mentioned that the old Cairngorm Diagram Explorer really helped him get a feel for how the various moving parts of Cairngorm work together. After browsing through it, everyone on the team agreed that it was a great tool, but that since it was out-of-date (based on Cairngorm 2.0/Flex 2) it could be confusing to new developers. So I decided to bring it up to Cairngorm 2.2/Flex 3, following the best practices outlined in the Cairngorm training materials.
You can click here to view the Explorer and interact with it, or click here to download the zip that includes the Explorer and the Flex application on which it is based.
Let me know if you run into any issues or if you see room for improvement.
I’m on The Flex Show this week, talking a bit about Flex/Alfresco integration. Jeff and John were great, and I think I managed to get some useful information across in spite of the fact that I was recovering from the flu when we recorded it (back in December). There are a couple of items that need improving/correcting, but listen to the show first, then come back here for the clarifications.
OK, here we go. For one thing, I have learned since doing the show that in addition to Alfresco, there are other open-source Enterprise Content Management Systems (ECM’s) out there. (When we did the show I knew about projects like Drupal and Joomla, which are great, but they are Web CMS, not enterprise systems.) In any case, Alfresco is the one embedded in LCDS, so it’s going to be the one that has the most potential to impact us as Flex developers.
Another thing I realized in listening to the recording is that I did not do a very good job of describing the Flex/Alfresco implementation that we did for the large hospitality corporation. The application is really a lot cooler than I made it sound. On the Alfresco side, the repository has models and custom content types that map to the corporation’s specific needs. On the Flex side, VOs map directly to these custom content types. The UI presents these as custom item renderers/item editors, with each renderer/editor being specific to a content type. The screens then group these custom renderers/editors based on business logic, not content type. For example, if the user does a search on “Pets”, the application will respond by displaying a list of content items that relate to pets, regardless of the content type of the individual items. It was a bit of a challenge to display renderers/editors for all of these disparate content types in a consistent and user-friendly way, but I think we succeeded.
The application also had alerts to prompt users to appropriate action. For example, many content types had specified periods of time that they were considered to be valid, after which they became “stale”. This period of time varies between content types, and can be configured in the administrative interface. On the Flex side, items that are soon to become stale are highlighted so as to draw the users’ attention to them.
But perhaps the best thing about the application is how it allows different groups of users to interact with the content as a team. For example, the groups that are responsible for entering the content are dispersed around the globe, whereas the groups responsible for reviewing and approving the content are located in the corporate offices. These reviewers/approvers do not have rights to edit the content; they merely review it, and if it needs modification, they return it to the responsible party with notes as to what needs revising. They can also assign tasks to the entities responsible for entering and updating the content.
I could go on with this, but hopefully you are getting the idea that there are a lot of things that you can do when you have an ECM on the backend and Flex on the client.
I’m in the process of developing a new Flex 3 RIA, and the server code is not yet written, so I’m using static XML files to provide data while I build out the UI functionality. The XML files are stored on my development machine in a subdirectory of the folder that holds the main SWF. It’s all a very standard setup, and I was successfully loading two files from the same subdirectory, so I was very surprised this morning when I got a security sandbox error:
Error #2070: Security sandbox violation:
caller cannot access Stage owned by .
As implied by the reference to “Stage owned by”, this error is supposed to occur when you are loading a SWF from an unauthorized domain. I did some quick searching on Google, and everything I looked at had to do with loading a SWF. The stack trace did not clarify the issue either:
[RPC Fault faultString="Error #2070: Security sandbox
violation:caller cannot access Stage owned by ."
faultCode="Client.CouldNotDecode" faultDetail="null"]
at mx.rpc.http::HTTPService/http://www.adobe.com/
2006/flex/mx/internal::processResult()
[E:\dev \3.0.x\frameworks\projects\rpc\src\mx\rpc\http
\HTTPService.as:842]
at mx.rpc::AbstractInvoker/http://www.adobe.com/2006/flex/
mx/internal::resultHandler()
[E:\dev\3.0.x\frameworks\projects\rpc\src\mx\rpc\
AbstractInvoker.as:186]
at mx.rpc::Responder/result()[E:\dev\3.0.x\frameworks\
projects\rpc\src\mx\rpc\Responder.as:41]
at mx.rpc::AsyncRequest/acknowledge()
[E:\dev\3.0.x\frameworks\projects\rpc\src\mx\rpc\
AsyncRequest.as:74]
at DirectHTTPMessageResponder/completeHandler()
[E:\dev\3.0.x\frameworks\projects\rpc\src\mx\
messaging\channels\DirectHTTPChannel.as:381]
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at flash.net::URLLoader/onComplete()
I suspected something was wrong with the XML file, since the UI was successfully loading other files from the same directory. I opened the file in XML Spy, which immediately displayed a message to the effect that the XML was not well-formed. And sure enough, I had missed something. Here is what the XML looked like:
<page>
<name>page1</name>
<type>pagetype</type>
<previewUrl>previewUrl</previewUrl>
<path>page/path1</path>
<promoTypes>
</promoType>typeOne</promoType>
</promoType>typeN</promoType>
</promoTypes>
</page>
You will probably see the error right away, but to my embarrassment I didn’t. How did the error creep in? Well, I had copied the sample XML from the design document (which I did not write) and pasted it into an XML file so that I’d have something to pull in for development purposes, and evidently I did not check it over very carefully. (If you don’t see the error, look closely at the promoType tags, and you’ll see that the opening tags have closing slashes.)
I fixed the XML, the error vanished, and I was able to resume forward progress. Clearly, the error message displayed by the debug player was not only non-helpful, it was actually misleading.
I thought I’d post this here in case anyone else runs into a similar problem. It may save you a few minutes of wonderment.
About 15 months ago I released the initial version of CheckBoxGroup, and I was very happy to see that a number of people found it useful. However, like most developers, I can’t stay happy with my creations for very long; I always seem to think of things that I could do to extend and/or improve them. So it is with the CheckBoxGroup: although it was a decent and useful control as it was, I really wanted to make it better. (If you’re not familiar with what the CheckBoxGroup does, take a quick look at the original post.)
The primary issue that I wanted to address was that it could not be implemented in MXML; the only way to instantiate it was in ActionScript. This was not ideal, especially considering that there are many developers who prefer to work as much as possible in MXML. So the biggest change for version 2 is that it can be instantiated with an MXML tag.
Of course, in order for a class to be instantiated in MXML it must be a subclass of UIComponent. The Adobe engineers got around this with RadioButtonGroup, as I understand it, by tweaking the compiler so that it made an exception for that particular control. I am not interested in messing with the compiler, so I made CheckBoxGroup a subclass of UIComponent. This may be unfortunate, since it’s not a visible control, but I do not think it is a major issue. First, I don’t foresee any application having so many instances of the control that the additional resources used will be significant. Second, I set visible and includeInLayout to false so that it doesn’t interfere with the appearance of the UI.
In the process of making it MXML-ready, I also created some public properties and methods that make the control more dynamic and flexible. For example, you can now specify the master, subordinate, and other/none-of-the-above checkboxes at any time after instantiation. Of course, you can still pass them to the constructor as you did in version one; this version is fully backward-compatible.
Another new property that I think is very useful is selectedItems. As you would expect, it holds an array of the checkboxes in the group that are selected.
Two useful new methods are addSubordinate() and removeSubordinate(). Just like the names sound, these allow you to add and remove individual subordinate checkboxes at any time.
One caveat: Unlike version 1, this new version has not yet been implemented in a production application. So exercise due diligence. And please - let me know if you find any bugs or have any suggestions for improvement.
Click here or on the image above to see a small sample application that demonstrates how the CheckBoxGroup works. You can right-click on the application or click here to view and download the source code.
The demo application shows three different implementation styles, one ActionScript and two MXML. As far as I can see, which one you choose is purely a matter of personal taste. The demo has a fourth screen that lets you see how the CheckBoxGroup instance behaves as you add and remove individual CheckBoxes.
Enjoy - and again, contact me with any feedback.
I haven’t done one of these in years.
My employer’s website needed some sprucing up, so he asked me to put together a simple promotional animation for the home page. It had been a long time since I designed one of these, but I did it, and you can see it at rothburysoftware.com.
Surprisingly, it was fun - so much fun, in fact, that I’m thinking about making one for my own site. So, what do you think? What sort of elements would be appropriate in a Flash animation on a Flex developer’s site?
Credits:
I did not create the icons used in the animation, so let me give credit where credit is due.
Similarly, I did not create the Camaro graphic used on this post. I got it from cemagraphics
Following my friend Jason The Saj’s good suggestion, I’ve installed the WPTouch plugin, so those of you who use the iPhone or iPod touch should now have a better experience here. Unfortunately, I don’t have either, so I can’t test it. 
That being the case, I will enlist your aid: please let me know how it looks to you, and give me whatever feedback you think might be helpful. Feel free to either add your comments to this post or contact me directly.
Enjoy!
In August, I posted a simple application that shows how the Flex 3 AdvancedDataGrid handles XML data. What I did not discuss in the accompanying blog entry is the fact that binding the XML from the server directly to a UI component is not generally the best design for a real-world application. Unless you’re building a very simple one-off application that is not likely to be significantly extended or modified, it is better to create collections of ActionScript objects to hold the data, and then bind these collections to the UI components.
This is a better design for a number of reasons. One reason is that it makes it easier to create multiple views of the same data. Another reason is that it makes the application more maintainable, because the server-facing code is isolated in specialized classes rather than being spread throughout your Flex code. And another reason is that it can make it easier to create and update data; it is often a simple matter of passing an instance of your ActionScript class to the server API.
OK, it is easy to say all that, but how do you actually do it? For starters, take a look at this sample application:
The application simply displays employee data grouped by role. The data comes from two separate server calls, one of which gets the list of roles, and the other the list of employees. The data from each call is stored in an ArrayCollection of custom ActionScript objects which I call Value Objects, or VOs, but are sometimes called Data Transfer Objects, or DTOs. Having these two collections of objects representing my data gives me a great deal of flexibility in the UI; I could do a lot of interesting things with data stored in this way. In order to show the data in the AdvancedDataGrid, I put it into a HierarchicalData instance, which is bound to the control.
That’s a lot to follow, so let’s take a step back and look at some of the code. We’ll start in the result() method of the RoleProxy class. This is where the XML data is used to create a collection of RoleVO instances:
role = new RoleVO(xml.@id, xml.@name);
Here the server values for the id and name of each role are passed to the RoleVO constructor in order to create an instance with those values. As you would expect, the RoleVO constructor assigns these values to the instance properties.
Another way of accomplishing essentially the same thing can be seen in the result() method of the EmployeeProxy class. Here, the entire XML element representing an employee is passed to the EmployeeVO constructor:
employee = new EmployeeVO(xml);
If you take a look at the EmployeeVO constructor, you will see that it assigns the values of the XML attributes and child elements to the EmployeeVO instance properties.
OK, now that we have our two collections of value objects, we are ready to do something useful with them. For an example of how to do this, let’s move from the model to the view.
In the view component we can manipulate the data as needed in order to present the visualization desired. In this case, we want to display the data hierarchically, with employees as children of their respective roles. In order to accomplish this we loop over our collections to create a single ArrayCollection of dynamic objects that hold arrays of EmployeeVO instances and are identified by the corresponding roles. This is done in the onInitialDataLoad() method of AdvancedDataGridXMLVO. In the following snippet, roles is the collection of RoleVO objects, empys is the collection of EmployeeVO instances, and ac is the new ArrayCollection instance that we’re building from the two:
// Loop over the collections and build dynamic objects
for(var i:int = 0; i < roles.length; i++)
{
// One object per Role
obj = new Object;
obj.role = roles.getItemAt(i).roleName;
obj.roleId = roles.getItemAt(i).id;
// An array of Employees for each role
arr = [];
// Loop over the Employee collection
for(var j:int = 0; j < empys.length; j++)
{
// Check the employee’s role ID
if(empys.getItemAt(j).roleId == obj.roleId)
{
// Add the employee to our array
arr.push(empys.getItemAt(j));
}
}
// Assign the array to a property on our dynamic object
obj.employees = arr;
// Add the object to the ArrayCollection
ac.addItem(obj);
}
When we have the new ArrayCollection, we then use it to create our HierarchicalData instance:
employeeRoleData = new HierarchicalData(ac);
// Let Flex know which field represents Child objects
employeeRoleData.childrenField = “employees”;
Because employeeRoleData is bound to the dataProvider property of our AdvancedDataGrid instance, the data is displayed automagically. In other words, we’re done!
As a side point, you’ll notice that the role names span several columns in order to provide a strong visual cue to indicate how the data is arranged. I got the idea from this post by Rob Rusher.
Now that we’ve seen how the application uses collections of value objects to provide a layer of abstraction between the view and the data, let’s take a higher-level look at how the application is architected. It does not use a framework such as PureMVC or Cairngorm, but the code is organized in a way that is similar to an MVC implementation. It is sort of an intermediary step between the brittle architectures that are typical of introductory Flex tutorials, and an extensible, maintainable, enterprise-class architecture:
If you walk through this flowchart (PDF), you can begin to see how the application is fairly easy to maintain. If I want to add a new visualization of the data, I just need to build a new view component that displays the existing ArrayCollections in a different way. If I want to change the source of my data, I just need to change the Proxy classes in the model - my view components don’t need to be touched.
Also, you can begin to see how this kind of architecture lends itself to team development. For example, if you have some developers who are very good with MXML and visualizations, you can have them focus on the view components, and they don’t have to know anything about the inner workings of the model classes. Similarly, you can have other developers build out the model without ever concerning themselves with the view components. This way neither group of developers ever gets in the other group’s way.
I architected the application this way because it seems to me that there aren’t many intermediary examples out there to help you make the leap from the very simple tutorial applications to applications built with full-blown frameworks. It occurs to me that this gap makes it difficult for many developers to appreciate the value of the frameworks. So, I offer this application as a way to help full in this gap. I hope to present some modifications to this application in future posts in order to highlight other aspects of good development practices, such as code reuse and encapsulation, so stay tuned.
The ConfigService class in the Alfresco Flex SDK is responsible for getting server configuration information from an external XML file, and making that information available to other SDK classes. The class works well generally, but it does have a quirk that can really trip you up: it sets default values for the configuration variables, and these default values match the default development setup. As a result, you can have your application working like a charm on your development machine, and assume everything is functioning as designed, only to find that it fails to even start when you upload it to a server.
The reason this happens is that the application is reading the server configuration values from the ConfigService instance before it has had time to retrieve those values from the external XML file. This works fine on your development machine if you’re using the default configuration, but since the server doesn’t use the default configuration, the application fails. The solution, thankfully, is quite simple. The ConfigService class is a Singleton, and it attempts to retrieve the values from the XML file immediately after instantiation. So, all you need to do to avoid this issue is to instantiate ConfigService early enough that it gets the correct values before any other application objects need them.
Let’s look at how to do this in three different scenarios: using the PureMVC framework, the Cairngorm microarchitecture, and no framework at all. I’ll start with the latter, since it’s the simplest.
No Framework
If you’re building a simple UI where separation of concerns is not an issue, then you can simply instantiate ConfigService in the <script> block of your main Application MXML file. If you declare a member variable to hold the instance, and initialize the variable at the same time that you declare it, then your ConfigService class will be instantiated very early - and therefore it will begin retrieving the configuration data from the XML file - well before the creationComplete event is dispatched.
<mx:Script>
<![CDATA[
import org.alfresco.framework.service.webscript.ConfigService;
// Instantiate ConfigService early so the config data
// will be available to the various proxies
private var configService:ConfigService = ConfigService.instance;
]]>
</mx:Script>
PureMVC
In PureMVC applications, you would not want a direct reference to the Alfresco SDK in an MXML file, as this would create a very tight coupling between the view and the service tiers. So, instantiating the ConfigService class directly in the main Application MXML is not a good idea. However, PureMVC applications typically instantiate the ApplicationFacade in the main Application MXML’s <script> block, like so:
// ApplicationFacade instance
private var _facade:ApplicationFacade = ApplicationFacade.getInstance();
That being the case, if you instantiate the ConfigService class in the ApplicationFacade’s constructor, you will have your ConfigService instance very early indeed.
/**
* Singleton Constructor
*/
public function ApplicationFacade()
{
// Instantiate ConfigService early so the config data
// will be available to the various proxies
var configService:ConfigService = ConfigService.instance;
}
As in the no-framework example above, it will be instantiated well before your main Application MXML’s creationComplete handler is called, and will be initialized with the external XML data before your users have time to enter their usernames and passwords.
Cairngorm
With Cairngorm, you typically have a tag in your Application MXML that looks something like this:
<business:Services id=”service” />
This instantiates the Services component, and as in the examples above, this will happen before the Application’s creationComplete event is dispatched. So you can declare and initialize a member variable to hold the ConfigService instance in the <script> block of Services.mxml, and this should be early enough. (The code will look the same as the no-framework example above, so I won’t repeat it here.)
Nuff Sed
Hopefully, these examples will be sufficient to get you going in whatever framework you use. If not, feel free to contact me and I’ll do my best to help you out.
