Rick -- flex doesn't support any sort of dynamic getElementById()
lookup the way HTML does. You'll have to write that yourself, using
Regarding filters...you'll seend to submit a bug, there's no reason
why that shouldn't work (could be pilot error of course
I was under the impression that with most MXML containers, you can use this[id] to get a reference to the object dynamically, such as this['myThing'], and of course getChildByName('myThing'). This works with statically or dynamically created display objects. Except with Spark. :-(
I had assumed that such a mechanism would work with Spark, but it appears not - as a side effect of the child <-> element different in terms of managing and accessing the container children. Out of curiosity, do you know why didn't Spark get an "getElementByName()" method as an analog to MX's getChildByName()? I assume it is due to the underlying collection type being used to manage the display list. Just curious.
The issue with filters seems to apply to any filters added at runtime - they never seem to render. I'll see if it is pilot error, and if not, I'll report a bug.
That should only work with objects that were provided an id at compile
time, as the compiler will ensure a slot (property) on the owning
document corresponding to that declaration.
this['myThing'] only works if myThing was statically declared in the
MXML document, I believe.
getElementByName -- I think it's just not implemented out of a belief
that there wasn't a general need for it. It's something that could be
added to containers, if the community wants it.
No worries. It's easy enough just to create another object to hold the references to the dynamically created objects, keyed by name. That said, it would be very useful to have the ability to use "getElementByID()" on any container to grab a reference to any statically or dynamically created component by its id. I suppose the companion capability is to have the Application (or other appropriate container) include dynamically created components in that list. There are definitely workarounds today, though.
We (and quite a few others, I'd think) have been dynamically generating UI's at runtime using ActionScript, and this capability is really useful for wiring together events, data binding, setting/getting properties on selection events, and so on. We'd used it in Flex 3 to link UI components (and their underlying HTTPService data providers) together "on the fly", and it works fine with a little bit of reflection and invocation magic. We'll just extend our custom classes to maintain a list of dynamically added Spark graphics primitives so that we can animate them in a similar manner.
If you're wondering, the main reason we have to do the dynamic UI creation is because we want to provide a higher level UI authoring environment to the end user, rather than Flash Builder/Flex Builder, with more of a drag-and-drop, wire things together sort of metaphor. It generates "pseudo-MXML" which then gets processed at runtime. We had explored dynamic generation of "real" MXML and/or inline compilation, but we needed a solution that would run on .NET platforms as well as Java/JSP platforms. I'm guessing there's no plan to provide programmatic or inline MXML compilation for .NET.
I think we have a workable solution for now, though.
Here's an update on the dynamic assignment of filters issue: You cannot add or remove individual filters using ActionScript - you can only replace the entire filters collection en masse. If you do so, the display object will render properly. However, manipulating the filters array by adding or removing filters will not work. Let's consider it a "known feature"...