[Gwt-openlayers-devl] options for options

[Edwin C. <com...@gm...>]

Hi all,

In reaction to a recent issue that OptionsBase (the base class for specific
Options objects) doesn't expose it's setAttribute methods, while this can be
useful at times I have thought of 3 options for options:

A.) Let all XxxOptions objects extend Options directly. PRO: * direct access
to setAttribute methods; CONS: * Options is actually a way to construct an
arbitrary javascript object, while XxxOptions are not arbitrary javascript
objects (they are technically in OpenLayers, but not conceptually), but a
javascript object with specific properties (or attributes). * the code
suggestions in the IDE get cluttered by all the setAttributeXxx methods

B.) Let XxxOptions have a 'mergeOptions(Options options)' method that is
able to take an Options object on which arbitrary properties can be set, and
merge them (copy all the properties) with the XxxOptions object. PRO: *
XxxOptions can have the power of the Options object without having to expose
all the Options methods itself. * no code suggesting clutter; CONS: *
XxxOptions would need to still extend OptionsBase, so there will remain 2
classes which overlapping and thus one should be redundant. * It is
inconvenient for users to have to create two Options objects to set options
that were not foreseen by the GWT-OL API
Code Example Option B:
MapOptions mapOptions = new MapOptions();
mapOptions.setTileSize(new Size(300,300));
Options options = new Options();
options.setAttribute("zIndex", 1000); //fictional
mapOptions.mergeOptions(options);

C.) Let XxxOptions wrap Options and provide a getOptions method through
which arbitrary properties can be set. PRO: see B) CONS: needs one step more
to set an attribute than A) => although this is also an advantage since you
want user to have to set as less 'arbitrary' properties as possible and not
make it to easy for them to do this.
Code Example Option C:
MapOptions mapOptions = new MapOptions();
mapOptions.setTileSize(new Size(300,300));
mapOptions.getOptions().setAttribute("zIndex", 1000);

Currently I would favor option C.) as it acknowledges that conceptually an
XxxOptions object is not a subclass of Options. This is because Options is
actually more a generic way to create a Javascript Object with different
properties in java (so you don't have to do this using JSNI).

While we are on this I would suggest that we rename Options and the
setAttribute methods, as JavaScript Objects do not have attributes, but
properties. One possibility I am thinking of is that the setProperty methods
should be methods of JSObject. That way a MapOptions object can be just a
JSObjectWrapper from which you can request the JSObject through getJSObject
and which allows setting properties dynamically. Possibly there is some
security reason why GWT doesn't allow setting properties on
JavaScriptObject, although I cannot think of one, because all properties of
a javascript object can be modified runtime if you have access to the
objects on the page:
http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/core/client/JavaScriptObject.html

Throughout the code base there are more place where DOM terminology:
Elements that have Attributes, is used where Javascript terminology is more
correct: Objects that have properties.
See also: http://jennifermadden.com/javascript/objectsPropertiesMethods.html

Greetings,
Edwin