I think that's a fair thought if you think of the id as a variable name trying to index into the universe of components. However, you can also think of an id as just a tag. I don't think that the need is to identify a specific element in the universe of elements with direct access, but as a tag that helps navigate the hierarchy and its most potent when used to construct paths through the component tree relative to another component.
I would think of the name as more of path segment in a URL. Having said that, since they would be optional, clients would need to ensure they give the components names (or autogenerate them in the serializer which is easy to do since as you know I like to fiddle with the serializer :-)). There are a couple of use cases that can be made much easier with "tags:" a) Managing menu contributions e.g. add "this chunk of menu" to the "URL/tag path" here. I know there is a "updateMenu" type API but I need to be able to declare menus statically (and dynamically) and get them into the right location without so much code. b) Adding any component chunks to containers. c) Finding elements to bind to. Whether its in pivot today or not, I don't want to have have all that boilerplate for styles that link to other component styles (as I was reviewing in the tree renderer). I would rather just tell my component color to bind to the color of a other component style automatically (or have inherited properties). To do this, I need to find elements by name in the tree. This allows me to layer in renderer templates more easily which will make theme customization easier. d) When passing around components, finding a tagged component that receives special processing without knowing the details of the sub-component. The contract of just having a named component is a good contract sometimes. e) I am actually most worried about memory misuse because the significant amount of listener/observer patterns that are employed especially with hard references. I think your comment is really in the context of a global component registry though. -----Original Message----- From: Greg Brown [mailto:[email protected]] Sent: Monday, June 07, 2010 8:16 AM To: [email protected] Subject: Re: Component names inside the containers 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 > >
