Monthly Archives: December 2009

What Do Oracle’s MySQL Promises Amount To?

Oracle has NOT promised (certainly not in a legally binding manner):

– To keep (all of) MySQL under an open source license.
– Not to add closed source parts, modules or required tools.
– To keep the code for MySQL enterprise edition and MySQL community edition the same.
– To not raise MySQL license or MySQL support prices.
– To release new MySQL versions in a regular and timely manner.
– To continue with dual licensing and always provide affordable commercial licenses to MySQL to those who needs them (to storage vendors and application vendors) or provide MySQL under a more permissive license
– To develop MySQL as an Open Source project
– To actively work with the community
– Apply submitted patches in a timely manner
– To not discriminate patches that make MySQL compete more with Oracles other products
– To ensure that MySQL is improved also in manners that make it compete even more with Oracles’ main offering.

In short, Oracle hasn’t promised to do much of anything that truly matters.

Oracle made a statement about MySQL’s future — but which addressed only one of the concerns on the above list, the one marked with an asterisk. Nothing — or at least, nothing of substance — has been said about MySQL’s future as an open source project.

It’s not surprising at all, given that all of Oracle’s experience with open source would come through their acquisition of Sun and not through anything they’ve done directly. Plus, almost nothing Oracle has said so far indicates they’re willing to let Sun’s people do the heavy lifting where MySQL is concerned.

At the very least, all that hammering on Oracle’s facade is producing a few cracks. It’s a sign that they can be persuaded to do the smart thing, and not tick off a great many people who could be potential customers.


The Sad Decline of Windows Mobile

Microsoft has been plugging away at the mobile computing market for almost as long as Windows has been around. Thinking of products like Windows for Pen Computing, or the original Windows CE for handheld devices. At best, the consumers were willing but the platforms were weak.

In Microsoft’s case, the problem with those early devices was a stubborn devotion to the look and feel of desktop Windows. Their vision seemed to be that the Windows GUI deserved to be moved to every device, because users understood how it worked. But of course, a desktop interface isn’t optimal for a mobile device with a tiny screen and lilliputian keyboard (if any). Tiny hardware platforms deserve software that’s optimally designed to work with them.

Pioneering mobile devices like the original PalmPilot and the BlackBerry weren’t shackled to a notion of a handheld interface that looked like a desktop, and they did very well. Then came the iPhone, a product from another maker of desktop operating systems. Apple didn’t feel obligated to mimic its desktop software design on the iPhone the way Microsoft did, and users seemed to like the result.

Now, Microsoft’s share of the mobile computing market is slipping away. Windows Mobile 6 looks pretty feeble next to the iPhone, which is why Windows Mobile 7 has been so greatly anticipated by Microsoft’s hardware partners. News is that there has been another delay in Windows Mobile 7, and we’re not likely to see it ship until late 2010.

The mobile market isn’t going to wait for Microsoft in 2010; far from it. Google’s Android platform is starting to make serious inroads into the market with hardware like the Motorola Droid; if the Google Phone rumors are to be believed there may be some big news in early 2010. And who knows what Apple has in store for the iPhone in 2010. In the meantime, the mobile device makers who’ve stuck with Microsoft and Windows Mobile are going to be tempted to jump ship, rather than wait a year or longer.

Selenium- testing from browser


The Selenium-IDE (Integrated Development Environment) is the tool you use to develop your Selenium test cases. It’s an easy-to-use Firefox plug-in and is generally the most efficient way to develop test cases. It also contains a context menu that allows you to first select a UI element from the browser’s currently displayed page and then select from a list of Selenium commands with parameters pre-defined according to the context of the selected UI element. This is not only a time-saver, but also an excellent way of learning Selenium script syntax.

This chapter is all about the Selenium IDE and how to use it effectively.

Installing the IDE

Using Firefox, first, download the IDE from the SeleniumHQ downloads page

When downloading from Firefox, you’ll be presented with the following window.

_images/chapt3_img01_IDE_Installation.pngSelect Install Now. The Firefox Add-ons window pops up, first showing a progress bar, and when the download is complete, displays the following.

_images/chapt3_img02_IDE_Installation.pngRestart Firefox. After Firefox reboots you will find the Selnium-IDE listed under the Firefox Tools menu.


Opening the IDE

To run the Selenium-IDE, simply select it from the Firefox Tools menu. It opens as follows with an empty script-editing window and a menu for loading, or creating new test cases.


IDE Features


