I’m putting this out there as a give back to other Flash-Flex developers that want to use Joomla! as a data repository for any projects, in part because Rune Skjoldborg Madsen has taken the time to build specific component views in php to change the transport layer to XML.

The backbone of the model objects is still XML so it can be quite flexible to update or change attributes as needed, however some of the fundamental differences in using fixed property classes are as follows:

  • Correct data type conversion: If an attribute or value is meant to be Boolean or int, it can be converted at the source layer via getter/setter properties instead of the consuming layer.
  • Marginal Performance Optimization: With fixed properties, the AVM2 does not need to look to the prototype chain if the property has not been overridden.
  • Data layer abstraction: If/WHEN the transport layer either changes form or naming convention, only the model itself needs to be updated not the dependencies of the model objects. This becomes important in larger scale applications and especially where Modules are used.
  • Compiler “Goodness”: Most IDE’s will be able to use contextual completion lists, as well as, any developer errors in spelling / case sensitivity / and type will be caught at compile time, and not left to run time since XML native objects are treated with the same loose rules as Array accessors.

The Joomla model and any objects rely on the ArrayCollection for Flex however this can be easily updated if you need to use this in Flash. In this case, change the collection property to an Array and in the creation methods change the method access from getItemAt / addItem as needed. Note the collection manager property for every object is protected. This allows type casting control over the returned object since the return type of both an Array and ArrayCollection are either Object or untyped. If needed, the implementation could be separated into it’s respective concrete object and interface.

As in the Joomla backend, all objects are stored as a nested collection of Section > Category > Article. Currently I have built the model to deal with requests for sections and for categories but not for individual articles. If a request for a category is made, a shell Section is created if it’s container id is not found.

Please note: this does not deal with the transport layer of making the requests to the server, this is only a post processor once that data has arrived.

A basic example to get you started (this assumes you’ve already made the appropriate service call, and this data is now ready to be processed. ViewPortalData is an internal class I’ve used to hold state of the requested id.

protected function onUpdateModelData(event:ServiceEvent):void {
var si:ServiceItem =ServiceItem(event.currentTarget);
si.removeEventListener(ServiceEvent.SUCCESS, onUpdateModelData);

//NOTE: If using the FlashFeed component on the Joomla backend
//you must first use an escape/unescape formatter to change > and < and other sequences
//to their actual respective characters in order to generate a valid XML string sequence
var model:IModel =new Joomla();
var section:Section =model.addSection(XML(event.resultData), ViewPortalData(si.data).id);
dispatchEvent(new ApplicationEvent(ApplicationEvent.MODEL_CHANGE));


Download it here: bigfatstogie-joomla-model