Christophe Herreman

I've been working on a project lately that uses Flex, AMFPHP, Propel and MySQL. For most of you these technologies may be well known, except maybe for Propel. In this post, I'll briefly mention what Propel is, what it does and how you can hack the AMFPHP Deserializer to make maximum use of Propel.

Propel

From the Propel project website: Propel is an Object Relational Mapping (ORM) framework for PHP5. It allows you to access your database using a set of objects, providing a simple API for storing and retrieving data.

Propel allows you, the web application developer, to work with databases in the same way you work with other classes and objects in PHP.

* You don't have to worry about database connections or writing SQL -- unless you want to.
* You never have to worry about escaping data or type-casting results.
* You define your database in a simple XML format (or tell Propel to build it from an existing database) and Propel will create database initialization files for your database and will generate static classes and objects that provide an OO interface to your database. (It can generate other useful things based on the datamodel too!)
* Propel builds classes which are aware of the structure of your database so there's no performance lost to initialization or to on-the-fly database metadata queries.

Most of you will agree that writing database queries and access code is one of the most tedious jobs in application development. Propel does an extremely good job at simplifying this work for the reasons mentioned above.

Mapping objects

The classes built by Propel use explicit getters and setters. That means they have methods like "setMyProperty" and "getMyProperty" to modify and access their fields. In addition to that, collections are an exception to that rule because they don't define a setter method. Instead, they define a method like "addMyItem" to fill the collection called "myItems".

The setter methods don't just set a property. They also contain logic that will mark a property as modified so that queries can be optimized.

