Finally, it seems that double click is completely ignored by Firefox 3.6 on Mac OS X, but fortunately this seems to been fixed in the last release (3.6.3)

• getHours()
• getMinutes()
• getSeconds()

So, in order to take advantage of these useful methods, all we have to do is initialize a “fake” date using the amount of seconds we want to “split” into hours, minutes and seconds. The Date class has several OPTIONAL arguments that can be specified during its initializations, these are:

• year
• month
• date (day number)
• hours
• minutes
• seconds
• milliseconds

Because theme all are optional, we can create a date object by specifying only the know arguments (in our case seconds) and by assigning null or zero to the others:

Then by calling getHours, getMinutes and getSeconds we will obtain what we expect:

Not sure about the result? Let’s test it:

60 * 60 * 2 = 7200; (seconds contained in 2 hours)
32 * 60 = 1920; (seconds contained in 32 minutes)
7200 + 1920 + 17 = 9137; (original seconds!)

Learn more here: http://www.daveoncode.com/air-logging-framework

Just a note: although I tested the library (windows and mac) and it works fine, this project may contains bugs or doesn’t work under some circumstances. Comments and feedback are welcome!

Deploy an swc file

To obtain an SWC file, we have first to create a library project by selecting “New > Flex Library Project” from Flex builder’s menu.
The file will be automatically generated under the bin folder as soon a new class is created and/or modified (under src folder) and it will have the same name of the project. Is also possible to copy .as files from a folder and paste them into src folder, but in this case the SWC file won’t be (re)deployed until we select the new added classes under “Flex Library Build Path“.
There are two other cases for which Flex Builder won’t (re)deploy the SWC file and is important to keep these in mind, because no errors nor notification messages will be showed by the ide and this could lead to a waste of time trying to figure out what is going on.
The two big things to remember are:

1. Be sure to check “Include Adobe AIR libraries” under “Flex library compiler” settings (this can be defined during library creation step or after) when the library make use of AIR api
2. Be sure that package path, declared into imported classes, match the structure of src folder (if we import a class “MyClass” with a package declaration like “com.mysite.ui” then src folder must contain “com/mysite/ui” and “MyClass” must be placed there, if we put it under the src root it won’t be compiled into SWC)

Import the swc file into a project

Once we get our library project and our compiled swc, we can import it into others Flex projects by going to “Flex build path > Library path” and selecting “Add project“. There are two ways of using the imported library and to determine the type of linkage to it: a static link (by choosing the default option “Merge into code“) or dynamic link (by choosing the default option “Runtime shared library (RSL)“). The difference between the two types of linkage are that, in the first all library content are compiled into the final project’s swf file, so once you import and merge the library, its swc file is not necessary anymore and you can distribute your application without the external library (it’s already embedded into the app), by using an RSL instead the library is loaded at runtime and the application swf doesn’t keep it’s data, but only a reference to its location, so the resulting file is smaller than the previous one, but you must be sure to release the Flex application in conjunction with the external library in order to works, otherwise Flex Builder will show an error saying “unable to open path/yourlib.swc” (where “path” is the path to the library you previously imported).

So, this is what I done:

1. I defined an interface IFilter, which declares only one method: apply()
2. I defined a dummy Filter class (which implements IFilter in a basic way just to agree to the interface), that is used as a basic empty filter to decorate. It also has a constant called ALL_VALUES which is used as a wildcard for filters (it’s a simple string with value “*”, which means “all values are allowed”)
3. I defined an abstract AbstractFilterDecorator class
4. I created as many subclass of AbstractFilterDecorator as the filters I need (yes I treat filters as classes not mere functions)

The implementation code is the following:

The filter object is wrapped by decorators which all accepts 2 common arguments: an IFilter reference and an Object representing a value. The DateFilter has a third parameter which is used to configure an internal DateFormatter (from mx.formatters package).
I’m pretty satisfied :)
Uh… and if you are worried about performance, it is fast enough because filter object are created once and then the function assigned to filterFunction is a reference to the resulting decorated filter.

UPDATE:
I realized a very simple example application which can be downloaded here.
This following is the content of the mxml file:

The classes diagram of this pattern is composed by an interface or an abstract class which will define the supertype of the class that will be extended (decorated) by one or more classes implementing the same interface and extending an abstract class which identify these as decorator classes.

A real scenario into which apply this pattern can be a cars store. A car is the base class and the accessories such dvd player, gps, air conditioning and so on, can be thought as decorators. Once decorated, the car (which has a method getPrice() which returns its cost) will get updated by accessories, so calling the getPrice() method will include the price of the “naked” car plus the price of the various accessories installed.

Let’s take a look to the classes…

The interface above will be implemented by all the classes and we will treat the car as an IVehicle not a concrete Car class.
This is our simple Car class:

Now is time to see the decorators (in our scenario the accessories). This is the abstract Accessory class, all accessories will extend it:

