The Goal

The goal of this article is to improve upon the code from Aral’s article with generic form handling and automatic collection of form data. This is one way of going about this problem and there are many other ways to do it which probably just as good for your use.

A secondary goal is to make the solution as simple as possible and make it really simple to use in most kinds of applications. Just having two or three lines of code to make it all work perfectly.

The Design

The design consists mainly of two interfaces called FormHelper , FormHelpEnabled and an implementation class FormHelperImpl.

The FormHelper interface extends the IEventDispatcher interface because the implementation classes needs to dispatch events notifying about changes in validation status and sending. The implementation class dispatches a FormEvent, which extends flash.events.Event, when a form is validated and all the data is collected. Listening for a FormEvent.SEND event you can retrieve a typed object containing the form data.

In order to make data collection easy the FormHelper uses a convetion in the way you name your input controls inside your Form. By having a naming convention the implementation class uses the field names in the targetClass property and looks first for a FormItem with the ID on the form <Field name in class>Field and a an input control called <Field name in class>Input. You can of course change this convention to just rely on the input control if you like.
Using this convention the implemention class of FormHelper is capable of returning a typed object with the form data. Have a look at the source code (see the link below) to learn more about the details of the implementation.

UPDATE (25.07.2008): My friend Børre Wessel pointed out something which makes a lot of sense and that was the tight coupling between the view component and the validators.  This was beyond my simple scope which was simple validation and data collection. However his point makes perfect sense and I have update the sample code with a new class VOFormHelper which extends the FormHelperImpl class by adding a mapping array which uses the field names of the configured target class as key to store a validator class.
This is all configured in the main application and removes the tight coupling between the form component and the validation logic. The same approach can be performed to format data.
Have a look at the sample source code to see how this is done.

The Sample

Here is a simple demonstration application which shows how to make use of these classes to provide your application with form validation and processing. The sample consists of two input forms and they are there to collect information about a user and some address data. Both input components implement the FormHelpEnabled interface:

public interface FormHelpEnabled {
  function set formHelper(f:FormHelper):void;
  function get formControl():Form;
}

This enables the main application to compose the input components with a FormHelper to do validation and data collection.
Using the two SASO’s (Simple ActionScript Objects) Address and User the sample just needs to setup two FormHelperImpl instances and add an event listener to retrieve the form data.

formhelper = new FormHelperImpl(FormHelpEnabled(regForm), User);
formhelper.addEventListener(FormEvent.SEND, function(fe:FormEvent):void {
  if (fe.resultObject is User) {
    var u:User = User(fe.resultObject);
    Alert.show("Form data:\n" + ObjectUtil.toString(u));
  }
});
regForm.formHelper = formhelper;
.....
<mx:TabNavigator height="350" width="600">
  <local:RegistrationForm2 id="regForm"
	label="User information"/>
  <local:RegistrationForm id="regForm2"
	label="Address information"
	creationComplete="initAddress()"/>
</mx:TabNavigator>

View the sample in new window
View the source code

The design of these classes are not necessarily what you need for you application and you are free to use the code in any way you see fit. Just let me know and I can post an update here on the blog.

Having this kind of logic seperated into Simple ActionScript Objects, SASO’s, (I’m sorry I could not resist to reuse the POJO catch phrase) which are simple to both understand and unit test. Unit testing and indeed understanding complex binding expressions or functions inline in MXML-code is hard when your application grows. Therefor making this kind of separation makes perfect sense.

In my previous posting I outlined how you could have stand alone classes for handling security. However the posting did not include a running sample as to how you would best implement the principles outlined. This posting comes with a more detailed description and a running sample with source code.

The Design

The implementation of the policy based security consists of three interfaces and an implementation class. Security policies are created in stand alone classes which are easily unit tested and gives you better control of what policies applies to performing certain operations in your applications.

The Policy interface has one method apply, which takes a criteria as parameter. Classes implementing this interface can be set on a class implementing the PolicyHandler interface.  In the policy handler class all the “magic” happens. Based on the composed criteria, policies and targets.

