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

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

Hi Edwin,

Your stated approach below seems to have merit.

+1 on the approach and thanks.

Edwin Commandeur wrote:
> Hi Farrukh,
>
> Option C would not need OptionsBase and Options, but only an Options 
> object and maybe not even that (see below after steps a-e). The 
> Options object is a bit of a strange beast, as it creates a javascript 
> object and allows you to set arbitrary properties on them and ask for 
> these properties. Basically the Options object allows you to create 
> any javascript object you like (not so strange considering that in OL 
> an options object is created with an object literal that can be any 
> object).
>
> I have been thinking about it and I would still like to make a case 
> for Option C. The problem with Option A is that it makes it to easy to 
> code around the abstraction layer that GWT-OL offers. The setAttribute 
> methods are not part of what you want to expose as the GWT-OL API on 
> each options object, as they are basically methods that allow you to 
> code around your api by setting properties by their javascript name. 
> If 100 users want to set a ZIndex and there is no setZIndex method, 
> the setAttribute method allows users to make such a method themselves 
> but then they are coding around the abstraction GWT-OL offers and each 
> of them has to lookup the exact name that the OL Map object uses for 
> this property. Options C makes it clearer than Option A that users are 
> coding around the GWT-OL API, while stile permitting them to do so.
>
> I asked a colleague who is a long-time Java programmer and he said the 
> natural way he would approach opening up the setAttribute methods is 
> to extend MapOptions, e.g. CustomMapOptions extends MapOptions, and 
> provide a setZIndex method in CustomMapOptions. I think however that 
> we should take into account that GWT-OL is a GWT thing, and sometimes 
> you want access to the javascript objects underneath. What would be a 
> better place to get access to these javascript objects underneath than 
> the JSObject (see below)...
>
>  Here's some more detail of how I would envision things:
>
> a) Tear apart the DOM helper methods from ElementHelper and the 
> Javascript (object) helper methods (now named setAttribute/getAttribute)
>
> b) Put the Javascript (object) helper methods in JSObjectHelper
>
> c) Check which DOM methods in ElementHelper still make sense with GWT 
> 1.5 (which has a lot of methods for doing DOM stuff)
>
> d) Rename the setAttributeXxx methods to setPropertyXxx ()
>
> e) Implement the setProperty methods on JSObject, which is now just an 
> empty extension of JavaScriptObject 
> (http://google-web-toolkit.googlecode.com/svn/javadoc/1.5/com/google/gwt/core/client/JavaScriptObject.html).
>
> Notice that JSObject cannot be instantiated directly and that this is 
> intentionally done by GWT. So you would have to do:
>
> JSObject object = JSObject.createObject(); // or createFunction, or 
> createArray;
> object.setProperty("anyProp", 1); //go about setting properties
>
> Or as we do in all wrapper functions
> JSObject object = XxxImpl.create(); // create the JSObject that the 
> Xxx wraps
>
> By doing point (a)-(e) we get a lot cleaner code, and then we don't 
> even need the Options object anymore, or only use it to create an 
> empty javascript object on instantiation. MapOptions object can be a 
> JSObjectWrapper or extend Options. The object it wraps if it is a 
> JSObjectWrapper is an empty javascript object created by 
> JSObject.createObject(). The setters and getters of MapOptions are 
> then implemented as follows
>
> //how the setters would look
> public void setZIndex(int index) {
>     getJSObject().setProperty("zindex", index);
> }
>
> MapOptions is a JSObjectWrapper, the JSObject is the javascript object 
> underneath
>
> What's more, every object that is a JSObjectWrapper now has a backdoor 
> to set properties that are not yet supported by the abstraction layer 
> offered by GWT-OL.This is a bad thing if we want to have a locked down 
> API, but a good thing if we want to be flexible, and let user get to 
> the javascript beneath to solve stuff where there are not yet 
> abstractions for.
>
> Map map = mapWidget.getMap();
> map.getJSObject().setProperty("zindex", index); //not officially 
> supported by GWT-OL, but possible
>
> By the way, when it boils down to it, everything in Javascript is an 
> Object so having setProperty methods on JSObject makes sense to my 
> mind. In javascript you can do
>
> var x = new Object()
> x.prop = "property"
>
> equals var x = { prop: "property" }
>
> var x = function(){};
> x.prop = "property"; // does not directly make sense, but is possible, 
> and possibly useful
>
> var x = 1
> x.prop = "property"; // does not directly make sense, but is possible, 
> and possibly useful
>
> All in all, an important point I think is that the GWT-OL API should 
> eventually provide an abstraction layer above the javascript layer, so 
> for users the javascript layer is invisible. The setAttribute methods 
> set attributes directly on a javascript object and therefore I think 
> it should be clear to users that they are messing with the javascript 
> objects underneath.
>


-- 
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com