Monthly Archives: July, 2009

MXML Graphics: Verbose syntax for Path is gone

As of last week, the Flex SDK removed support for the ‘verbose’ syntax for creating Path data. In the past, you could create a Path using two methods:

short syntax, just using the ‘data’ property:

<s:Path data=”M  9 0 L 9 55 L 70 55 z” />

and the long “verbose” syntax which was more readable:

<Path>
<segments>
<MoveSegment x=”9″ y=”0″ />
<LineSegment x=”9″ y=”55″ />
<LineSegment x=”70″ y=”55″ />
<CloseSegment />
</segments>
</Path>

The long syntax is no longer supported. Here is more information, if you want to know the reasoning behind this change:

http://opensource.adobe.com/wiki/display/flexsdk/Verbose+Path+Syntax

Also, here are additional changes that Deepa mentioned in her check-in notes for svn 8589.

1. Path.segments property removed. In its place, there is private variable (segments) which holds the path data parsed into the correct segment objects.

2. Path.segmentChanged() removed ?\226?\128?\147 Segments do not need to notify the parent path when their properties have changed since they are now not individually accessible.

3. PathSegment.segmentHost property removed ?\226?\128?\147 Segments do not need a pointer back to the parent Path since now they are now not individually accessible.

4. PathSegment.notifySegmentChanged() removed ?\226?\128?\147 Segments do not need to notify the parent Path they have changed since they are now not individually accessible.

5. PathSegment.dispatchSegmentChanged() removed ?\226?\128?\147 Path segments do not need to dispatch propertyChange events since they are now not individually accessible. As part of this, I have removed the [Bindable] and   [Inspectable] metadata from all PathSegment properties.

6. PathSegment no longer extends EventDispatcher, instead it extends Object.

7. All of the PathSegment and derivative classes no longer have getters/setters for their properties (like x, y, etc) since these properties are now not dispatching property change events.

8. A variety of checkintests/sparkTest project files have been updated to use the compact syntax as they are drawn/transitioned between state changes. Refer to sparkTest/AddItemsTest.mxml and RemoveItemsTest.mxml for examples on how to use states and transitions to transform Paths through the data they are bound to (as opposed to modifying individual segments).

RSLs on by default in Flex 4

As of last week’s Flex 4 builds, using the framework RSL has now been turned on by default. If you compile with one of these builds, you will probably notice a difference in your start up time. If you are compiling a small Flex 4 application, the start up may be slower than it used to be. This is because the RSL takes some time to get parsed int he beginning. But, in the end, when you are building real life applications which are much larger, using the framework RSL should be extremely beneficial.

One problem that I did run into was when having RSLs on by default was when I had an application using runtime CSS. I documented this in bug SDK-22172. Not thinking, I compiled my css file with the defaults. Apparently, this is not recommended. My bug was marked “Not a Bug” and I was given this advice:

“CSS modules are loaded into the same application domain as the application that loads them. Assuming the application has loaded all the needed RSLs, then CSS modules do not need to load RSLs. In this scenario the CSS modules should be statically linked and also externalize the swcs linked as RSLs in the main application. Swcs are externalized by adding them to the compiler’s “-external-library-path” option. The amount of benefit depends on how many classes are referenced in the css file.”

By the way, if you want to compile an application without using rsls, you would add the compiler argument: -static-link-runtime-shared-libraries=true