Ease of use is important when writing library style components and the policy handler is design with this in mind.  All you need to do in your application is to instanciate a policy handler class and then configure it with the required properties. Thanks to Flex’s data binding features the policies get applied whenever the criteria changes.

Using the policy handler

The implementation class, PolicyHanlderImpl of the PolicyHandler interface does all the heavy lifting and all you need to do is to pass it a callback function which gets called with the result of all the applied policies. In your callback method you can do make components appear/dissapear or enable/disable depending on the policy result.

public function applyToTargets(policyApplies:Boolean):void {
  componentA.visible = componentA.includeInLayout = b;
}
...
<policyHandlers:PolicyHandlerImpl id="handler"
	policies="{[AdminWidgetAccessPolicy]}"
	criteria="{currentUser}"
	callback="{applyToTargets}"
	/>

The Sample

In order to make it a bit easier to review this way of securing access to parts of your application I have created a really horrible looking sample (can’t have a security sample which looks nice, that just does not seem secure enough) which shows the design in practice.

Pressing the button in the sample makes you change the current user between user A and user B. The policy in the sample ensures that only users with the role administrator sees the admin widgets.  When looking at the source code, do not pay much attention to the lack of comments and nice coding. This is a quick and dirty sample code, not a best practice type sample.

View the sample in new window
View the source code

I appreciate all questions/comments, whether you think this is terrible or brilliant, just leave them over on the right.

UPDATE: Last night I detected an obvious flaw in my design, originally I had an abstract class which you had to extend in order to implement a new policy handler. In order to make using this design even easier I decided to have the PolicyHandler/ have a new method for setting a callback function which gets called after application of all the policies.

• a wrong perspecktive on the purpose of testing
• lack of good tool support with the correct perspecktive on testing

The purpose of testing

Most developers and test tool makers have a perspective of testing as an exercise where the object is to find defects. This is a perspective on things which led us to where we where a couple of years ago. With the introduction og eXtreme Programming and agile methods the perspective developers had on testing changed. Testing became an exercise which purpose was to prevent defects from entering your code base.

Testing as a way of preventing defects is a view shared by Lean Software Development and Mary Popendieck goes into details about this in her book Implementing Lean Software Development: From Concept To Cash. If you fail to convince your developers that this is the purpose of testing, I think you are going to fail at successfully working test driven. Testing to prevent defects is something which comes natural for interface developers as we have always been forced to continuously test our applications in numerous browsers while writing code. If this comes natural, how come test driven interface development is so hard?

The Tools

I agree with some of Dean Wampler’s points and I do think that lack of good tools might be part of the reason why test driving user interface development is hard. However I think the reason why the tool are inadequate is that they are created by people who don’t know enough or care enough about their target audience (to all of you who have written tools I apologize, but this is what it looks like from my point of view. If you are offended, just let me know and we can settle it off line). The tools for testing user interfaces tend to be intrusive, expensive and just too complicated to use.

Monster tools like Quick Test Pro are so complex (just installing this monster is a pain) that they exclude some users. Not to mention the ridiculous price tag on this software. However these things aside the tool itself is just not good enough to make it worth while for the people actually implementing the user interface. They do not want a tool where you write some code in some macro- or script language. They do not want a 3 GB tool to install with a limited number of licenses.

What they do want is a simple, free and easy tool to help them work faster and with better quality. A testing tool which not only helps in finding defects, but a tool which prevent defects from entering their code. A tool which is none intrusive and can be used while writing code.

This is where most tools get it wrong too. They are tools created to finding defects and errors in an application. Usually you record a test script and then run that script later on in order to find defects. What these kinds of tools fails to do is to give developers a way of working which prevent defects from entering their application.

One shining star

During my time as an interface developer I have only found one tool which actually allow you to work Test Driven and which enables the developer to work with preventing defects. The tool in question in is the free tool Selenium.

