Re: [Gwt-openlayers-devl] options for options

[Farrukh N. <fa...@we...>]

Edwin Commandeur wrote:
> 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).

For me both B and C are confusing with more than one typeof Option class 
while A is clear.
I am personally not bothered by IDE suggetsion clutter issue. IMHO We 
should not let IDE cosniderations
impact the naturalness of the API.

So, with my limited experience at this API I feel A is best. Please do 
not consider this a VOTE as I do not feel
as qualified as other team mates to carry the same weight of opinion.

>
> 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

Again with my limited experience, above suggestion sounds reasonable. 
Thanks.

-- 
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com