The toolbar contains buttons for controlling the execution of your test cases, including a step feature for debugging your test cases. The right-most button, the one with the red-dot, is the record button.


speed control
Speed Control: controls how fast your test case runs.
run all
Run All: Runs the entire test suite when a test suite with multiple test cases is loaded.
Run: Runs the currently selected test. When only a single test is loaded this button and the Run All button have the same effect.
pause resume
Pause/Resume: Allows stopping and re-starting of a running test case.
Step: Allows one to “step” through a test case by running it one command at a time. Use for debugging test cases.
TestRunner Mode: Allows you to run the test case in a browser loaded with the Selenium-Core TestRunner. The TestRunner is not commonly used now and is likely to be deprecated. This button is for evaluating test cases for backwards compatibility with the TestRunner. Most users will probably not need this button.
Apply Rollup Rules: This advanced feature allows repetitive sequences of Selenium commands to be grouped into a single action. Detailed documentation on rollup rules can be found in the UI-Element Documentation on the Help menu.
Record: Records the user’s browser actions.

Test Case Pane

Your script is displayed in the test case pane. It has two tabs, one for displaying the command and their parameters in a readable “table” format.

_images/chapt3_img15_Table_Format.pngThe Source tab displays the test case in the native format in which the file will be stored. By default, this is HTML although it can be changed to a programming language such as Java or C#, or a scripting language like Python. See the Options menu for details. The Source view also allows one to edit the test case in its raw form, including copy, cut and paste operations.

The Command, Target, and Value entry fields display the currently selected command along with its parameters. These are entry fields where you can modify the currently selected command. The first parameter specified for a command in the Reference tab of the bottom pane always goes in the Target field. If a second parameter is specified by the Reference tab, it always goes in the Value field.

_images/chapt3_img16_Entry_Fields.pngIf you start typing in the Command field, a drop-down list will be populated based on the first characters you type; you can then select your desired command from the drop-down.

Log/Reference/UI-Element/Rollup Pane

The bottom pane is used for four different functions–Log, Reference, UI-Element, and Rollup–depending on which tab is selected.


When you run your test case, error messages and information messages showing the progress are displayed in this pane automatically, even if you do not first select the Log tab. These messages are often useful for test case debugging. Notice the Clear button for clearing the Log. Also notice the Info button is a drop-down allowing selection of different levels of information to display.



The Reference tab is the default selection whenever you are entering or modifying Selenese commands and parameters in Table mode. In Table mode, the Reference pane will display documentation on the current command. When entering or modifying commands, whether from Table or Source mode, it is critically important to ensure that the parameters specified in the Target and Value fields match those specified in the parameter list specified in the Reference pane. The number of parameters provided must match the number specified, the order of parameters provided must match the order specified, and the type of parameters provided must match the type specified. If there is a mismatch in any of these three areas, the command will not run correctly.

_images/chapt3_img18_Bottom_Box_Ref.pngWhile the Reference tab is invaluable as a quick reference, it is still often necessary to consult the Selenium Reference document.

UI-Element and Rollup

Detailed information on these two panes (which cover advanced features) can be found in the UI-Element Documentation on the Help menu of Selenium-IDE.

Building Test Cases

There are three primary methods for developing test cases. Frequently, a test developer will require all three techniques.


Many first-time users begin by recording a test case from their interactions with a website. When Selenium-IDE is first opened, the record button is ON by default.


This can be set to OFF as a default with an available user extension.

During recording, Selenium-IDE will automatically insert commands into your test case based on your actions. Typically, this will include:

  • clicking a link – click or clickAndWait commands
  • entering values – type command
  • selecting options from a drop-down listbox – select command
  • clicking checkboxes or radio buttons – click command

Here are some “gotchas” to be aware of:

  • The type command may require clicking on some other area of the web page for it to record.
  • Following a link usually records a click command. You will often need to change this to clickAndWait to ensure your test case pauses until the new page is completely loaded. Otherwise, your test case will continue running commands before the page has loaded all its UI elements. This will cause unexpected test case failures.

Adding Verifications and Asserts With the Context Menu

Your test cases will also need to check the properties of a web-page. This requires assert and verify commands. We won’t describe the specifics of these commands here; that is in the chapter on “Selenese” Selenium Commands. Here we’ll simply describe how to add them to your test case.

With Selenium-IDE recording, go to the browser displaying your test application and right click anywhere on the page. You will see a context menu showing verify and/or assert commands.

