Flex Pasta

It has been about a year now since Adobe announced it was open sourcing the Flex SDK, BlazeDS, and the Flex Compiler.  Today on my way home, I started thinking about improvements to the Flex Open Source Adobe that I would like to see in the future.

5.  Upgrade LCDS/BlazeDS to Java 5.

I am not sure the reasoning for having BlazeDS written in Java 1.4.  Most projects using Flex are going to use Java 1.5 since they are most likely newer software.  If for whatever reason, BlazeDS to Java 5 is not viable, at least create a separate Java 5 project that extends the BlazeDS code base.  This project could use features of Java 5 to give developers more tools.  In particular, annotations with remote objects would be a huge advantage for developers.  Bean property configuration, service method security, better enum handling, code generator support, etc would all be great.

4.   Bring the Flex Compiler Source Code out from the shadows

After attending MAX last month, I heard little about improvements to the Flex Compiler for Gumbo.  I guess the compiler isn’t the sexy part of Flex so maybe that is why.  But the compiler is just as important as the Flex SDK itself, so I would love to understand how it works.  I think the community would benefit with more exposure to the compiler code base.

3.  Make it easier to set up the Flex SDK, BlazeDS, and the Flex Compiler for local builds

The most looked at code base of the three components is probably the Flex SDK, just because we can hit F3 in eclipse and go look at the source code.  However, how many people out there(other than Adobe employees) know how to check out the source code for the Flex SDK, BlazeDS, and the Flex Compiler and then be able to make changes to the code?  I have been able to do it for the Flex SDK and BlazeDS, but it took some time(I also don’t think my config was ideal).  I spent a couple of hours trying to figure out the Flex Compiler with no luck.  I am hopefull for a little documentation for those of us out on an island trying to set it up.

2.  Improve the ability to run different versions of the Flex SDK

If you go out and download Flex Eclipse plug-in site today, you will probably get Flex version 3.2.  The rest of the development team might be using another version; say version 3.0 on the project.  Figuring it might be a good idea to have the same version of Flex as your coworkers, you visit opensource.adobe.com to download version 3.0.  The nice interface in FlexBuilder lets you have multiple Flex SDK’s installed and you can easily flip the compiler between different versions of the SDK.  One problem: Charts.  When you download the plugin, you get the charts bundled with the source code, but when you download releases from the open source page, charts are left off(I’m not sure the reason).  This means a project using charts won’t compile for you without some hacking to get it to work.

1.  Avoid using mx_internal/private in the Flex SDK

There are important instances where the private keyword is usefull(when I don’t want a subclass to override it or even be able to call it).  However, and I admit to doing this as well, we tend to use the private keyword by default when we don’t want a method to be public.  The protected keyword would be a much better option for the majority of methods in the Flex SDK.  I have found it difficult at times to extend Flex components and even BlazeDS code because the methods are private or mx_internal.   Maybe it was the intent of the authors to keep these methods private to avoid future upgrade hassles, but it can be problamtic to extend them.  My latest example of one such problem involves creating a ColumnChart.  I created the chart and had a ColumnSeries.  The chart was simple and I set the properties  labelAlign=”center” labelPosition=”outside”.  I was wanting to center the labels at the top of the bars on the outside.

As you can see in the picture, the labels are left aligned.  The as-doc states that labels on the outside can only be left aligned.  I want to try and extend column series to get the labels in the middle.  I find the method:

private function renderExternalLabels

I can’t extend it since it’s private.  Ok, so I find where renderExternalLabels method is called.

mx_internal function updateLabels()

This goes on for four or five methods before there is one that can be extended.  The point is that marking methods protected more aggressively can help everyone out who is trying to extend these components.

Those are my top five wishes for Flex Open Source.  What are your wishes?

I was using an embedded font today with modules and charts.  My embedded font is declared in the css file and is only referenced in the main application page and not in each module.  When embedding the font in the main application, I would expect the font to be carried over into each module, the same way all the other styles work with modules.  For some reason though, the labels on the axes of the column chart don’t appear when the chart is in a module using an embedded font.  I have opened a bug with Adobe regarding this issue.  I’m not sure if it’s the chart doing something weird or the Flex compiler(or maybe me!).  In any case, I don’t think the labels should disappear.

Run the example and see for yourself the behavior: Charting.swf

Panel 1 is a column chart declared in the main application and Panel 2 is the exact same column chart in a module.  There is an embedded font ‘Verdana’ in the main application.

Charting.mxml

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml” layout=”horizontal” xmlns:local=”*”>
<mx:Style>
Application
{
font-family: Verdana;
}
@font-face {
src:url(”font/verdana.ttf”);
fontFamily: Verdana;
advancedAntiAliasing: true;
}
@font-face {
src:url(”font/verdanab.ttf”);
fontFamily: Verdana;
fontWeight: bold;
advancedAntiAliasing: true;
}
@font-face {
src:url(”font/verdanai.ttf”);
fontFamily: Verdana;
font-style: italic;
advancedAntiAliasing: true;
}
</mx:Style>
<local:ColumnChart width=”50%” height=”100%” title=”Chart 1″/>
<mx:ModuleLoader url=”ChartModule.swf” width=”50%” height=”100%”/>
</mx:Application>

I was creating a custom component today.   I wanted to declare the component in mxml, but the component was not a visual component, just like the RadioButtonGroup class.  To create a non-visual component in mxml, just have the component implement the interface mx.core.IMXMLObject …. or so I thought.  Here is my component:

package
{
import mx.core.IMXMLObject;

public class MyNonVisualComponent implements IMXMLObject
{
public function MyNonVisualComponent()
{
}

public function initialized(document:Object, id:String):void
{
}

}
}

When I try and use the component, I get an error: Component declarations are not allowed here. (Note: visual children must implement mx.core.IUIComponent)

Wait a minute, I used the  IMXMLObject whose interface states:

The IMXMLObject interface defines the APIs that a non-visual component must implement in order to work properly with the MXML compiler. Currently, the only supported method is the initialized() method.

This is exactly how the mx.controls.RadioButtonGroup class does it too(Check out the source of it if you don’t believe me)!!!   So after an hour trying to figure out why something so simple doesn’t work I found my answer deep inside the compiler source code.  It appears the compiler gives special treament for RadioButtonGroup when it compiles instead of to IMXMLObject.

In flex2.compiler.mxml.builder.ComponentBuilder.java:

else if ((standardDefs.isContainer(parentType) && childType.isAssignableTo(standardDefs.CLASS_RADIOBUTTONGROUP)) ||
(child instanceof ReparentNode))
{
ComponentBuilder builder = new ComponentBuilder(unit, typeTable, mxmlConfiguration, document, component, null, null, true, null);
child.analyze(builder);
}

Therefore, unless I am missing something, I can’t create a non-visual component for mxml.  Thought I’d pass this info along to anyone else who is banging their head against a wall!

I opened a ticket with Adobe to fix the problem.