In Accessory we can notice that the class encapsulate an object of IVehicle which is passed to the constructor (of course since this class is abstract the object will be passed to the constructor of Accessory’s subclasses). This is the key concept of decorator pattern, all decorators keep a reference of the interface they are going to decorate and this reference is used as the base for methods business logic. Let’s see how:

DVDPlayer is a concrete decorator and it uses the encapsulated IVehicle object in order to provide an extended version of the interface methods (getPrice() and getDescription()). Basically it uses first the reference methods and then it adds some other values.

To use the pattern we will first instantiate a Car object, than we will wrap it with one or more decorators:

The output will be:

Price: 50000 - description: Base car
Price: 50550 - description: Base car, DVD Player
Price: 50875 - description: Base car, DVD Player, GPS System

The order into which we wrap the concrete component (Car) is indifferent (we can add GPSSystem before or after DVDPlayer) and of course despite its readability, we can wrap the Car in a single statement:

In this example I used very simple classes, however in a real implementation we can create more sophisticated decorators which will accept extra arguments beyond the IVehicle reference.

This is a piece of my AS code to set DataGridColumn width in percentage:

In my code I’m setting the columns to 10% and to 60% only for “Message” column.

Example:

var myString = "000123";
alert(parseInt(myString));

The code above will alert 83 instead of 123 (because the default base guessed by Javascript isn’t 10 like in Actionscript), to get 123 the code must be:

var myString = "000123";
alert(parseInt(myString, 10));

The logging framework is a powerful feature that comes with Flex’s sdk and it’s composed by the classes under mx.logging package, which includes the two “subpackages” mx.logging.errors and mx.logging.target.

Java developers should be already confident whit such framework, because logging api are commonly used in Java programming,  Actionscript /Flash/Flex developers may find this tool a novelty (as I did).

The objective of logging framework is to provide a tool that offers a far better, flexible and centralized way to debug an application than simple use a lot of trace() callings. With Flex’s debugging framework we are able to print and filtering among different types of message based on their severity, such:

• DEBUG
• ERROR
• FATAL
• INFO
• WARN

We can also print the timestamp of the message and the class it refers to, and finally we can simultaneously print messages to different targets.

How it works

The logging framework is basically represented by 3 units: a logger, a target and a log event. The first component is the main class of the framework and its job is to register the different “loggable classes”, register one or more targets and dispatch log events. A target is a class which receives a LogEvent event and handles it by printing its information (message, date, level…) somewhere. A LogEvent event is dispatched when one of the logger methods such: debug(), error(), fatal(), info(), log() or warn() is called.

The steps required to use the logging system are the following:

1. Registering the classes for logging:

The code above will register the class Foo under the package com.daveoncode and then it will broadcast a debug and a warning message

2. Initialize and configure a logging target such TraceTarget (typically in the main class):

The code above will print log messages of all “subscribed” classes inside the package com.daveoncode, including all information available (date, time, category, level)

3. Add the target to the logger:

The previous steps can be repeated as many times as we need, in order to registering several classes and several targets (perhaps with different filters and info settings).

How to extend the framework

To extend the framework we can create new target classes, which print LogEvent data to different location and display data as we like. In my experiment I created a “mini subframework” which can print logs to text files or html files. I created the following 7 classes:

1. LogFileTarget
2. IStreamDataWriter
3. AbstractDataWriter
4. PlainTextDataWriter
5. HTMLDataWriter
6. InvalidLogFileTargetError
7. UnsupportedWriteModeError

The first, as the name suggest is a custom target class, which extends LineFormattedTarget (a target class available in Flex’s framework), it has a parametric constructor which allows the user to choose the name of the file, its directory, the type of file (txt or html) and the charset that will be used to write the file. IStreamDataWriter is an interface which simply declares one method called writeData(), the main purpose of this interface is to use it in polymorphism. IStreamDataWriter is implemented by AbstractDataWriter as an abstract method (abstract is not supported yet in as3, but is treated as abstract), this class also has a secondary method which is used by two subclasses PlainTextDataWriter and HTMLDataWriter. These classes have the duty to physically write data to the file by handling the event received by LogFileTarget which delegates the business logic to them and are used based on the writeMode configuration of  LogFileTarget, which for ease has two public constants called MODE_PLAIN_TEXT and MODE_HTML. InvalidLogFileTargetError and UnsupportedWriteModeError are obviously two custom error which are both (potentially) thrown by LogFileTarget.

This is a sample code using my own classes:

Of course this experiment will works only in AIR applications, because we need to use flash.fileystem classes.

These are the two different output that my classes will generate:
Text file
HTML file

The cool aspect of html version (LogFileTarget.MODE_HTML) is that you can filter by log type :)

If you want to use or take a look to my experiment, feel free to download my logging package here (let me know your opinion)

In conclusion Actionscript and Java have a  lot of stuff in common, the syntax and structure is quite the same, except for some issues like abstract classes and methods, multiple methods and constructors declaration (override). The main difference is that Java provides an huge number of Classes that Actionscript doesn’t, however it seems not so hard to translate Java code and implement Java functionality in Actionscript.

I hope I won’t have to deny my words :)