Flex headaches

I had been planning to post late last night, but I was too tired. I was working on implementing project creation; I finished this just a few minutes ago. I hadn’t expected it to take so long, but my initial sense overlooked the fact that I needed to implement some permissions checking along with actually creating the project. I also ran into a few roadblocks along the way.

The first roadblock was trying to get a combobox to display the right field. We have, effectively, an array of CompanyPermissions objects, but we only want the company name displayed in the combobox as the other information is irrelevant to the context. Turns out this is pretty easy to fix: just specify a labelField.

The second roadblock was caused by me not remembering code that I wrote last week. I screwed up a few things, like checking $_SESSION['username'] instead of  $_SESSION['user']. This turned out to be a good thing though, because it forced me to reconsider my error handling mechanisms when I needed to debug. I created some utility functions for permissions checking and initially had them return a boolean indicating whether the user can perform the action, or null if the check failed for some reason. Of course, returning null makes it pretty hard to pass anything back that might explain WHY the check failed. It occurred to me that exceptions would be a nice way of handling internal errors, so I did a Google search, and lo and behold, PHP has exceptions! So instead of returning null, we now throw an exception instead.

The third roadblock (well, it was actually the first chronologically, but it’s much more exciting to save the best for last) nearly caused my jaw to fall off. I had been using a HashMap to store the company permissions in order to make accessing them by name easy. We aren’t using that functionality yet, but I expected it would be handy later. Instead, it caused a problem because ActionScript doesn’t have generics.

Yep, you read that right. No generics. Every other strongly-typed modern programming language I can think of has generics, although they may call them something else (generics is the Java term). This is very annoying, because it means that when you put something into ANY collection, when you go to take it out, you get it back as a generic Object instead of the class it actually is. You can cast, but this only ensures run-time type safety, not compile-time type safety. The only other option is to subclass the collection class and add methods that will return the more specific object type, but this still doesn’t really solve the underlying problem. I’ve opted to go with this since Flex auto-generated it for us, but it still irks me.

What’s worse is the fact that in Flex SDK 3.4, Adobe sort of but not really added generics. There’s now a Vector class that takes an object type, but that’s it. You’re not yet allowed to create your own generic classes. I can’t imagine why they would implement a half-baked solution like this; probably they’re not actually implementing generics, just achieving the effect using some mad haxx.

In other news, I also worked on the test deployment procedure a bit. The database stuff is mostly nailed down, so now I just need to add the FTPing to the build script and we’ll be where I initially wanted to be. I’ve noticed that there is an Ant task for talking to SQL servers and now I’m wondering if it’s feasible to include that in the test build as well. This might be more work than it’s worth though; I need to investigate further. In any case, this isn’t on the top of my list, since we have a procedure that works, even if it’s not as automated as I’d like. Implementing project editing is up next.

Advertisement