If one of the true signs of a vibrant developer community is an active blogosphere surrounding a technology, then the MX suite of technologies certainly passes that test with flying colors. In case you're not yet actively blogging yourself, MXDJ brings you here a comprehensive selection from some of the best known blogger-commentators (and some of the not so well-known too), by way of whetting your appetite.

Don't forget that you can blog yourself now, too, at the MXDJ site ­ just follow the link from http://mxdj.sys-con.com.

Blog Topic: The Acquisition
Macromedia and Adobe Not Sure If it's a Good Thing?
By The Blogster (http://williajay.linuxworld.com/read/1214759.htm)

"Being a user of Macromedia products for the last 15 years, I find the Adobe purchase to be a much better fit for Adobe than Macromedia. Macromedia has created such a wonderful web presence; Adobe has tried but hasn't come close. There is also the issue of support. I haven't had an issue with Macromedia's support, they have always been very patient and worked through my problems.

Over on Slashdot, they're talking about this: "According to John Dvorak the reasoning behind Adobe's recent (and to many, surprising) purchase of Macromedia for $3.4 billion is that Adobe was afraid Microsoft was going to do it first."

Blog Topic: Flash
Class Deserialization: OpenAMF & Flashcom
By Jesse Randall Warden (www.jessewarden.com/)

Had a hell of a time debugging some OpenAMF calls yesterday. Turns out, when Flash deserializes your class, it basically takes a vanilla object, puts properties on it and assigns their values, and then points that instance's __proto__ property to the prototype of the class you registered via Object.registerClass. The downside to this is it doesn't run your setter functions on any getter/setters you have set on the class. Naturally, your getters fail immediately because they look to a private equivalent variable which is different, and when you call the setter... it's really a function.

How Flash manages to keep "firstName" the public property and "firstName" the public getter function in the same namespace is beyond me, but regardless, I've tested in Flashcom last night, and the same thing happens there, too, so it appears to be how Flash deserializes your class.

The way we, "solved it" as my manager says, or "worked around it" as I claim, is emulating, EXACTLY the Java class equivalents. So, you have private properties in the Java model class, like:

private String firstName;

And same on the Flash side:

private var firstName:String;

And instead of getter/setter functions in Flash, you just use the get/set function methology:

public function getFirstName():String
{
return firstName;
}
public function setFirstName(val:String):Void { firstName = val; }

I really don't like this at all, and personally feel that there should either be an event letting you know when the class is deserialized (Flashcom does this for server-side ActionScript classes via the onInitialize event) so you can then run the getter/setters yourself, OR Flash should just intrinsically know there are getter/setters in place, and set the private variables accordingly. This gets sticky though because you're now having the Flash Player run code on your classes. Thus, I vote for the first.

Blog Topic: Flash
ProgressBar "Gotcha"
By Colin Moock from "moockblog" (http://moock.org/blog/)

"I just noticed this undocumented limitation with the v2 ProgressBar component, and I figured it was worth sharing...

When a ProgressBar's mode property is set to "event" (the default) it won't broadcast complete() or progress() events. if you want to register for events from a ProgressBar make sure its mode is set to "polled" or "manual". If you are using the ProgressBar in "event" mode then you should register for events with the ProgressBar's source rather than with the ProgressBar itself.

Have fun preloading..."