From Kohana to ZendFramework in about 30 minutes

I am pleased to say that it took me only about 30 minutes to transfer a basic site writte on Kohana to the ZendFramework, both frameworks make it easy to switch between each other. For one thing you can use the ZendFramework Library in Kohana (although I haven’t done it myself people declare is rather easy)

The thing I like the most about the ZendFramework is their tool which comes as a part of their library download. I have mainly used the tool to create the controllers and actions and so far it has been a time saver and has helped me to see how the framework works in a few keystrokes.

After the first site was a success the next step will be to convert a site with a simple CMS built in Kohana to the ZendFramework, I have to admit that there were two things that held me back for a while into using the ZendFramework.

Speed

I read in different blogs how slow ZendFramework was compared to other frameworks such as Kohana, CI, CakePHP and even the new framework called Yii. The graphic below is one of my many findings:


(Source yiiframework.com)

But it is obvious that as the time goes by the framework is getting better and seems like it is getting faster as well.

Initial setup

When I tried the framework for the first time was about a year ago or so, it was brand new and people were still getting their heads around it as well as was very limited content in the subject so my first attempt to try it was a failure but months later I come back and wow, what a difference. Not only that but I stayed away from the full package and downloaded the minimal package and started just with the library and it was a breeze.

It is nice to have different packages to choose from and that they get better day by day. So far Zend has made it an easy transition and a nice new PHP development start.

RobotLegs and Flash IDE CS4 Injection

“UPDATE: It has been discovered that Flash CS3/4 can be instructed to keep metadata after all: Simply select “Export SWC” in your publish settings. Doing so will keep all metadata in tact in your SWF!” – Thanks to shaun for this clarification.

So you heard of the RobotLegs framework and downloade their demos so you could compile them on your own computer but the only thing that you have available is CS4, not a problem you can still use the framework and I’m going to update the “Hello Flash” demo to show you how. After this article you should be able to update any other demo or create your own with CS4.

Accordingly to the Knowledge Base we get a good kick start by letting us know that we need the following:

[as]//Initializing the injector with XML is done by adding this line to your context’s constructor, before the super() call:

injector = new SwiftSuspendersInjector(xmlConfiguration);

//Where xmlConfiguration is your XML object.[/as]

So in our HelloFlashContext file we are going to add our “xmlConfiguration” property that will be passed to the SwiftSuspendersInjector.

So I am going to borrow the XML_CONFIG from the SwiftSuspendersInjector and use it as a guide for my HelloFlashContext class.

[as]protected static const XML_CONFIG:XML =
















;

public function HelloFlashContext(contextView:DisplayObjectContainer)
{
injector = new SwiftSuspendersInjector(XML_CONFIG);
super(contextView);
}[/as]

Now that we know how our XML has to be formed we can start adding our custom properties that will substitute the [Inject] annotations.

There are only two locations where the inject annotation is being used.

[as]org.robotlegs.demos.hellowflash.view.BallMediator
org.robotlegs.demos.hellowflash.view.ReadoutMediator[/as]

and there are only 2 properties used in both instances

[as]view
statsModel[/as]

So with that information we very easily update our XML_CONFIG constant as follows:

[as]






[/as]

And here you have the complete HellowFlashContext class updated:

[as]package org.robotlegs.demos.helloflash
{
import flash.display.DisplayObjectContainer;

import org.robotlegs.base.ContextEvent;
import org.robotlegs.demos.helloflash.controller.CreateBallCommand;
import org.robotlegs.demos.helloflash.controller.HelloFlashEvent;
import org.robotlegs.demos.helloflash.model.StatsModel;
import org.robotlegs.demos.helloflash.view.Ball;
import org.robotlegs.demos.helloflash.view.BallMediator;
import org.robotlegs.demos.helloflash.view.Readout;
import org.robotlegs.demos.helloflash.view.ReadoutMediator;
import org.robotlegs.mvcs.Context;

import org.robotlegs.adapters.SwiftSuspendersInjector;

public class HelloFlashContext extends Context
{
protected static const XML_CONFIG:XML =








;

public function HelloFlashContext(contextView:DisplayObjectContainer)
{
injector = new SwiftSuspendersInjector(XML_CONFIG);
super(contextView);
}

override public function startup():void
{
// Map some Commands to Events
commandMap.mapEvent(ContextEvent.STARTUP_COMPLETE, CreateBallCommand, ContextEvent, true);
commandMap.mapEvent(HelloFlashEvent.BALL_CLICKED, CreateBallCommand, HelloFlashEvent );

// Create a rule for Dependency Injection
injector.mapSingleton(StatsModel);

// Here we bind Mediator Classes to View Classes:
// Mediators will be created automatically when
// view instances arrive on stage (anywhere inside the context view)
mediatorMap.mapView(Ball, BallMediator);
mediatorMap.mapView(Readout, ReadoutMediator);

// Manually add something to stage
contextView.addChild(new Readout());

// And we’re done
super.startup();
}

}
}[/as]

This way you should be able to update any demo and compile with the Flash IDE.

Updated: Thanks to Jos Yule for pointing out that the XML will be concatenated on the existing XML so no need to recreate it all

Optimizing SWF files with Flex Optimizer

I found a reference to optimizing SWC files with Flex Optimizer and I figured I would run some tests through SWF files and see what effects it had in it.

To my surprise the Optimizer tool did optimize the SWF files but just by a few bytes:

Test 1:
…_concept1_v1_alt.swf (56569 bytes)
…_concept1_v1_alt_optimized.swf (56456 bytes)

Test 2:
…600_Flash_v1.swf (38164 bytes)
…600_Flash_v1_optimized.swf (38127 bytes)

I also ran a test against a custom SWF file inside a SWC file and this is the result:

…DropDown/library.swf (14810 bytes)
…DropDown/library_optimized.swf (11723 bytes)

So the SWC files are bloated with extra information no needed and can be compressed quite a bit but SWF file no love. And it does make sense since the SWF files that I was testing contain a lot of graphics but I still gave it a go.

Here you can ind more information about Optimizing RSL SWF Files.