> One more thing, in the old Thinlet, you could always grab a handle to an > object by it's ID (every element in their xml had an ID attribute) as long as > you provided an ID attribute. It was something like > "desktop.getByID(my_item_id)". ... > With Pivot, you have to explicity set a variable when the serializer is > running. Is there a big cost to storing a map of all IDs ? Just an idea.
It's not so much a cost issue as a design one. WTKX IDs are a WTKX construct, so they are only relevant within the context of a WTKXSerializer. Other means of loading a Pivot UI (such as a Groovy builder) may use a different identifier scheme. So, outside of WTKX, there isn't a concept of "global" IDs across all components. Note however that, if you use WTKXSerializer.bind() or the Bindable interface, you don't generally need to work directly with WTKXSerializer#get() at all. Using this approach, WTKX IDs are simply mapped to Java member variables and are easily accessible in code. > With this you were able to provide the scope of the seach with another > argument, just in case you were using duplicate IDs in across larger > components. WTKXSerializer IDs are partitioned by include IDs. An include that has an ID creates a separate namespace, whereas an include without an ID inherits the parent namespace. You can refer to nested elements using a dot-delimited namespace path to the element; e.g. foo.bar.myButton refers to the element with ID "myButton" in the nested includes with IDs "foo" and "bar". The path is relative to the root serializer on which you invoke the get() method. You can also use this syntax within an @WTKX annotation, via the "id" property. G