The first time you use Selenium, there may only be one Selenium command listed. As you use the IDE however, you will find additional commands will quickly be added to this menu. Selenium-IDE will attempt to predict what command, along with the parameters, you will need for a selected UI element on the current web-page.

Let’s see how this works. Open a web-page of your choosing and select a block of text on the page. A paragraph or a heading will work fine. Now, right-click the selected text. The context menu should give you a verifyTextPresent command and the suggested parameter should be the text itself.

Also, notice the Show All Available Commands menu option. This shows many, many more commands, again, along with suggested parameters, for testing your currently selected UI element.

Try a few more UI elements. Try right-clicking an image, or a user control like a button or a checkbox. You may need to use Show All Available Commands to see options other than verifyTextPresent. Once you select these other options, the more commonly used ones will show up on the primary context menu. For example, selecting verifyElementPresent for an image should later cause that command to be available on the primary context menu the next time you select an image and right-click.

Again, these commands will be explained in detail in the chapter on Selenium commands. For now though, feel free to use the IDE to record and select commands into a test case and then run it. You can learn a lot about the Selenium commands simply by experimenting though the IDE.


Insert Command

Table View

Select the point in your test case where you want to insert the command. Right-click and select Insert Command. Now use the command editing text fields to enter your new command and its parameters.

Source View

Select the point in your test case where you want to insert the command, and enter the HTML tags needed to create a 3-column row containing the Command, first parameter (if one is required by the Command), and second parameter (again, if one is required). Be sure to save your test before switching back to Table view.

Insert Comment

Comments may be added to make your test case more readable. These comments are ignored when the test case is run.

In order to add vertical white space (one or more blank lines) in your tests, you must create empty comments. An empty command will cause an error during execution.

Table View

Select the point in your test case where you want to insert the comment. Right-click and select Insert Comment. Now use the Command field to enter the comment. Your comment will appear in purple font.

Source View

Select the point in your test case where you want to insert the comment. Add an HTML-style comment, i.e., <!– your comment here –>.

Edit a Command or Comment

Table View

Simply select the line to be changed and edit it using the Command, Target, and Value fields.

Source View

Since Source view provides the equivalent of a WYSIWYG editor, simply modify which line you wish–command, parameter, or comment.

Opening and Saving a Test Case

The File=>Open, Save and Save As menu commands behave similarly to opening and saving files in most other programs. When you open an existing test case, Selenium-IDE displays its Selenium commands in the test case pane.

Test suite files can also be opened and saved via the File menu. However, such operations have their own menu entries near the bottom; the Open, Save, and Save As items are only for files.


At the time of this writing, there’s a bug, where at times, when the IDE is first opened and then you select File=>Open, nothing happens. If you see this, close down the IDE and restart it (you don’t need to close the browser itself). This will fix the problem.

Running Test Cases

The IDE allows many options for running your test case. You can run a test case all at once, stop and start it, run it one line at a time, run a single command you are currently developing, and you can do a batch run of an entire test suite. Execution of test cases is very flexible in the IDE.

Run a Test Case
Click the Run button to run the currently displayed test case.
Run a Test Suite
Click the Run All button to run all the test cases in the currently loaded test suite.
Stop and Start
The Pause button can be used to stop the test case while it is running. The icon of this button then changes to indicate the Resume button. To continue click Resume.
Stop in the Middle
You can set a breakpoint in the test case to cause it to stop on a particular command. This is useful for debugging your test case. To set a breakpoint, select a command, right-click, and from the context menu select Toggle Breakpoint.
Start from the Middle
You can tell the IDE to begin running from a specific command in the middle of the test case. This also is used for debugging. To set a startpoint, select a command, right-click, and from the context menu select Set/Clear Start Point.
Run Any Single Command
Double-click any single command to run it by itself. This is useful when writing a single command. It lets you immediately test a command you are constructing, when you are not sure if it is correct. You can double-click it to see if it runs correctly. This is also available from the context menu.

Using Base URL to Run Test Cases in Different Domains

The Base URL field at the top of the Selenium-IDE window is very useful for allowing test cases to be run across different domains. Suppose that a site named had an in-house beta site named Any test cases for these sites that begin with an open statement should specify a relative URL as the argument to open rather than an absolute URL (one starting with a protocol such as http: or https:). Selenium-IDE will then create an absolute URL by appending the open command’s argument onto the end of the value of Base URL. For example, the test case below would be run against

_images/chapt3_img20_BaseURL_prod.pngThis same test case with a modified Base URL setting would be run against



