Archive for Flex 3
Book Review: Learning Flex 3
Posted by: | CommentsI enjoyed reading Learning Flex 3, by Alaric Cole… which is saying something, because there aren’t very many “Flex for beginner”-type books I can stand to read these days. Aside from being very easy to read as far as technical books go, here are a few things that really stood out:
First, the book is very well organized, and the content is good. The breadth and depth of material covered is perfect for a beginning level. He even goes over several different deployment scenarios toward the end. Off the top of my head I don’t consider deployment as a “Flex-related topic”, but as I read through it I thought about how many times I’ve answered questions on this very topic to people just starting on the journey. It was a nice touch.
Second, tutorial based approaches are very effective for beginners. Maybe I shouldn’t speak for everyone, but when I first start learning a new language or framework, I find tutorials to be very helpful. Once the developer has the confidence and basic understanding (that can be obtained through tutorials) then they can apply their own style and develop their skills further. Learning Flex 3 reads almost like the Flex tutorials on steroids. If you’ve done the tutorials on the Flex Builder 2 startup page (which is how I started out with Flex) then you’ll know what I mean. Just picture how those build on each other, and then stuff in about 5 times as much information, and you’ve got this book.
Third, the syntax highlighting. Anyone who has ever read a book full of code will appreciate how much easier the syntax highlighting is on your eyes, allowing you to focus on other things. As a side note, the Deitel & Deitel books started becoming intolerable for me when they started rushing books to press without syntax highlighting… it was hard enough to get through those books with the code highlighting and color breakouts, but without them it was just torture.
Fourth, there are color diagrams. Simon and Garfunkel are right. Though I definitely wouldn’t base my decision to purchase this book on the basis of color pictures, it adds a very nice touch and makes the book easier to read than an identical book with only black and white diagrams. I didn’t do the tutorials as I read the book, I wouldn’t recommend that to a pure beginner. Even in color, reading the code and looking at the pictures is not the same as typing it out and running it.
I highly recommend Learning Flex 3 for beginners who want to get their feet wet with Flex. I don’t recommend it to more advanced Flex developers, unless they just want to look at the color pictures.
Private Variables and Monkey Patching
Posted by: | CommentsI’ve been pretty busy the past two months finishing up a project for my client. I may have mentioned it before, but their creative vision is pretty intense (especially considering this is an in-house app… in my limited experience I’ve never seen so many resources allocated toward getting the look and feel of an in-house app to be just right).
Anyway, I’ve had to monkey patch approximately 10 Flex framework classes (for various reasons) in order to realize their vision. In each of these cases I’ve first tried to use inheritance or composition to achieve the desired functionality, mostly in terms of interaction. And in each of these cases I was unable to do so, and had to resort to making changes directly in a framework class which I maintain in an mx.controls.etc, etc structure with the rest of my project. I don’t think I need to point out the many evils that this exposes the project to, suffice it to say it’s not ideal.
I just wanted to make an observation as to why I was unable to use normal OOP techniques to achieve the desired functionality. The most common reason I have been unable to extend classes to do what I need is because there are too many private variables being used in protected functions. So if I need to tweak one line of a protected method, I can override it. However, assuming I don’t want to call super.methodName(), there’s no way to recreate the lines that interact with the private variables.
This leaves me two alternatives: 1) monkey patch the file to make the variable protected, or 2) monkey patch the file and just make the change directly to the method. I make that decision depending on whether I’m fixing a bug, or just adding functionality. Either way, it’s still a pain in the butt; and will probably be a bigger pain down the road.
Flex Menu Monkey Patch: Allowing a Branch to be Selected
Posted by: | CommentsSo the interaction designers decided that the branches of a menu needed to be selectable (picture a warped checkbox tree, only it’s a menu… and there aren’t any checkboxes). The default behavior of a Menu in Flex can be described as follows:
1. If you click on a leaf, the leaf is selected.
2. If you click on a branch, the sub menu opens up.
3. If you hover over a branch, the sub menu opens up.
I needed to change #2 to select the branch.
The first thing that I did was sublcass Menu (we’ll call it NewMenu), and overrode (with copies) two obvious methods on the Menu class:
override protected function mouseUpHandler(event : MouseEvent) : void override protected function mouseDownHandler(event : MouseEvent) : void
In those two methods you’ll need to remove any expressions containing something similar to the following:
_dataDescriptor.isBranch(item)
This will allow the branches of your sub class to be treated as leaves. The problem is that Menu class contains this line:
private var subMenu:Menu;
which forces all sub menus to be of type Menu– the only NewMenu will be at the very top! We need all sub menus to be NewMenus. So this is where the monkey patching comes in. You have to change subMenu to a protected variable. Then in your NewMenu class, you can override the function:
mx_internal override function openSubMenu(row : IListItemRenderer) : void
And change the line:
menu = new Menu();
to
menu = new NewMenu();
And you’re done! The reason you need subMenu to be protected is because later on in the method you assign menu to subMenu, and you couldn’t do that from a subclass when it was private. Voila. Interaction designers satisfied.
