pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: Component names inside the containers
Date Mon, 07 Jun 2010 15:34:39 GMT
We still need automation IDs because they are added to a global map, whereas names would not
be.


----- Reply message -----
From: "Todd Volkert" <tvolkert@gmail.com>
Date: Mon, Jun 7, 2010 11:25 am
Subject: Component names inside the containers
To: <user@pivot.apache.org>

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 <gkbrown@mac.com> 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" <tvolkert@gmail.com>
> Date: Mon, Jun 7, 2010 10:58 am
> Subject: Component names inside the containers
>
> To: <user@pivot.apache.org>
>
> 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 <gkbrown@mac.com> 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/user@pivot.apache.org/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 <gkbrown@mac.com> 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
Mime
View raw message