Debugging means finding and fixing errors in your test case. This is a normal part of test case development.

We won’t teach debugging here as most new users to Selenium will already have some basic experience with debugging. If this is new to you, we recommend you ask one of the developers in your organization.

Breakpoints and Startpoints

The Sel-IDE supports the setting of breakpoints and the ability to start and stop the running of a test case, from any point within the test case. That is, one can run up to a specific command in the middle of the test case and inspect how the test case behaves at that point. To do this, set a breakpoint on the command just before the one to be examined.

To set a breakpoint, select a command, right-click, and from the context menu select Toggle Breakpoint. Then click the Run button to run your test case from the beginning up to the breakpoint.

It is also sometimes useful to run a test case from somewhere in the middle to the end of the test case or up to a breakpoint that follows the starting point. For example, suppose your test case first logs into the website and then performs a series of tests and you are trying to debug one of those tests. However, you only need to login once, but you need to keep rerunning your tests as you are developing them. You can login once, then run your test case from a startpoint placed after the login portion of your test case. That will prevent you from having to manually logout each time you rerun your test case.

To set a startpoint, select a command, right-click, and from the context menu select Set/Clear Start Point. Then click the Run button to execute the test case beginning at that startpoint.

Stepping Through a Testcase

To execute a test case one command at a time (“step through” it), follow these steps:

  1. Start the test case running with the Run button from the toolbar.


  1. Immediately pause the executing test case with the Pause button.


  1. Repeatedly select the Step button.


Find Button

The Find button is used to see which UI element on the currently displayed webpage (in the browser) is used in the currently selected Selenium command. This is useful when building a locator for a command’s first parameter (see the section on locators in the Selenium Commands chapter). It can be used with any command that must identify a UI element on a webpage, i.e. click, clickAndWait, type, and certain assert and verify commands, among others.

From Table view, select any command that has a locator parameter. Click the Find button. Now look on the webpage displayed in the Firefox browser. There should be a bright green rectangle enclosing the element specified by the locator parameter.

Page Source for Debugging

Often, when debugging a test case, you simply must look at the page source (the HTML for the webpage you’re trying to test) to determine a problem. Firefox makes this easy. Simply, right-click the webpage and select Page Source. The HTML opens in a separate window. Use its Search feature (Edit=>Find) to search for a keyword to find the HTML for the UI element you’re trying to test.

Alternatively, select just that portion of the webpage for which you want to see the source. Then right-click the webpage and select View Selection Source. In this case, the separate HTML window will contain just a small amount of source, with highlighting on the portion representing your selection.

Locator Assistance

Whenever Selenium-IDE records a locator-type argument, it stores additional information which allows the user to view other possible locator-type arguments that could be used instead. This feature can be very useful for learning more about locators, and is often needed to help one build a different type of locator than the type that was recorded.

This locator assistance is presented on the Selenium-IDE window as a drop-down list accessible at the right end of the Target field (only when the Target field contains a recorded locator-type argument). Below is a snapshot showing the contents of this drop-down for one command. Note that the first column of the drop-down provides alternative locators, whereas the second column indicates the type of each alternative.


Writing a Test Suite

A test suite is a collection of test cases which is displayed in the leftmost pane in the IDE. The test suite pane can be manually opened or closed via selecting a small dot halfway down the right edge of the pane (which is the left edge of the entire Selenium-IDE window if the pane is closed).

The test suite pane will be automatically opened when an existing test suite is opened or when the user selects the New Test Case item from the File menu. In the latter case, the new test case will appear immediately below the previous test case.

Selenium-IDE does not yet support loading pre-existing test cases into a test suite. Users who want to create or modify a test suite by adding pre-existing test cases must manually edit a test suite file.

A test suite file is an HTML file containing a one-column table. Each cell of each row in the <tbody> section contains a link to a test case. The example below is of a test suite containing four test cases:

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>Sample Selenium Test Suite</title>

    <table cellpadding="1" cellspacing="1" border="1">

            <tr><td>Test Cases for De Anza A-Z Directory Links</td></tr>
        <tr><td><a href="./a.html">A Links</a></td></tr>

        <tr><td><a href="./b.html">B Links</a></td></tr>
        <tr><td><a href="./c.html">C Links</a></td></tr>

        <tr><td><a href="./d.html">D Links</a></td></tr>