What makes Selenium so great is that it through it’s Selenium IDE provides developers with an actual tool which enables you to work test driven. By using the default view you can easily create simple test fixtures up front before coding and then run the test until the test passes. The Selenium IDE is a Firefox add on and hence fits naturaly into a user interface developers portfolio of tools. It’s small, portable and available on all platforms.

The way forward

I think the future for test driven interface development is very promising. Iterating and continuously testing is something which is in the blood of all experienced interface developers and I am certain that tool vendors will be capable of building tools which encourage test driven interface development.

Those of you who speak Norwegian can enjoy my blog “her er mitt arbeid” and for those of you who do not speak Norwegian you can check out the Google translation.

Why Unit-testing has “nothing” to do with testing

I do not claim to be the master of testdriven developmen, but I have used a testdrvien approach for about two years now. What I have come to realize is that, for me as a programmer, my unit-tests are not most valueable as a way of testing.
Sound stoopid, right? Hold on! Do not stop reading, theres an explaination to this somewhat bizzare statement. What I mean is that my unit-tests help me in a lot of other ways which are actulay more benefical for me as a programmer.

New approach to an old technique

A few years ago I read the first edition of “Code Complete”, which is a great book. I picked up a few tips which helped me improve my speed and accuracy while coding. One of the things was first document what the method should do before the signature, and then “code” the method by writing comments for what you want it to do. By doing this you can more easily see if what you wrote in the method body corresponds to the documentation in the header for the method. You will notice if you need to refactor you method and you can detect logic errors before writing a single line of code. I found this technique to be very useful and it helped me improve the quality of the code and I produced fewer errors in my code.

Unit-testing introduced a more extreme approach which is somewhat simular. Testdriven development evangelists says “You must write you tests first”. This is a new spin to the method mentioned in “Code Complete” by Steve McConnel. By writing the test first you can see if your component meet the requirements, and you will also be able to detect design errors early. In addition you will also write better code for the actual method since it will only meet the requirements in the unit-test.
If you are not writing your tests first, you might as well just skip writing unit-tests. They will pretty much just test that the code you wrote runs, not if your component actualy does what it is supposed to. But, this topic has pretty much been covered by other people so I will leave it at that.
To recap: writing tests first helps me trap design and requirements errors early and improves code quality.

Having the courage to implement change

Refactoring is a word that some people love, and some people think is just a word used by consultants to make money off of their mistakes. Either way, we all know that we somewhere down the line will have to change our code. Nobody writes perfect code that never needs change, that is just a fact.
When the time comes for your component to change, what do you do?
Do you start to sweat and suddenly develop a spiritual conciousness, or do you smile and see this as an opportunity to make the changes you have been dying to do for some time? If you have been a good boy or girl and written your unit-tests you will be in the latter category. This is one of the reasons why I have come to embrace unit-testing. It gives me the confidence to perform required changes. My unit-tests gives me the sound foundation to perform every required change in my application. No more prayers like, “please please let this change be a good one” to the allmight “Runtime God”.

Going fast by never going back

I have seen people estimating more hours because they are doing unit-testing. This is in my opinion dead wrong. This would be equivalent of saying “I will use the IntelliJ debugger, and that will take me 4 hours”. Writing unit-tests should be a natural part of the craft of writing code, therefor it makes no sense to add hours to a budget “because we are gonna unit-test”.
By applying unit-tests in the way I have discussed earlier you will never use mour hours by adding unit-tests. That is because you will detect errors and trap design flaws earlier when writing tests up-front. You might spend an hour our two writing the tests, but you will also spend less time debugging your component. In other word you will go fast, by writing better code that you will not have to back and debug.
Again, this is actualy nothing new. Writing tests first is just a new spin to an old software developement “truth”: you will go faster by trapping errors early.

Summary

Unit-testing has more to do with writing code than testing in a traditional way. I see unit-testing as a tool for:

• Trapping errors in code and design early
• A safetynet when improving application designs by refactoring
• Better understanding of the problem domain at an earlier stage in the development process

