Ah, right. On Mon, Jun 7, 2010 at 11:34 AM, Greg Brown <[email protected]> wrote:
> We still need automation IDs because they are added to a global map, > whereas names would not be. > > > > ----- Reply message ----- > From: "Todd Volkert" <[email protected]> > Date: Mon, Jun 7, 2010 11:25 am > > Subject: Component names inside the containers > To: <[email protected]> > > I think a getNamedComponent() would greatly increase the value of this. It > also opens up the question as to whether we need an automation ID *and* a > name - can the two be unified into one? > > -T > > On Mon, Jun 7, 2010 at 11:16 AM, Greg Brown <[email protected]> wrote: > > > I'm not even sure the container method or path syntax would be necessary > - > > AWT only provides get/set name at the Component level. A > getNamedComponent() > > method in Container wouldn't hurt, though. > > > > > > ----- Reply message ----- > > From: "Todd Volkert" <[email protected]> > > Date: Mon, Jun 7, 2010 10:58 am > > Subject: Component names inside the containers > > > > To: <[email protected]> > > > > If you allowed each component to have a name property, then you could add > > methods to Container to get children by their name (since the container > has > > a reference to all of its children anyway). That way, given a Container, > a > > caller could get, for instance, the "foo.bar.baz" descendant without > > requiring any global name lookup. The Container would have to linearly > > look > > at each of its children, but we do that elsewhere with methods like > > getComponentAt(), so I don't see any issue there. All in all, I think > it'd > > be a valuable addition without disrupting anything. > > > > -T > > > > On Mon, Jun 7, 2010 at 9:32 AM, Greg Brown <[email protected]> wrote: > > > > > 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 > > > >> H > >