Test case files should not have to be co-located with the test suite file that invokes them. And on Mac OS and Linux systems, that is indeed the case. However, at the time of this writing, a bug prevents Windows users from being able to place the test cases elsewhere than with the test suite that invokes them.

User Extensions

User extensions are JavaScript files that allow one to create his or her own customizations and features to add additional functionality. Often this is in the form of customized commands although this extensibility is not limited to additional commands.

There are a number of useful extensions created by users.

Perhaps the most popular of all Selenium-IDE extensions is one which provides flow control in the form of while loops and primitive conditionals. This extension is the goto_sel_ide.js. For an example of how to use the functionality provided by this extension, look at the page created by its author.

To install this extension, put the pathname to its location on your computer in the Selenium Core extensions field of Selenium-IDE’s Options=>Options=>General tab.

_images/chapt3_img31_Extensions_install.pngAfter selecting the OK button, you must close and reopen Selenium-IDE in order for the extensions file to be read. Any change you make to an extension will also require you to close and reopen Selenium-IDE.

Information on writing your own extensions can be found near the bottom of the Selenium Reference document.


Format, under the Options menu, allows you to select a language for saving and displaying the test case. The default is HTML.

If you will be using Selenium-RC to run your test cases, this feature is used to translate your test case into a programming language. Select the language, i.e. Java, PHP, you will be using with Selenium-RC for developing your test programs. Then simply save the test case using File=>Save. Your test case will be translated into a series of functions in the language you choose. Essentially, program code supporting your test is generated for you by Selenium-IDE.

Also, note that if the generated code does not suit your needs, you can alter it by editing a configuration file which defines the generation process. Each supported language has configuration settings which are editable. This is under the Options=>Options=>Format tab.


At the time of this writing, this feature is not yet supported by the Selenium developers. However the author has altered the C# format in a limited manner and it has worked well.

Executing Selenium-IDE Tests on Different Browsers

While Selenium-IDE can only run tests against Firefox, tests developed with Selenium-IDE can be run against other browsers, using a simple command-line interface that invokes the Selenium-RC server. This topic is covered in the Run Selenese tests section on Selenium-RC chapter. The -htmlSuite command-line option is the particular feature of interest.


Below is a list of image/explanation pairs which describe frequent sources of problems with Selenium-IDE:

_images/chapt3_img30_Trouble_startup.pngThis problem occurs occasionally when Selenium IDE is first brought up. The solution is to close and reopen Selenium IDE. The bug has been filed as SIDE-230.

_images/chapt3_img24_Trouble_open.pngYou’ve used File=>Open to try to open a test suite file. Use File=>Open Test Suite instead.

_images/chapt3_img27_Trouble_timing.pngThis type of error may indicate a timing problem, i.e., the element specified by a locator in your command wasn’t fully loaded when the command was executed. Try putting a pause 5000 before the command to determine whether the problem is indeed related to timing. If so, investigate using an appropriate waitFor* or *AndWait command immediately before the failing command.

_images/chapt3_img28_Trouble_param.pngWhenever your attempt to use variable substitution fails as is the case for the open command above, it indicates that you haven’t actually created the variable whose value you’re trying to access. This is sometimes due to putting the variable in the Value field when it should be in the Target field or vice versa. In the example above, the two parameters for the store command have been erroneously placed in the reverse order of what is required. For any Selenese command, the first required parameter must go in the Target field, and the second required parameter (if one exists) must go in the Value field.

_images/chapt3_img23_Trouble_ts.pngOne of the test cases in your test suite cannot be found. Make sure that the test case is indeed located where the test suite indicates it is located. Also, make sure that your actual test case files have the .html extension both in their filenames, and in the test suite file where they are referenced.

_images/chapt3_img25_Trouble_space.pngSelenium-IDE is very space-sensitive! An extra space before or after a command will cause it to be unrecognizable.

_images/chapt3_img26_Trouble_extension.pngYour extension file’s contents have not been read by Selenium-IDE. Be sure you have specified the proper pathname to the extensions file via Options=>Options=>General in the Selenium Core extensions field. Also, Selenium-IDE must be restarted after any change to either an extensions file or to the contents of the Selenium Core extensions field.

_images/chapt3_img29_Trouble_collapsed.pngThis type of error message makes it appear that Selenium-IDE has generated a failure where there is none. However, Selenium-IDE is correct that the actual value does not match the value specified in such test cases. The problem is that the log file error messages collapse a series of two or more spaces into a single space, which is confusing. In the example above, note that the parameter for verifyTitle has two spaces between the words “System” and “Division.” The page’s actual title has only one space between these words. Thus, Selenium-IDE is correct to generate an error.