2008 Update

Having lived and learned a little more over the past two years I think an update is required to what I wrote back when. Testing has another very important purpose which I did not see as clearly then. Which is that tests, if written in a good way, also acts as the best possible documentation about your problem domain and application. Allistar Cockburn mentions in his excellent book Agile Software Development: The Cooperative Game something that was originally written by XXX back in YYY about how documentation of projects is really difficult and the most important things are never put on paper. The most important thing is the “mental model” of those who developed the system. Without a knowledge of that model you will have a hard time taking over an existing project or adding new features to it.

I whole heartedly agree with this point and I think one of the places the model of the developers could be exposed is in the tests. By building a decent test harness you document how you want the system to work and you in turn expose some of the things you had to do when creating the application.
One example is lets say you had a bug which made you have to change your architecture a bit. Following the practice of TDD you would first write a test for this and in the documentation for the test method you would write a small entry about what this test does. Then you would make the architectural change until the test passes. This would expose to people coming in later reading your test code what the reasons for the test and what it solved.

Besides the fact that tests help document the mental model of the developers I think I would not change much in the original article.

When you write code you are using collections of items probably without giving it much thought. This is why I think this article is great because it makes you think about how small things in something as simple as collections can have a big impact on your code. When working with Flex the small things do have a tendency to get forgotten while working with monster components like the DataGrid or by wresteling with frameworks such as Cairngorm. While we get caught up in all the hassel with these larger parts of Flex the small things tends to be forgotten and as a result we get more problems. I’d like to thank Mr Eckel for writing this article and reminding me that the little things do actually count and now I can not wait to get started on one of the latest books I purchased: Beautiful Code.

Reducing waste and polling information

One important aspect of Lean Software Development is reducing waste and I think that reducing waste in project communication is very important. By removing the need for a lot of manual communication about server status or events occurring in the different development environments you remove a lot of waste. Another principle is that you should poll information when you need it instead of pushing it onto people. By using IRC you enable developers to poll information when they are actually developing by allowing them to connect to IRC when they are actually developing or giving them access to IRC logs if they need to see what went on while they where in a meeting. If you where to use IM software for this you would push information and it will feel a lot more intrusive for developers.

Installing IRCcat

1. Download a Java JDK 1.5 or later, and point JAVA_HOME to this directory
2. Download Ant and make it available in your PATH
3. Download IRCcat
4. Download the attached configuration file
5. Run the command: ant -Dirccat-howto.xml run
6. Viola! You should now see something similar to this:

Uhm, so what did I just do? Well, IRCcat is a service which basically dispatches commands to an IRC server. You can “talk” to IRCcat and then have it communicate to the IRC channel and all it’s listeners. This samples uses the IRCnet IRC network and connects to the channel #TWA-IRCcat-howto. Now connect to an IRCnet server with a regular IRC client (mIRC, Pidgin, etc) and join the channel #TWA-IRCcat-howto. In this channel there should be a bot called TWAcat.

What we now need to do is to send some messages using IRCcat. Doing this is most easily done by downloading a tool called netcat (more on netcat at Wikipedia) available on Unix and Windows. Unfortunately some virus protection software thinks netcat is a dangerous program and will prevent you from executing it, so you might have to stop any such applications when trying this out.

Having downloaded netcat and added it to your path you can now write the following command:
echo Hola el Mundo|nc -w1 localhost 9999

In your IRC client you should now see TWAcat say: “Hola el mundo”

Where to go from here?

What is cool about IRCcat is that it is very easy to write your own piece of code which reports statuses, errors, etc to your development team. This is really cool and I’m very much looking forward to see how this works out. Keep a lookout for upgrades by reading the journal on Last F.M and let me know if you have any problems with this sample.

“Taking people seriously costs too much”

