Uses for non-visual Flex components
Brian LeGros | December 13th, 2007 | programmingRecently, I've been interested in examining the features of non-visual components as it applies to Flex. I don't hear them talked about a lot (at least in the small part of the blog-o-sphere that I read), but I think there are some uses for these types of components that could really catch on in the community. I've tried to put together a sample application to show an example of some of the ideas I'm playing with in my head.
So the big place where I see non-visual components having a use is when attempting to bridge the stateless and stateful portions of a Flex application, mainly in the area of remote services. When I design a web service or remote object to be used by Flex, I typically build it in Java (or ColdFusion) and I design the service such that its methods operate in a stateless fashion. For example, when I call a method on my service, I don't expect previous calls to that method to influence the results of my current call; at least from the perspective of the caller. Additionally, I have the expectation that more information may be required when calling the method since the remote object receiving the call has no context in which to interpret the method call besides the method itself. Now I'm know an argument can be made about whether something truly is stateless or not, but that's not the goal of this post. Let's work with this ad hoc definition of stateless for now.
Flex provides us with a very simple, global means to get a hold of these services: RemoteObject, WebService, HttpService; there are other means by which to connect to remote services, but for now let's take the simple example of stateless RPC-based services. Typically in my Flex applications, I want to emulate a synchronous call from the application to the service (using something that implements IResponder or mapping the result/fault methods manually). Ideally I should have a class abstracting these calls to improve cohesion in the application; frameworks like to use command, delegate, or proxy classes, for example. During the emulation of this synchronous call I usually have my result/fault handler call out to a method on a class to change the state of an object (e.g. - setting values on the ModelLocator in Cairngorm), consequently firing propertyChanged events and/or custom events to update visual components via data binding.
All that being said, there are a couple of things with this approach that I want to address. First, I'm making the assumption that the class which abstracts the interactions with my service should also remain stateless. No where in the creation of the object am I changing its state so that the behaviors associated with the object may have a different context when executed. Second, I'm making the assumption that the behavior of this abstracting class must be separate from the data it uses. Propagating a change in an object's state via events is the back-bone of Flex data-binding. Not only that, but data binding is very simple to use and code, why shouldn't this simplicity be available in the ActionScript class abstracting the call to the remote service?
So that's enough conceptualizing for now, let's look at some example code. Please note the entire working example can be found at this location.
In this example, we have a very simple phone directory application. A SearchView exists which takes input from the user and announces a custom event (SearchEvent) passing that user input as its payload (i.e. - SearchCriteria). This event is handled by the Application class which in turn calls the find() method on an instance of SearchComponent. SearchComponent is a non-visual component which uses data-binding to propagate changes from the stateless world into my stateful Flex application. The code for SearchComoponent can be found below:
-
package com.brianlegros.nvc_example.component
-
{
-
import flash.xml.XMLDocument;
-
import mx.collections.XMLListCollection;
-
import mx.collections.ListCollectionView;
-
import mx.collections.IList;
-
import mx.collections.ArrayCollection;
-
import flash.net.URLRequest;
-
import flash.net.URLLoader;
-
-
import com.brianlegros.nvc_example.vo.Employee;
-
import com.brianlegros.nvc_example.vo.SearchCriteria;
-
-
public class SearchComponent
-
{
-
[Bindable]
-
public var locations : IList;
-
-
[Bindable]
-
public var departments : IList;
-
-
[Bindable]
-
public var employees : IList;
-
-
private var data : XML;
-
-
public function SearchComponent() : void
-
{
-
var request : URLRequest = new URLRequest("results.xml");
-
var loader : URLLoader = new URLLoader(request);
-
loader.addEventListener(Event.COMPLETE, function() : void
-
{
-
data = XML(loader.data);
-
-
locations = findLocations();
-
-
departments = findDepartments();
-
}
-
);
-
-
this.employees = new ArrayCollection();
-
}
-
-
private function findLocations() : ArrayCollection
-
{
-
var temp : ArrayCollection = new ArrayCollection();
-
-
for each(var item : XML in this.data.employee.location)
-
{
-
if(!temp.contains(item.toString()))
-
{
-
temp.addItem(item.toString());
-
}
-
}
-
-
return temp;
-
}
-
-
private function findDepartments() : ArrayCollection
-
{
-
var temp : ArrayCollection = new ArrayCollection();
-
-
for each(var item : XML in this.data.employee.department)
-
{
-
if(!temp.contains(item.toString()))
-
{
-
temp.addItem(item.toString());
-
}
-
}
-
-
return temp;
-
}
-
-
-
public function find(criteria : SearchCriteria) : void
-
{
-
var temp : ArrayCollection = new ArrayCollection();
-
-
for each(var item : XML in this.data.employee)
-
{
-
if(criteria.firstName.toUpperCase() == item.firstName.toString().toUpperCase()
-
|| criteria.lastName.toUpperCase() == item.lastName.toString().toUpperCase()
-
|| criteria.nickName.toUpperCase() == item.nickName.toString().toUpperCase()
-
|| criteria.location == item.location
-
|| criteria.department == item.department)
-
{
-
var employee : Employee = new Employee();
-
employee.firstName = item.firstName.toString();
-
employee.lastName = item.lastName.toString();
-
employee.nickName = item.nickName.toString();
-
employee.location = item.location.toString();
-
employee.department = item.department.toString();
-
employee.phone = item.phone.toString();
-
-
temp.addItem(employee);
-
}
-
}
-
-
this.employees = temp;
-
}
-
}
-
}
There a few things to note about this component for the purpose of this example:
- A method on a remote service/object is not actually being called, I'm using an XML document to simulate that process.
- I am not actually emulating a synchronous call, I'm allowing the current thread to block on the method call. If I were to emulate the synchronous call, I would suggest using anonymous functions as the result and fault handlers for the remote service/object. The code in this example would be short and not warrant a named method mapping (this is done a lot in JavaScript when registering event handlers).
- Yes, my coding style kinda sucks, get over it.
Now when the find() method is called it does not return anything, instead it updates the component's internal state via the employees property which then fires a propertyChanged event which is handled by ResultsView to populate a datagrid. Additionally, notice that when the object is constructed it makes a call to fetch location and department information to which controls in the SearchView are bound and updated when construction is complete. These values from these controls are used to filter the search performed by the user.
Going back to the conceptual, there are a few questions that come to mind:
- Aren't components supposed to be reusable? - From my POV, it feels like Flex has already done a great job of handling re-use through the RemoteObject, HttpService, and WebService classes. It seems that if re-usability is needed it would be at the service rather than the non-visual component. The non-visual component in my example is literally acting as a perspective for its service, or what potentially could be a group of services. Right now, however, I'm not sure if there are huge performance issues that may result from having multiple component perspectives for a single or series of services. I would assume for RemoteObject it may not be as big as a hit as it would be for a web service. Maybe this would be based on the remoting implementation you choose (i.e. - LCDS, BlazeDS, WebORB, Granite Data Services, etc).
- Aren't you just causing side-effects on objects? - In my opinion, it's not doing anything different than what Flex is doing with its visual components. In fact, what I think justifies this particular approach is the fact that you have the ability to notify anyone watching the object when its state has changed; I've always considered side effects as changes in state that I potentially didn't know about as the caller. The Flash movie instance is stateful; why not take advantage of this environment to add state to the classes abstracting our services? I'm building these non-visual components to satisfy the needs of my application, so I will know how they should behave and can to document that formally based on the constructs of the language. Now, if you ask me if this approach should be used for building an API-like interface to a set of remote services, then I would have to say no. The implementer of an API doesn't know how their code will be used in the context of an application, consequently keeping these components as stateless as possible is to the benefit of the API developer; context is limited to the execution of a method call. I think the Twitter API for Flash Developers is a great example of this.
- Where do I put all of these non-visual components? - This question I believe involves much more conversation about the implementation of these non-visual components. The example application is extremely simple and does not represent the issue of how to handle event propagation. In the example, all events are being propagated to the
Applicationclass and emulating a sort of global event system similar to those that I've seen in Flex frameworks with which I've worked. In fact, this is how easyMVC handles its event registration in theControllerFactory; aControllerEventwith a user provided type is registered on theApplicationand no matter where the event is dispatched, it's told to bubble to theApplicationto be handled by a mapped method in a customControllerclass. I have to admit that I like this approach much better than Cairngorm and PureMVC's approach of building their own global event system. I know both camps have their own reasoning for why they've done it, but I don't think that what Adobe has provided is worth re-writing. On the other hand, does the hierarchical nature of MXML bind visual component layout and construction too close such that without global event systems we can't be productive as Flex developers? On a side note, data binding in practice isn't always the answer to our problems; how a component can take advantage of these non-visual components and still interact with the components it needs to is a mystery to me. This may come back to the nature of MXML as well. - Do I need a framework if I use this approach? - This is something I'm still trying to figure out. The biggest use of Flex frameworks I've found is a structured approach for making calls to remote services. I feel like frameworks have way too much boiler plate code and if this approach is practical, a good alternative may exist in place of adopting a framework. It seems to me like Flex frameworks have come from the mindset of the web world where stateless HTTP is king. We don't have to use the Front Page Controller pattern to build rich UI's; I think it's time to move on to different interpretations of the MVC pattern. I always find myself asking, did developers in the Java Swing world find themselves turning to a framework or were the constructs of Swing enough to be productive. If people were productive with Swing and it was a widget toolkit for AWT, why can't the same be true for Flex and Flash?
All this being said, this is just my latest idea. As you can tell, I still have a lot of unanswered questions. We are the process of implementing this approach on a much larger scale at work and hoping to solve the questions listed above. I'm always interested in feedback, so please rip this to shreds. I am far from experienced in this arena and am always open to what others have to say despite what some may think.
NOTE: For those who are interested, I began along this line of thinking based of the latest buzz-worthy topics in the programming community. It interested me as to how OSGI implemented their component architecture in Java w/o some language level support (e.g. - formal properties) and why it so popular. I was also intrigued by a proposal put together by Joe Noxel, from the Java Posse, regarding additions to Java for some of the language level elements already present in Flex. Additionally, SOA has come into debate by some of the more experienced professionals in software engineering and SCA (see Apache Tuscany as an example) has been identified as a potentially better alternative. So all this talk, combined with the little amount of component programming I've done with COM+ and .NET, made me wonder. If there is such a huge draw towards component-oriented design is there anything in Flex that we can do to take advantage of these practices? Does having formal properties and support for events as it presents itself in Flex aid developers with the tools necessary to utilize component-oriented design? Is one of those areas specifically the perspective of bridging the gap from the stateful component to the stateless service? Now I know a component has a much richer definition than I'm limiting it to, but this is just the point. To what extent can we, and should we, use components within Flex?