Log package for Flex and Air apps

The ASLib de.flamelab.log package provides classes and functionalities for general purpose logging. It can be regarded as an alternative to the Flex build in mx.loggging package as it offers a different approach, similar to the Zend_Log component in PHP. It can be used in any ActionScript based project and is therefore not limited to Flex applications.


The package supports multiple log backends and formatting and filtering messages sent to the log. These functionality is devided into to the following objects:

    A Log (de.flamelab.log.Log) represents the basic object. An application can have as many Log objects as you like. Log objects can be sotred in the LogRegistry
    A Writer (de.flamelab.log.AbstractLogWriter) implements a concrete logging mechanism and is therfore responsible for saving the message to a storage. New Writers can be added by inheriting and implementing the abstract base class.
    A Filter (de.flamelab.log.ILogFilter) blocks data from being logged. A filter is applied to a Writer object and can be chained with other filters.
    A Formatter(de.flamelab.log.ILogFormatter) is used to format the log messages before they are written by a Writer. Each Writer has excatly one Formatter.
    A LogRegistry (de.flamelab.log.LogRegistry) can be used to gain convenient access to different Log instances among different classes.
    A LogEvent (de.flamelab.log.LogEvent) is used for encapsulating the necessary log information an is dispatched to all assigned Writers of a Log object.

Logging messages

To start logging, a Writer intance must be passed to a Log instance and the log() Method can be called on the Log. Additionally, the Log instance can be stored in the LogRegistry for further usage. Writer instances can be fetched through a static method of a LogFactory. A Log instance must at least have one Writer assigned with the addWriter() method to it to work properly. If multiple Writers are assigned, each Writer recieves the log data.

logger = new Log();
LogRegistry.setLog('testlogger', logger);
var write:AbstractLogWriter = LogFactory.getWriter(LogFactory.FIREBUG);
logger.log("emergency log message", Log.EMERG);

The log method accepts two arguments, the log message and a priority. The Log class defines the following priorites, based on the BSD syslog protocol, described in RFC-3164:

    EMERG – Emergency: system is unusable
    ALERT – Alert: action must be taken immediately
    CRIT – Critical: critical conditions
    ERR – Error: error conditions
    WARN – Warning: warning conditions
    NOTICE – Notice: normal but significant condition
    INFO – Informational: informational messages
    DEBUG – Debug: debug messages

By calling the log() method, a LogEvent instance is created an populated with all necessary data describing the log action. It is passed to all Writer objects and its creation is completely transparent.


A Writer is an object which responsibility is to record the log data to a defined storage. All Writer inherit and implement the abstract AbstractLogWriter class. Each Writer can be instantiated directly or it can be fetched through the LogFactory. The package already has the following Writer objects implemented:

    LogWriterFirebug: Writes the data to the Firebug Console.
    LogWriterAirFile: Uses the FileStream object to write log messages to a defined logfile on the clients’ filesystem.
    LogWriterAirSqlite: Uses Airs’ SQLite ability and stores messages in a automatically created, local database table.

All Writers are meant for logging certain application activities or errors during application runtime, not only while developing or debugging.


A Formatter takes an LogEvent and formates its data in a predefined manner for storage. Some Writers are not line-oriented and cannot use a Formatter. The LogWriterAirSqlite for example takes the data from the event and inserts its values into the database directly.

Each Formatter must implement the ILogFormatter interface. The package includes a basic LogFormatterSimple that uses a user-defined pattern for arranging the data provided by the LogEvent in a message. It is also used for default formatting when no Formatter is specified. A Formatter is set on an individual Writer by using the setFormatter() method.

logger = new Log();
var writer:AbstractLogWriter = LogFactory.getWriter(LogFactory.AIRFILE, {uri:"logs/log.txt"});
var format:LogFormatterSimple = new LogFormatterSimple("%timestamp%:%message%");
logger.log("error log message", Log.ERR);


A Filter objects decides if a message should be stored or blocked from being written to the log. The addFilter() method is used to add a Filter to a Writer. They can be chained, as multiple Filters can be applied. Each Filter mus implement the ILofFilter interface. The package comes with two predefined classes:

    LogFilterPriority: Only messages with a priority smaller or equal the given value are logged.
    LogFilterRegex: Uses a regular expression to decide whether a message should be blocked.

