new as3-xpath build 0.2.4 released

We just released a new build of the XPath library. It's just a couple of small bugfixes, and tweaks, but if you are using it already, you might like to update to the latest 0.2.4 release.

mxml syntax proposal for styles and events

Don't you think it's a bit funky that you set styles in exactly the same way that you set a property in MXML? And isn't it a bit confusing that you add an event listener in exactly the same way too? Actually, it's not that confusing. It's pretty cool and works quite nicely - I couldn't really see a better way. Except, I'd like to tweak it a little bit...

The first problem is, you can't have a style or an event named the same as a public property, if the object is going to be used in MXML. The other problem is that, when you look at some MXML code, and you see various attributes being set, you can't immediately tell if it's setting a property, listening for an event or setting a style. Events listeners are nearly always added in-line, and there are quite a few cases where it is better practice to use in-line styles instead of CSS (ask me after class). So, all in all, it's not a rare consideration. A third problem isn't so important to you and me, but the developers who create MXML editors would be able to simplify some of their code if they could depend on a namespace instead of having to figure out if a given attribute represents a property, style or event.

My suggestion is a very small change to what we have already. Adobe should simply define a namespace for events and another for styles. The Flex compiler does something completely different with each of these, so the namespaces should help Adobe to simplify their own code too.

Here's an example of what it might look like:

  <mx:VBox style:verticalGap="3">
     <mx:Button event:click="onClick(event)" />
  </mx:VBox>

The extra namespaces would have to be declared at the top of every MXML file that used them, but that is not a big deal if that is mostly generated by a decent editor.

I made a bug report for this a while back, but never thought about it again. So feel welcome to vote for it if you agree that it's a good idea. Also on the report, I suggested how the same feature could be extended to allow some interesting custom extensions to MXML, by handling attributes in custom namespaces.