BDoc helps you keep documentation and code in synch
22.10.08Filed Under: work with 0 Comments
My friend Per Otto Bergum Christensen has created a great too for agile software developers called BDoc. The purpose of the tool is to generate documentation from your unit test code which is linked to requirements in your user stories. This is one of the reoccurring problems I have experienced in agile projects and BDoc is a step in the right direction.
BDoc generates documentation from the test code in a natural language which anyone can read, with a link to the user story. This enables the customer or other non-technical personnel to see whether the requirements in the user stories are fulfilled or whether there are still some pieces missing. This solves one of the issues frequently encountered in agile software projects with user stories becoming outdated and out of sync with what developers are creating.
There is a great article up on The Server Side which gives a great overview of how BDoc works. If you understand Norwegian you can see his talk about BDoc at the agile conference Smidig 2008 in Oslo, Norway.
Sexier Software with Java and Flex
11.09.08Filed Under: Flex with 0 Comments
Java and Flex specialist James Ward is coming to Oslo and the Flash User Group Norway for a special session on September 18th. This is a great chance for a one-on-one chat with one of the top experts on the planet when it comes to Flex and Java.
The session is an informal gathering and a great oportunity to have all your questions answered by a real life RIA Cowboy:
September 18th, 18:00
Peppes Pizza, Stortingsgaten
JSF Flex Project – april fools comes late this year
09.09.08Filed Under: Flex with 4 Comments
It was in amazement that I read about the The JSF Flex Project on TheServerSide . I thought that this was someones idea of a bad joke, sadly it wasn’t. The author claims the project is for “developers who are unfamiliar with Adobe Flex can be completely abstracted from its technology and focus in linking the application’s data to legacy information”.
Hold up just a god damn minute here. First of all JSF probably is the framework with the highest learning curve I have ever laid my hands on. Because it is based ideas from all the horrible UI frameworks (AWT, Swing, etc) it is of course over engineered, utterly complex and not very well suited for UI development . The only reason people use JSF is because software vendors (IBM, Sun, BEA, etc) keeps showing it down their throat.
Secondly Flex is dead simple. If you are not able to learn to create a Flex application in one week you should probably change profession. I have personally experienced this with several Java developers who have learned Flex in one week without any prior knowledge of Flex or UI programming.
Anyone with their brain plugged in when reading about a framework and see the phrase “completely abstracted from its technology” know that it is absolute nonsense. If you think for one second that you can write Java code and not have a need to understand the technology it abstracts you should, once again, change your profession. If you actualy belive the above statement you should read Joel Spolsky’s article The Law Of Leaky Abstraction.
What is depressing is that the people behind the JSF Flex Project probably have spent time on this utterly stoopid project. I am sorry that you have wasted time on this and I am sorry that I have to tell you that you have wasted your time.
Handling the view in Cairngorm with Presentation Model
03.09.08Filed Under: Flex with 0 Comments
Alot has happened since my rant about Cairngorm. My friend Børre Wessel has always told me to use a presentation model when working with Cairngormas a way to better separate the view from the model. So I have tried this approach a few times now on some small projects, and I have to agree that it really is a good way to sort out this issue.
Børre and I are of course not the only ones doing this. Paul Williams put up a simple example on how to use a presentation model, but yesterday I found an even better article outlining how to use the same pattern with Cairngorm.
David Deraed has a post Cairngorm and Presentation Model Part 2: sample application on his blog Flex May Day which gives a step by step guide with source code on how to implement the Presentation Model pattern with Cairngorm. When reading the article make sure you read the comments too as they point out a few important aspects about the code sample. You might also want to read part 1 of the article to get some background.
Using the Presentation Model pattern is in my opinion the best way of resolving separation between model classes and the view.
Simplifying form validation and processing in Flex
23.07.08Filed Under: Flex with 0 Comments
One of the most common tasks you perform when writing an application is code related to validating user input and collecting user input. This is also the case for applications written in Flex and having a simple way of doing this would save both time and money. In my new job working for Open AdExchange I looking at possible solutions to this very common task. Adobe has an article by Aral Balkan called Handling Data which covers basic validation of a form in Flex. This example serves as a good sample of simple validation, but it is not perfect and it does not cover collection of the form data.
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.
Policy based security in Flex – part II
10.07.08Filed Under: Flex with 3 Comments
Since writing my first article about Implementing Policy Based Security In Action Script 3 I have had the opportunity to create a live demo with source code available for viewing/downloading. This is to give you a better notion of how implementing policy based security for user interface components can make sense. No more of those monster data binding expressions which determine whether a user has access or not.
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.
In order to view this sample you must install the Adobe Flash Player.
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.