(My apologies to my colleagues at Nexaweb, for whom this might be the
third time they hear me spout about this stuff; this represents my
views, not necessarily Nexaweb's or theirs.)
When I started working on bridges to dojo widgets, I became aware that
there are places in the code where bridge objects talk to peers owned by
other bridge objects. This requires making certain assumptions about
the methods those peers can understand. I also saw that the bridges
themselves end up looking very different from each other when created
for differing toolkits; it made me think that there might be
widget-oriented bridge functionality that could be separated out from
the necessarily toolkit-specific parts of the code.
I would propose that bridges should not ever speak directly to
peer-class objects, but rather only to other bridges. This would mean
that each bridge would have to implement a well-defined API that will
allow this---I believe at least "getPeerDomNode()" method to allow you
place one bridge's peer under another's (this is done on creation right
now, see <any_bridge_class>.createPeer().
Since we don't have Java's interface mechanism, I would further propose
the following structure:
<Widget>Bridge --- can speak to any other such
...owns a <toolkit><Widget>Adapter --- fits a widget from a particular
toolkit to the bridge's needs
...owns a <toolkit><Widget> --- the specific toolkit's object
(peer)
Example: to set the label on a button, ButtonBridge will call
aDwtButtonAdapter.setLabel(), which will
call aDwtButton.setText()
...or...
aDojoButtonAdapter.setLabel(), which has
to muck around with
a dojo button's
internals to set the caption, there being
no simple setter to do
this.
...or...
aSomeFutureButtonAdapter.setLabel(),
which is designed for an interface for
the blind and literally
tells the user when her button has a new label.
ButtonBridge is basically a generic button.
At best, it would ease interoperability between toolkits; at least, it
would provide a cleaner top-level model, and make it easier to swap out
objects from under the bridges
How important is interoperability? There might be little need to for
allowing the use of several different text-fields from different
toolkits. People might want to steal (in the benign sense) pieces of
other applications and try to fit them together, but for the most part I
believe that people will prefer to stick with one toolkit for the basic
html elements' wrappers. I think interoperability will be needed for
widgets with new and disparate functionality, e.g. the Yahoo map widget
paired with JRandomCoder's charting and analysis objects; for this, we
could at least have a generic widget allowing us to set bounding
rectangles and z-layers, something for layout managers to manage.
There is no immediate need to make a decision about this---maybe by the
time I'm done with Dojo bridges, _I_ would not want to do things this
way---but I wanted to throw the idea before the list for comment. I
intend to stop thinking about it until after the July 4th weekend....
========================================================
M. Turyn
Software Engineer, Nexaweb Inc.
"Enterprise Web 2.0 Solutions - Thinner, Richer, Faster"