logger = new Log();
var writer:AbstractLogWriter = LogFactory.getWriter(LogFactory.AIRFILE, {uri:"logs/log.txt"});
var prioFilter:LogFilterPriority = new LogFilterPriority(Log.WARN);
var regex:RegExp = /.*?(critical).*?/;
var regexFilter:LogFilterRegex = new LogFilterRegex(regex);

logger.log(“error log message”, Log.ERR);

The package is part of the ASLib. The sources can be downloaded.

Flex – Cairngorm Architecture Overview

Cairngorm is the lightweight micro-architecture for Rich Internet Applications built in Flex or AIR. A collaboration of recognized design patterns, Cairngorm exemplifies and encourages best-practices for RIA development advocated by Adobe Consulting, encourages best-practice leverage of the underlying Flex framework, while making it easier for medium to large teams of software engineers deliver medium to large scale, mission-critical Rich Internet Applications.

Cairngorm Architectural Framework

Cairngorm follows the principle of separating the view and business logic which is known as the Model-View-Controller pattern (MVC). The following list shows the different elements that form the framework.

1. View: Contains UI controls for user interaction and displays the state of the models data. Views dispatch events handled by the controller.

2. Model Locator: It acts as a centralized repository for all data needed in the application. It manages the view an is declared as [Bindable] to use all variables for data binding in the view. It must be implemented as a singleton which implements the Cairngorm IModelLocator. All data managed in the model should only be updated through a command or a responder object.

3. Value Object (VO): A value object is a class that only has properties to store values. It contains no methods or logic and acts as a pure data container. Value objects must implement the Cairngorm ValueObject interface. If they should be mapped to a corresponding server-side class it must declare the [RemoteClass (alias=”)] metatag. By doing so, Flex automatically converts an server-side object returned through remoting or data service interaction to its corresponding ActionScript object.

4. Event: In Cairngorm everything should be mapped to an event. Whenever the user interacts with the view or an action occurs an event must be dispatched. Custom events extend the CairngormEvent class an have a special property to contain the data that comes with it.

5. Command: Commands actually do the majority of an applications work. They recieve the event and its data, execute the logic an can change the workflow state of the model and view. Each command must implement the Cairngorm ICommand interface and its execute function. The revcieved event is a generic CairngormEvent and must be casted to the appropriate custom event first. The complete frontend-logic of the RIA is encapsulated within the commands.

6. Front Controller: It extends the Cairngorm FrontController class and maps the dispatched events to its corresponding commands. Therefore it has two methods: the constructor and an initialize method which will map an event to an command via the addCommand method. The controller is instantiated directly in the main.mxml via a component tag. You simply need to add the directory your class is in as an XML Namespace and then include the tag in the file.

7. Service Locator: Implemented as a singleton, it contains references to all services an application will use. Like the Front Controller, it is placed within the main.mxml via a tag. Possible services to be used are RemoteObjects, HTTPServices, WebServices or custom services.

8. Business Delegate: Business Delegates form an abstraction layer between the server-side services and the main frontend application. The locate the required service in the Service Locator, call the given method on it and route the response back to a responder object. Unlike the other elemente in the Cairngorm architecture, it does not extend a class or implement an interface, but it need to follow some guidelines: it must have at least two properties, one named reference to the ServiceLocator and one reference to a responder, both set in the constructor. And it must have implemented one method for each server-side method to be called. The delegate is created within a command object. It should only pass strongly typed value objects to a responder. If it does not recieve an appropriate object, it must create one before passing it.

9. Responder: Responders implement the mx.rpc.IResponder interface. A responder recieves the result of a service call and implements frontend-logic like a command. It directly may set values of the model and should only deal with strongly typed value objects.

10. Service: The Service is formed by an application tier, build with some server-side technology like J2EE or PHP. It Accepts the service requests from the RIA and responds back data. With a remoting technology like BlazeDS it is even possible to pass back value objects witch are transformed to their corresponding ActionScript objects in the application, so it can interact with them as if they are created by script.

PHP 5.3.1 Release Announcement

The PHP development team has announced the immediate release of PHP 5.3.1. This is a maintenance release in the 5.3 series, which includes a large number of bug fixes.

Security Enhancements and Fixes in PHP 5.3.1:

* Added “max_file_uploads” INI directive, which can be set to limit the number of file uploads per-request to 20 by default, to prevent possible DOS via temporary file exhaustion.
* Added missing sanity checks around exif processing.
* Fixed a safe_mode bypass in tempnam().
* Fixed a open_basedir bypass in posix_mkfifo().
* Fixed bug #50063 (safe_mode_include_dir fails).
* Fixed bug #44683 (popen crashes when an invalid mode is passed).

