addProperty bug

Just thought I'd blog this. It's just one of the many obstacles that I've come across for making generic wrapper classes. In short, If you use addProperty to create a getter/setter property in a Class prototype, it cannot retrieve or set another getter/setter of the same name, if that property was also created in a class prototype. I have worked around the problem to make the properties call the getter or setter function explicitly, if it exists, rather than requesting the property. This all adds a lot to the complexity and stops my implementation from being quite as intuitive as it could have been, as well as adding extra code to be processed each time a variable is retrieved or set.

See the FlashCoders thread for more info.

New Job

On monday I am starting a full time job with world archipelago. They seem like a great bunch of people with loads of interesting projects in the pipeline. Very soon, I will call London my home.

In preparation, I've spent the last month or so shedding clients, so that they will be easily manageable in my weekends and friday off. Although I will be keeping a short client list, it marks the end of an era and its a bit weird to think of myself as an employee. But, while I recommend freelance work, it doesn't provide all of the benefits that you might expect; or at least, it hasn't for me. It seems that there are two possible states for a freelancer: nothing to do, or too much to do. I'm looking forward to a predictability in both my income and my free time. Bring on the mortgage! ;-)

DevCon comes to London

Don't be put off by the name, CF-Europe is as much about Flash as it is about ColdFusion, and is being described as the European equivalent of DevCon.

There will be many well-known figures speaking, and I heard a rumour that Jeremy Allaire will be making an appearance. Aside from all the organised sessions, there are few better opportunites to spend two solid days with so many talented developers.

DRK Breeze Presentation

This is worth watching, just to see Mike Chambers in a Kung Fu pose on slide 6.

Update: Mike is running a contest to make the best spoof of the Marketing campaign, featuring him.

Macromedia DRK Sales Strategy

I find Macromedia's strategy for the DRKs quite interesting. Obviously they want to encourage people to subscribe to DevNet, so staggering the individual DRK release by three months makes sense. But I would feel more comfortable about it if they would release the kits, or at least the Flash components, for free after a further period of time, let's say another three months.

At the moment developers cannot use the components as assets in their own components, or give out source code which makes use of them. If, in six months time, they made the components free then both of these would be possible. As it stands, I think that it limits the creativity of the open-source community.

Imagine the scenario; a developer wants to build a component, which is basically the same as a DRK component, but with extra functionality. The obvious thing to do is to make a subclass of the DRK component or wrap it in another. However, that means you can't sell it or even distribute it for free. Now, assuming honesty, there are two types of developer. One will say "sod it, I'll use the existing component and not distribute it." The other will take the challenge and build it from scratch. But where do you draw the line? If you have seen the code for the component (and I always make a point of reading it), aren't you going to "reuse" some of it, even if unintentionally. And if someone steps over that particular grey line, are Macromedia going to ask the offending developer to withdraw the code, with threats of prosecution? Surely its ridiculous to ask someone to re-write code in a different way...

Whether people waste time re-writing or just don't bother, the community loses out either way. Can we avoid this, Macromedia?

DRK 3 released

The next DRK installment has just been released to DevNet subscribers. I think everyone else has to wait three months before it will be available for individual purchase.

I can't speak for the rest of the content, but the Flash stuff is immense; probably the best value DRK so far. I think this one will make the most difference to how we build forms. With the TextField component, together with the Data Validation Library, you can now build complex validating forms in just a few lines of code. The TabView, AccordionPane, WeekView and Slider are all excellent too. This lot were all built by Greg Burch and full credit is due for a great job (though not too much - it's not like he did it out of the goodness of his heart or anything ;-))

The Bevel Components also deserve a mention. They let you build OS-style layouts, with FStyleFormat support, very easily and are also good for quickly skinning your own components.

Check out all Greg's screenshots on his blog. Also, Mike Chambers has some more info about the rest of the CD.

Macromedia Firefly?

I'm not quite sure when this happened, but Macromedia have bought the Firefly Components from Cybersage Software, and will be selling them as part of it's upcoming Flash MX Data Connection Kit, which is going to be announced this week.

That's an interesting direction for Macromedia to take because, while the Firefly components are easy to use, they rely on a very specific architecture and way of working. I uninstalled Firefly from my machine a couple of months ago because the beta has about 50 separate custom actions XML files, and Flash seems to have some kind of limit. Now I'm going to have to install it again to get up to speed.

Decorator Design Pattern

So many people have asked me about the Decorator Pattern, since I mentioned it, that I thought I would go in a bit deeper. I decided to build a generic class, which could be inherited from to make decorators for any class. The result turned out to be a lot more long-winded than I initially thought and I ran up against a number of unexpected obstacles. Firstly, I expected to be able to use __resolve for passing method calls on to the decorated instance, but this proved far too problematic when combined with any decent support for events. The problem being that I couldn't easily check to see if a handler exists without triggering it.

This escapade resulted in a whole new Pattern, which I needed to handle events in a Decorator. I named it the Parasite because it allows objects to feed off another object's existing events. It was inspired by the way that the ToolTip Component preserves a MovieClip's existing mouse handlers, while "borrowing" the event for its own use. It's similar to the Observer Pattern, except you apply it externally and it feeds on specific events, rather than all the events sourced by the target. The target object does not know that it has a parasite attached which reponds to the event and broadcasts it, without affecting the target's own handler. This is important for the Decorator because it allows multiple Decorations to be layered on a single instance and use the same events as each other, without conflicting.

I have created Decorator subclasses, MovieClipDecorator, ButtonDecorator and TextFieldDecorator, which are designed to be further subclassed, to add Decorators to MovieClips, Buttons and TextFields. I will post the code when I have done some further testing.