The program interviews author of “The machine that changed the world: The story of Lean production” James P. Womack of the Lean Enterprise Institute who explains easily how for instance Home Depot and Wall Mart have disconnected themselves from customers by either off shoring customer services or using temporary unskilled workers instead of full time employees with actual. He goes on to explain how businesses who say “taking people seriously costs too much” are totally missing the point. I will not repeat everything he said, but instead encourage you to listen to the program (see details about this at the end of this post).

Lean customer service

One of the more surprising places that Lean has been applied is in call centers and the program shows how the Northern Ireland call center company gem have grown their business by applying Lean principles to customer service. By treating customers as actual human beings as opposed to treating them as numbers in a queue. Gem employees and executives are all measured on customer satisfaction and not how. They provide value to their clients by providing a feedback loop back letting them know how they can improve their business. Gem work with their clients

Steven Perry (I apologize if I spelled this wrong) of Transform also explains how they where hired by the government of Northern Ireland to try prevent jobs being off-shored and making their works important. By applying Lean principles to call-center companies in Northern Ireland they are securing jobs and making companies grow. One amazing example is a call-center handling technical support for an airlines company which keeps getting complaints about the email system not working properly. When contacting the CEO of the company the call-center got a reply that it was too expensive to upgrade the email system and that people would had to live with a few quirks in the email system. The call-center company then looked at the emails and discovered that the emails contained shift rosters, lists of passengers transferring from the airline to other airline and details about parts not arriving on time. When providing these root causes to the CEO it was an obvious decision to upgrade the email system.
The program also outlines how Lean principles when applied provides great value to companies providing services and how they transform themselves into management consulting companies and not just simple service companies.

Lean banking?

GE Money Bank measures customer satisfaction by using a simple survey with 5-6 customers and are not linked to change, growth or volume. Instead they measure customer satisfaction using net promoter score, which means asking customers, “would you recommend us/our product to your friends?”

Linking this to the Lean philosophy GE Moneybank sees an answer of “yes, I would recommend your product” as a much better indication for future growth. Their business executives are all measured and paid according to these scores and this enables them to execute their business based on Lean principles and by doing this making billions of dollars.

Lean in the software industry

1) Lean does not only apply to companies manufacturing products

2) Lean is gaining momentum in most areas of business and will become the standard way of doing business also in the software industry.

The software industry have started on it’s path towards Lean by starting to apply agile principles to software development. But in order to make the industry more mature and help customers get better value for their investments in information technology I am certain that our industry too needs to apply these principles in order to everyone in the entire business to focus upon the customer. Agile only does this for a certain part of an organization whereas Lean has principles which more easily transcends into the management sphere because of it’s roots in the Toyota Manufacturing System.

Iterate “leaning” the way in Norway

(I sincerely apologize for the tabloid heading of this section, but I just could not resist the temptation and again I am sorry) Lean has not become very relevant in Norway yet and we are still getting used to the idea of applying Scrum and agile methods. However there is a Norwegian consulting company called Iterate who both apply Lean to their clients, but also follow the same Lean principles to the way they run their own business. When talking with them you learn how Lean also can be applied to a company which makes money by billing hours.

I had the pleasure of being in contact with Iterate and it really is quite fascinating to learn how they apply Lean to a consulting company. By focusing internally on making sure their employees are treated as the knowledge workers they are and not cash-cows and by doing this providing their customers with excellent services by applying the same principles. They do not have what I call the “Accenture focus”, which means focusing upon getting the most number of hours squeezed out of any client, but instead treat the customer the same way as their own employees. Just like with call centers in Northern Ireland, Iterate of Norway applies Lean principles in the the service industry and they both do it with success.

How to listen to the program

Download the program or subscribe to the Podcast and look for the program called Lean, Mean and at Your Service: 29th April 08.

I started off writing some technical documentation and found the word processor to do the job. I could insert images and format lists which is basically all I would do for any document. What is missing is more short cut keys and some other minor things, but all in all I thought the service was cool. I haven’t gotten the chance to try the collaboration features yet, which really is one of the coolest features in Google Doc’s.