Key Bug Fixes in PHP 5.3.1 include:

* Fixed crash in com_print_typeinfo when an invalid typelib is given.
* Fixed crash in SQLiteDatabase::ArrayQuery() and SQLiteDatabase::SingleQuery() when calling using Reflection.
* Fixed crash when instantiating PDORow and PDOStatement through Reflection.
* Fixed bug #49910 (no support for ././@LongLink for long filenames in phar tar support).
* Fixed bug #49908 (throwing exception in __autoload crashes when interface is not defined).
* Around 100 other bug fixes

Adobe Flash CS5 Makes Native iPhone Apps

At its annual developer conference in Los Angeles on Monday, Adobe secured Flash’s future, at least for the near term.

Adobe said that its forthcoming Flash Professional CS5 will allow to developers “to create rich, interactive applications for the iPhone and iPod Touch.”

But just because those applications were created as Flash applications does not mean they will be allowed to run as Flash applications.

Flash Professional CS5, to be released as a public beta later this year, will allow developers to create Flash applications using the Flash development platform and then export those Flash apps as native iPhone applications.

“We created a new compiler front end that allowed LLVM [Low Level Virtual Machine] to understand ActionScript 3 and used its existing ARM back end to output native ARM assembly code,” explains Adobe senior product manager Aditya Bansod in a blog post. “…When you build your application for the iPhone, there is no interpreted code and no runtime in your final binary. Your application is truly a native iPhone app.”

That means certain Flash capabilities, such as being able to load another another Flash (.SWF) file or to browse Web content from within exported Flash apps, will not be available. Developers using Apple’s tools, however, can browse Web content from within their own apps via the SDK’s UIWebKit component.

Adobe’s announcement does not change the fact that Flash content on the Web is inaccessible through the iPhone’s Safari browser. Flash content on the Web requires Adobe’s Flash Player browser plug-in, which relies on a just-in-time compiler and virtual machine to render Flash content. Apple does not allow interpreted code on the iPhone.

James Anthony, co-founder of iPhone game maker Inedible Software, said in an e-mail that since his company has been developing native iPhone applications, its development process won’t change at all.

“What does make a huge difference is the flood of Flash developers that can now easily port their existing properties to the iPhone, as well as rapidly create new ones,” he said. “Apple made it pretty easy to get up to speed on the SDK, but this makes iPhone programming trivial for the tons of Flash programmers already out there. It’s definitely most well-suited to games, which aren’t expected to use the built-in user interface elements. There have already been lots of successful games that were clones or ports of existing Flash properties, and now the originals can make the leap painlessly.”

A sudden influx of Flash app conversions may not be entirely welcome, however. iPhone developers have been complaining about how difficult it has become to be noticed among the exploding inventory of Apple’s iTunes App Store and more games means more competition.

Apple recently announced that over 85,000 applications are available for the iPhone and that number is likely to pass 100,000 before the end of the year.

Adobe also announced that Google and RIM have joined its Open Screen Project, an initiative make Flash and Adobe AIR available as a consistent runtime environment across a wide variety of devices and platforms. The company said that Flash 10.1 would be available on Google Android, Blackberry, Symbian, Palm webOS and Windows Mobile devices toward the end of the year.

Google’s decision to support Flash may seem to be out of character. Google executives have been proclaiming loudly that the Web is the platform of the future and have been promoting open Web technologies like HTML 5, which duplicate some Flash functionality. The company’s willingness to look beyond Flash is even more explicit in a recent patent application that describes the company’s ambition to create sophisticated 3D maps “without needing special software such as a Flash plug-in or the like.”

However, company insiders are now striking a more conciliatory tone and acknowledging that Flash may be a better tool for certain jobs than Web technologies and that a lot of developers want to use Flash.

In a blog post, Google SVP of engineering Bill Coughran explains, “We’ve always believed that open platforms lead to greater innovation on the Web and we see participating in the Open Screen Project as another step in that direction.”

Although Adobe appears to have dispelled many doubts about Flash’s future at a time when so many are moving toward open Web technologies, the continued absence of the Flash player on the iPhone will become all the more glaring if Apple, as expected, releases an iTunes-dependent tablet device next year. An Apple tablet could be a showcase device for rich media content, and Adobe will want to make certain that its Flash technology plays a staring role.