Wed 2 Sep 2009
The problem domain: An issue exists where in a modular application you want to be able to share events from different modules without creating a dependency between the two. Deeply nested objects make this even more apparent when you realize you can’t use bubbling since they don’t reside within the same branch line down to the root trunk.
Mon 11 Feb 2008
There are times when it becomes important that we step back from our work to really understand when / where / how patterns are applied. However, where I think many of us fall short, is more importantly is when NOT to.
Like any great pattern that is meant to simplify and organize, they can abused and overused. Remember, a pattern is really nothing more than a general solution to a particular problem set that has been previously solved. So for many cases, this is a godsend, because it means less time can be spent on the implementation and more time can be spent on the UI, aesthetics, and over all product improvements. (more…)
Fri 10 Aug 2007
One of the things that I’ve noticed with the SDK that is hit or miss, and can probably be attributed to a slew of different developers working on various aspects, is most event handlers are written in the private space especially if it’s a top level component.
This is not good design especially in light of the news that Adobe has announced it will make the SDK apart of its open source initiative with staring with Flex 3. The simple reason why is extensibility. Most projects are made up of at least 1 and probably up to several dozen custom components that extend off the SDK architecture. FlexLib is a prime example of this. With privatized event handlers, this makes it impossible to write an extended object that needs to intercept and enhance a given event. Duplicating the event by assigning the same event to a different handler achieves a work around however this essentially only adds overhead and to the overall confusion of trying to keep track of duplicated events.
Writing the handler to the protected space is a far better solution. It offers the same security protections of not allowing other objects to mistakenly execute the method, but allows the integration of an event hierarchy to become seamless. It also gives one added underrated benefit: event polymorphism. The encapsulating owner now has conditional execute privileges over the super method, which gives rise to writing controllers a lot easier to manage.
Mon 6 Aug 2007
When I first started migrating some of my old AS2 code that I wanted to use and update for the AS3 world, these are some of the problems I have run across.
One of the biggest and most publicized differences in the new features is the access modifiers. There are some subtle differences here for those who have a Java background.