Just thinking about this a bit more - I don't see any reason why a "name" property couldn't be added to Component. AWT's Component class has one, and I don't believe the names are added to any kind of global map. This seems like it might address the original use case and wouldn't carry any of the negative implications described below. Thoughts?
On Jun 7, 2010, at 8:16 AM, Greg Brown wrote: > I stand by what I said about IDs being like Java variable names. A class > instance knows no more about the variable name or names that refer to it than > an object defined in WTKX knows about its ID. An ID is simply another kind of > variable name. > > Even if we did make it possible for a Component (or arbitrary object > instantiated in WTKX) to become aware of its ID, the ID wouldn't be of much > value unless it was added to a global ID-to-component mapping table (so it > could be used to look up components). There are a couple of issues with this: > > 1) WTKX IDs are only guaranteed to be unique to the page in which they are > defined (i.e. they are not globally unique). It we define multiple Components > with ID "foo", we have no way to uniquely identify "foo" A vs. "foo" B. > > 2) It is prone to memory leaks. > > So again, I would suggest that this is not a good idea. > > > On Jun 7, 2010, at 5:47 AM, Dirk Möbius wrote: > >> Since the same discussion has raised up a couple of times now, I suggest you >> again to reconsider adding an 'id' property to wtk.Component. See this >> thread: http://www.mail-archive.com/[email protected]/msg00686.html >> My use case given there was not a good example -- this one is. It seems >> strange to add a whole new palette of subclassed components just to add an >> id property because Component hasn't one. >> >> Dirk. >> >> >> Greg Brown <[email protected]> wrote: >> >>> One option would be to use the "automationID" property of Component. >>> However, I think a better approach would be to define a custom subclass of >>> whatever container type you are using, make it Bindable, and add getters >>> (but not setters) for each of the components you retrieve from the WTKX >>> file. That way, you get type safety and you don't need to maintain two >>> different identifiers for your components. >>> >>> On Jun 6, 2010, at 11:09 AM, aappddeevv wrote: >>> >>>> I was looking to pass in a container to a method and then pull a few >>>> components out by name (the container has a complex view and the >>>> components I want to access by name are labels, a few labels out of many >>>> labels) to do some processing on. This way I don?t have to add property >>>> setters and getters in my container subclass. In my method, I don?t have >>>> access to the serializer to obtain the components by id. >>>> >>>> However, a component name (an optional) property would do the trick. Is >>>> there a way to assign a string ?name? to a component in WTKX and access it >>>> later? In this context, a wtkx:id acts much like a name but as near as I >>>> can tell the wtkx:id is only relevant as a named component in the >>>> serializer versus a property of the component itself. >>> >>> >> >> >> >> -- >> Dirk Möbius >> >> SCOOP GmbH >> Am Kielshof 29 >> D-51105 Köln >> Fon +49 221 801916-0 >> Fax +49 221 801916-17 >> Mobil +49 170 7363035 >> www.scoop-gmbh.de >> Sitz der Gesellschaft: Köln >> Handelsregister: Köln >> Handelsregisternummer: HRB 36623 >> Geschäftsführer: >> Dr. Oleg Balovnev >> Frank Heinen >> Dr. Wolfgang Reddig >> Roland Scheel >> >> >
