UIObjects stored as private variables in Flex
First the disclaimer so as to set the tone of "creative criticism" and not "whinny flex community member". I make my living from the flex framework and both enjoy (mostly) and am great full for it.
Now for the issue at hand. I have come across it a couple of times again in the last few days when extending Flex components. I have seen it again and again. And when you commonly see developers copy and pasting almost complete classes just to extend/change a small part of a component, you know somethings wrong.
I am talking about UI elements being defined as private in controls. Using a private definition on the reference to a UI object restricts my ability as a developer to extend all the hard work the Flex engineers have gone to making "extendable" components. This breaks the along the entire chain of inheritance ( which is the main technique used by flex as opposed to composition). But with a protected definition I can extend that class and either override the correct method of the parent class and change whats happening or use event listeners. Point in case the knob in the class BoxDivider (used in a VBox etc). Its defined private, and yet I would have thought that it would be a likely case that somewhere down the line someone will want to add some functionality to it. With a visual user interface for use on the web the visual aspects are very likely to be changed/extended to some extent.
So why not move to protected as the default. This would allow a lot more extending of components in a lot more ways, while still keeping the OOP ideals of each component only aware of its own objects and being self contained.
I mention this really just to start some discussion and let the great team of developers at Adobe know of some of the frustrations I hit as a flex developer. Does anyone else hit this? or am I a 3 legged mutant.
I have foolishly devised a temporary fix for this which you can use to help when hitting this problem, while we as a community subtly prod the Flex development team at Adobe to change. It can be seen working HERE. (view source enabled and proudly built with degrafa)
P.S. Adobe Flex developers – I love your work by the way guys!
I make my living also with flex, but that doesn’t mean I have to kiss ass. Flex is a nice framework to work with, but it’s just too heavy most of the times…. There should be a Flex lite version. So let me “whine”, and build some usefull stuff.
“And when you commonly see developers copy and pasting almost complete classes just to extend/change a small part of a component, you know somethings wrong.” There is nothing wrong with that, why invent the wheel twice… Just take the idea, adjust it and give the builder, creator of the class enough credits!!! Don’t tell me you still ride a horse to work!?!
Anyway keep up the good work!!! Everything to improve Flex!! ONE!
Hahaha Hey Maikel, Nope I walk downstairs to my office
A horse would be a cool break from the norm though.
“There is nothing wrong with that, why invent the wheel twice”… exactly my point. Why would I want to maintain 300 lines of code in a copy of a class when I can just extend and override if done properly, and can take advantages of all the typing that comes with extending. You can run into a lot of problems with casting when creating your own com.xsive.DividedBox and a parent UI container expects a mx.containers.DividedBox.
As for kissing ass, I prefer to think of it as not pissing people off so they listen to my whines and might change things
HaHa…. your right!! But…. within the cummuninty there are so many people talking about how great flex is. They have to be realistic and see flex is not all that.
In a way you know I’m right. And in a way I know you are right!!
Touche’ Maikel, I agree.
I got an invite to preview LiveStation a p2p video streaming app done with Silverlight, and my first thought was why cant I do this with Flex and AIR, but the answer is not without a lot of hacking (limits in AIR and socket listeners mostly, but thats another blog post) and would it be better? I doubt it.
If anyone wants to try by the way email me for an invite – campbell at xsive dot co dot nz
If anyone wants to try to email me also for an invite – info@flexcoders.nl
I’m not trying to be obtuse, but can you explain what in particular in your code serves as a workaround to overcome the limitation of a privately declared UIObject?
Thanks,
Joseph
Lol Joe, It doesn’t, it’s a joke mate!
Once a UI component is added to the stage, you can always get to it using the Children method, right? Maybe composition would be a better solution to “Extending” the component?
It may open up a whole slew of other issues, though…