Anyway, while I was writing my document I had to spend some quality time catching up on my RSS feeds. When I went back to Buzzword it had a really nice surprise for me which really shows how one simple design on a feature shows that a company “gets it”. What usually is an annoying feature that you don’t want to see was transformed into something cute and unexpected. Just look at the screenshot below, there is no way you can be angry for having to log back in when you get prompted this image.

As we continued growing our application I could not help to notice that there really was a few things about the framework that really started to degrade the quality of our code base and really made our application harder to maintain.

Boilerplate code

Writing a Cairngorm application involves a lot of boilerplate code. In order to get just a simple command going you need to create 2/3 new classes and write 20/30 lines of code which provides no value what so ever.
I really feel the Cairngorm framework should try and encapsulate more of the inner workings and hence saving developers a lot of time and effort. When designing a framework I feel you should have the approach the guys developing Spring Framework for Java has: to make development simpler. Cairngorm does not make development simpler and as your application grows Cairngorm really starts to slow you down.

More code, more problems

Numerous studies has shown that the more lines of code you have in your application, the higher is the potential for bugs. Therefor it would be beneficial for an application framework such as Cairngorm to let developers write less code. In my experience Cairngorm does quite the oposite. I have compared an application created using Cairngorm to the same application written from scratch with a custom architecture and Cairngorm adds numerous classes and several hundred lines of code (I’ll provide samples of this later on).

Feels like EJB 2.0

When I work with Cairngorm I get the same feeling as I did back when I had to work with EJB 2.0. It feels like a plastic bag that’s constantly over your head while you try do develop your application. The framework is intrusive and continues to force you to write tons of useless code and transforms all applications intro dinosaurs that become hard to maintain and really hard for new people to learn. Regardless of all the patterns used in Cairngorm, it is not easy for new developers to start developing when they have to related to such a huge number of classes.

MVC is probably not what you need

In my experience most applications don’t need to implement the Model Control View pattern in order to provide a decent application architecture. Especially I feel this is the case for Flex, you really don’t want to mimic a Java web application when you have such a great framework as Flex!

A plead to Adobe Consulting

Listen Adobe Consulting, either you try and upgrade your framework to something that fulfills the demands of developers in 2008 or you release it as Open Source. Right now all the new things in Caringorm are related to their ridiculously expensive Live Cycle Data Service, nothing in regards to making development faster and easier. If you don’t have the time or resources to do this, release it and maybe the community can help out (I am fully aware that I should put my money where my mouth is and develop my own framework, but this is not something I have time to do right now).

Here is what you should do

Having put down the Cairngorm framework I guess you want to know what to do? OK, I’ll try and elaborate some of my thought on how you best construct and application architecture in Flex.

Model Locator & Business Delegate

There are two valuable things in Cairngorm which I would continue to use (but I would probably just develop those classes my self for each project):

• Model Locator
• Business Delegate

All the command, event, front controller mumbo jumbo is just there for the pattern horny architects who does no actual coding and have a need to have as many patterns as possible in every application architecture the work on.
Now here is why I feel these things make sense for almost any project. The Model Locator pattern, as Adobe calls it, is a great way to control data in your application. Combining the Model Locator with the built in feature of data binding in Flex that is a really powerful combo. If you combine this with a Business Delegate class you have pretty much all you need (you may not actually need that class either, it is not very hard to write one on your own).

Why settle for just one model?

If you decide to throw out most of Cairngorm and write your own architecture I would advice you to use two types of Models: Presentations Model and Server Models.
Having a one-to-one relation between the server side services and Server Models provides you with a seperation between server side data and the presentation data. Server Models should be responsible for retrieving their own data (that’s right, no events/commands needed). Presentation Models can use one or more Server Models, and once again using data binding to control updates. I think this provides a really simple, but yet very scalable, application architecture.

Update

I am terribly sorry about the mistake of not remembering that Cairngorm is Open Source. Since I wrote this I have been notified about some other articles dealing with the same issue and I think the best one yet is an article called Using Cairngorm & Thoughts On Handling Those Pesky Singletons

.