Bridge abstract superclass

[Michael Turyn <MT...@nexaweb.com>]

"Right governance begins with the proper naming of things," ---K'ung
fu-tzu

I named AbstractBlackBoxWidgetBridge that way because
1.) It was to be a powerful but abstract superclass
2.) ...for widget bridges...
3.) ...which was to be free of direct method call on the widgets---I had
had a lot of trouble adapting Dojo bridges to the extant bridges code
because the latter embodied assumptions about methods on the widget
peers---I wanted to create something that other bridges could refer to
without needing the know anything about the peer, hence the "Black Box".

Accurate, but ungainly; anyone have a better choice, or think the
current one's good enough?  

I'd vote for "AbstractWidgetBridge".


Also:  the method that formerly always created a peer, "createPeer", now
doesn't always do so---for example it often calls "obtainPeer" which
either creates a new peer (the Dojo widget bridges) or resolves an
extant one (e.g., an HTML dom node, or the as-yet unchecked-in
ExternalWidgetBridge).  I'd like to rename it to something like
"setupPeer".  Any opinions?

RE: Bridge abstract superclass

[Peter Yee <py...@nexaweb.com>]

I second AbstractWidgetBridge.

Also, I think for any classes related to xap, we don't need a xap
folder.

For instance, xap.bridges.xap.ComboBox can just be xap.bridges.ComboBox

Peter Yee

-----Original Message-----
From: James Margaris [mailto:jmargaris@nexaweb.com] 
Sent: Monday, September 11, 2006 7:45 PM
To: xap-dev@incubator.apache.org
Subject: RE: Bridge abstract superclass

 
AbstractWidgetBridge sounds fine.

I was also thinking if we should get rid of the "Bridge" postfix, as
they are already in the "bridges" package.

setupPeer() also sounds fine to me.

James Margaris
-----Original Message-----
From: Michael Turyn [mailto:MTuryn@nexaweb.com] 
Sent: Monday, September 11, 2006 11:36 AM
To: xap-dev@incubator.apache.org
Subject: Bridge abstract superclass
Importance: Low

"Right governance begins with the proper naming of things," ---K'ung
fu-tzu

I named AbstractBlackBoxWidgetBridge that way because
1.) It was to be a powerful but abstract superclass
2.) ...for widget bridges...
3.) ...which was to be free of direct method call on the widgets---I had
had a lot of trouble adapting Dojo bridges to the extant bridges code
because the latter embodied assumptions about methods on the widget
peers---I wanted to create something that other bridges could refer to
without needing the know anything about the peer, hence the "Black Box".

Accurate, but ungainly; anyone have a better choice, or think the
current one's good enough?  

I'd vote for "AbstractWidgetBridge".


Also:  the method that formerly always created a peer, "createPeer", now
doesn't always do so---for example it often calls "obtainPeer" which
either creates a new peer (the Dojo widget bridges) or resolves an
extant one (e.g., an HTML dom node, or the as-yet unchecked-in
ExternalWidgetBridge).  I'd like to rename it to something like
"setupPeer".  Any opinions?

RE: Bridge abstract superclass

[James Margaris <jm...@nexaweb.com>]

 
AbstractWidgetBridge sounds fine.

I was also thinking if we should get rid of the "Bridge" postfix, as
they are already in the "bridges" package.

setupPeer() also sounds fine to me.

James Margaris
-----Original Message-----
From: Michael Turyn [mailto:MTuryn@nexaweb.com] 
Sent: Monday, September 11, 2006 11:36 AM
To: xap-dev@incubator.apache.org
Subject: Bridge abstract superclass
Importance: Low

"Right governance begins with the proper naming of things," ---K'ung
fu-tzu

I named AbstractBlackBoxWidgetBridge that way because
1.) It was to be a powerful but abstract superclass
2.) ...for widget bridges...
3.) ...which was to be free of direct method call on the widgets---I had
had a lot of trouble adapting Dojo bridges to the extant bridges code
because the latter embodied assumptions about methods on the widget
peers---I wanted to create something that other bridges could refer to
without needing the know anything about the peer, hence the "Black Box".

Accurate, but ungainly; anyone have a better choice, or think the
current one's good enough?  

I'd vote for "AbstractWidgetBridge".


Also:  the method that formerly always created a peer, "createPeer", now
doesn't always do so---for example it often calls "obtainPeer" which
either creates a new peer (the Dojo widget bridges) or resolves an
extant one (e.g., an HTML dom node, or the as-yet unchecked-in
ExternalWidgetBridge).  I'd like to rename it to something like
"setupPeer".  Any opinions?