The first step in setting up automatic mapping of the client and server objects, is to create Data Transfer Objects (DTO's, also known as Value Objects or VO's - although I prefer DTO after reading Eric Evans' DDD book.) that have the same property names as the protected properties in the PHP classes generated by Propel. To simplify the server objects, we changed the protected scope to public since it then allows us to send these to the client.

So what we have so far is a bunch of classes on the server and a bunch of classes on the client. Sending an object from server to client will allow mapping at this moment since we changed the protected scope of the properties to a public scope. Also note that you need to instruct AMFPHP about the type of the class by defining it in every object you want to map:

Mapping objects from client to server

Mapping objects from client to server is actually not that easy. After all, when we send a property from the client, say "myProperty", the AMFDeserializer inside AMFPHP will try to set a property called "myProperty" on the mapped server object. This would actually work, but the queries would fail to execute correctly since they will not see any properties as being modified. That's why we need to call the setter method "setMyProperty" instead, which will mark the property as modified.

In order to invoke the setters (and "add*" methods of the collections) we changed the AMFDeserializer class so it tries to invoke setters dynamically. Let's jump right into the code.

The above code tries to match the name of the setters by looking at the name of the properties inside the object being send. If it finds a setter method, it will invoke it and pass in the property as a value. The code will also try to detect a collection and invoke the "add*" method instead of a setter. There's also a "isNew" property to instruct the classes whether to do an update or an insert query when the save method is invoked on an object.

This hack brought me to the idea that AMFPHP should maybe provide a pluggable architecture for the serializers and deserializers. Instead of going into the code and modifying it to suit your needs, you could then register a custom (de)serializer in the config which will be used. Upgrading to newer versions of AMFPHP would then be less of a pain.

Anyway, hope you find this useful. Have fun coding!

Mathis was born on March 21, 2008 at 12.45h. Mom and baby are doing very well. Thomas is excited with his baby brother and I'm a proud dad.

We often run into a scenario at work where we have to create an object from xml. More specifically we are parsing xml files with exercise (or assessment item) data to a concrete exercise type like a MultipleChoice, FillGaps, HotSpot, etc. The thing is that we are supporting several xml dialects for the same type of exercise and we end up with a lot of parsers. On top of that we also need to be able to decide on a per project basis what xml dialects are supported (a customer may only be allowed to use dialext X for exercise Y). In the next lines I will try to explain the way we manage and configure the objects that are involved in this process.

The basic idea is that we create a factory, let's call it ExerciseFactory, and define a createFromXML() method on it that takes an xml object as its input and "creates" a concrete exercise as its output. The factory is basically an xml parser. It works as follows:

Exercise is the base class for all exercise types like MultipleChoice, FillGaps, etc. The given xml object will be in a format that corresponds to such a concrete type. The factory however needs to know what the given xml is and what concrete exercise type it should return. The easiest way to handle these different xml dialects is with a switch on some property of the xml data. This results in code similar to this (in the ExerciseFactory class):

Although this works, it is certainly bad design since it is code that is hard to maintain and manage. If we need to add or remove some parsers, we have to modify this code which is buried deep inside some package hierarchy. We can't change this behavior at runtime since the parsers are hardcoded into the switch/case.

We could solve this with a mapping configured inside the ExerciseFactory. As its key, it contains the value of the property in the xml data we did the switch on. As its value it contains the class or an instance of the parser. This results in something like the following:

Ok this seems better, but we can't configure the parsers externally since they are coded in the contructor. Let's externalize this by passing in the map to the constructor and additionally create a method for adding a parser.

This is a neat implementation. We're setting a behavior or strategy for the parser in the factory at runtime, based on some configuration. But it has a drawback: the name of the property (xml.someProperty) in the xml data we use as a key in our map always needs to be the same for the different xml dialects. Unfortunately, we can't really control this because a new dialect might be used one day that does not contain the property.

To solve this, let's add another method to our parsers: canCreate(xml:XML):Boolean. As a parameter, it takes the xml data and then checks if it can parse the data by looking into the xml structure. Finally, it returns a boolean indicating whether or not the xml can be parsed. This way, the parser decides for itself what portions of the xml data to check instead of just the one property mentioned earlier.

To force this behavior upon the parsers, we can create an interface, IExerciseParser, and then let every parser implement it:

We can now change the implementation of the ExerciseParser. We will remove the map because we will no longer be checking on a key to get a parser, but the parsers will check for themselves.

... and configure our exercise factory before using it:

What we have achieved now is that we can add new parsers that support new xml dialects without the need to alter the code of the ExerciseFactory. All we need to is create a new parser, let it implement the IExerciseParser interface and it to the ExerciseFactory.

Additionaly, configuring the ExerciseFactory in a Prana application context is a piece of cake:

Hope you enjoyed this. Don't hesitate to leave questions or comments. Have fun coding!

I have been thinking about some of the concepts and patterns described in the Domain-Driven Design book and how they could be implemented in a Flex or AIR environment.

One thing that interests me in particular is the use of a Repository as a container for Domain Objects. In short, a Repository is responsible for fetching, persisting and manipulating objects. Its intent is to shield the client from the implementation details of the data storage or the remote services that are used to get and manipulate objects.

However, there seems to be a fundamental problem in creating an ActionScript implementation. Since remote services are handled asynchronously, it is impossible to create a Repository as it is originally described by Eric Evans.

Here's a snippet of a post (by myself) on the DDD list:

Would it be correct to assume that repositories don't make much sense if you are dealing with async remote calls? Or should I say that async data fetching is a problem currently not addressed by DDD? Quoting Eric Evans in the DDD book (p. 157): "The client of a REPOSITORY should be given the illusion that the objects are in memory.". That being said, it is no problem to call a method on a repository and have it return the objects immediately if the objects are in memory. But, if the objects are sent back asynchronously, the whole point of encapsulating that behavior is gone since the client needs to "listen" for a response on the repository. So it knows about the implementation details of the repository.

As a reply, someone offered to try to make the call synchronous by waiting for a result. Although I think that might work, for instance by entering a loop until the result is received, I'm not completely sure as I haven't tried this. Here's my reply:

The problem I see is that the UI will be locked/frozen until the response is received because the code runs in a single thread within the Flash player. That means it won't be possible to create a (animated) loading screen to give the user some visual feedback. This would probably not be a problem with remote calls that return a small amount of data and a fast remote connection, but it certainly will be a (usability) problem if the connection is slow or if we are loading large chunks of data.

Conclusion

So my conclusion at this moment is that implementing Repository in Flex doesn't make much sense since the client still needs to know about some of the technical details of the implementation. Locking the UI would most certainly lead to usability problems (if it would even be possible). On the other hand, a Repository could be perfectly implemented as intended in an AIR application that uses an embedded SQLite database and synchronous calls, but the UI would also be locked.

Thoughts?

There seem to be some problems with the Flex 3 licenses. Matt Chotin posted some info here and here.

However if you are installing the trial version, the info provided about removing the license.properties file on Windows is not correct if you're on Vista.

The correct path is C:\Users\[USERNAME]\AppData\Local\VirtualStore\ProgramData\
Adobe\Flex\license.properties

After you removed this file, restart Eclipse and you'll be prompted with the license window that states you can continue the 60 day trial.

Have fun!