Menu
▾
▴
gwt-openlayers-devl — Developer list. Fairly active.
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
(3) |
Mar
(51) |
Apr
(8) |
May
(8) |
Jun
|
Jul
(3) |
Aug
(8) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(1) |
Feb
(21) |
Mar
(13) |
Apr
(8) |
May
(4) |
Jun
(3) |
Jul
(2) |
Aug
(11) |
Sep
(10) |
Oct
(1) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Farrukh N. <fa...@we...> - 2009-05-04 14:32:31
|
Farrukh Najmi wrote: > Farrukh Najmi wrote: >> Hi Guys, >> >> I need to provide map support in a swing app. Any suggestions for a >> royalty-free OS Java Mapping library? >> Thanks for your help. >> >> > Looks like this answers my question: > > <http://today.java.net/pub/a/today/2007/11/13/mapping-mashups-with-jxmapviewer.html> > > > Thanks. > Hi Guys, Unfortunately above project (swingx-ws) looks pretty limited and not very active. So I am again looking for suggestions on a Swing based client library for WMS. Any suggestions? -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Farrukh N. <fa...@we...> - 2009-05-02 16:14:03
|
Farrukh Najmi wrote: > Hi Guys, > > I need to provide map support in a swing app. Any suggestions for a > royalty-free OS Java Mapping library? > Thanks for your help. > > Looks like this answers my question: <http://today.java.net/pub/a/today/2007/11/13/mapping-mashups-with-jxmapviewer.html> Thanks. -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Farrukh N. <fa...@we...> - 2009-05-02 14:41:46
|
Hi Guys, I need to provide map support in a swing app. Any suggestions for a royalty-free OS Java Mapping library? Thanks for your help. -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Edwin C. <com...@gm...> - 2009-04-20 18:36:13
|
thanks to all for your kind wishes. i am happy to be able to contribute to a project together with such nice people. looking forward to do more on gwt-ol in may great that everybody seems to agree on org.gwtopenmaps.openlayers best regards, Edwin |
|
From: Curtis <je...@us...> - 2009-04-20 14:50:47
|
Edwin , I think we'll all forgive you if you chose to spend time with your soon to be wife than spend time with us. And if not, it's still better to annoy us than your wife. Thanks for all you do. Now go enjoy your wedding. I vote for "org.gwtopenmaps.openlayers" Best wishes, Curtis On Sun, Apr 19, 2009 at 4:26 AM, Edwin Commandeur <com...@gm...> wrote: > Dear all, > > The original plan was to release GWT-OL 0.4 mid april, and I was hoping to > be able to get that release done before my marriage next tuesday. However, > my schedule didn't allow me to free time for making the release, and also I > will be away until the 10th of may, so I cannot answer questions if the > release would be coming week. > > My proposal is to release GWT-OL in may, around the 17th of may. Then we > also have some more time to get the code base as consistent as possible. > When I get back I can then work on getting the website and wiki ready. But > if anyone can get one or more tutorials up on the wiki in the mean time that > would be great. > > Finally, we have to vote on a name for the package. Here are my suggestions: > > org.gwtgis.openlayers > > org.openmapsforgwt.openlayers > org.gwtopenmaps.openlayers > org.gwtcommunitymaps.openlayers > org.gwtmapbazaar.openlayers > org.gwtslippymaps.openlayers > > > Greetings, > Edwin > > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > |
|
From: Erdem G. <erd...@ya...> - 2009-04-20 07:36:02
|
thanks Edwin and Farrukh for your contributions, +1 for org.gwtopenmaps.openlayers it makes 3 so far, ________________________________ From: Edwin Commandeur <com...@gm...> To: Farrukh Najmi <fa...@we...> Cc: gwt...@li... Sent: Sunday, April 19, 2009 6:15:17 PM Subject: Re: [Gwt-openlayers-devl] releasing 0.4 Hi Farrukh, Thanks for your congrulations and understanding. Thanks also for setting up the mailing lists (invaluable) and your involvement with GWT-OL! I also look forward to releasing 0.4 in may (no excuses then). I am curious if OpenLayers 2.8 will be out in may by the way. Looking at the roadmap in Trac it's nearing completion. For GWT-OL 0.5 it would be nice to investigate if we can bundle OL. Community Mapbuilder distributed OL with the Mapbuilder distribution, so it does seem to be possible. Finally, thanks for your vote on the package name! If anyone comes up with a better name than the ones I suggested than that name could also be an option, otherwise we take the one with the most votes (for now 'org.gwtopenmaps.openlayers') and move on. Greetings, Edwin 2009/4/19 Farrukh Najmi <fa...@we...> Hi Edwin, Congratulation to you and your bride on your upcoming wedding. May you have a lifetime of happiness together. Thank you for all your leadership and contributions in moving this project forward. I look forward to release 0.4 after your life gets back to normal. More inline below... Edwin Commandeur wrote: Dear all, The original plan was to release GWT-OL 0.4 mid april, and I was hoping to be able to get that release done before my marriage next tuesday. However, my schedule didn't allow me to free time for making the release, and also I will be away until the 10th of may, so I cannot answer questions if the release would be coming week. My proposal is to release GWT-OL in may, around the 17th of may. Then we also have some more time to get the code base as consistent as possible. When I get back I can then work on getting the website and wiki ready. But if anyone can get one or more tutorials up on the wiki in the mean time that would be great. Finally, we have to vote on a name for the package. Here are my suggestions: org.gwtgis.openlayers org.openmapsforgwt.openlayers org.gwtopenmaps.openlayers org.gwtcommunitymaps.openlayers org.gwtmapbazaar.openlayers org.gwtslippymaps.openlayers I like org.gwtopenmaps.openlayers unless it is taken. Does not seem to be taken. Thanks. -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Edwin C. <com...@gm...> - 2009-04-19 15:15:22
|
Hi Farrukh, Thanks for your congrulations and understanding. Thanks also for setting up the mailing lists (invaluable) and your involvement with GWT-OL! I also look forward to releasing 0.4 in may (no excuses then). I am curious if OpenLayers 2.8 will be out in may by the way. Looking at the roadmap in Trac it's nearing completion. For GWT-OL 0.5 it would be nice to investigate if we can bundle OL. Community Mapbuilder distributed OL with the Mapbuilder distribution, so it does seem to be possible. Finally, thanks for your vote on the package name! If anyone comes up with a better name than the ones I suggested than that name could also be an option, otherwise we take the one with the most votes (for now 'org.gwtopenmaps.openlayers') and move on. Greetings, Edwin 2009/4/19 Farrukh Najmi <fa...@we...> > Hi Edwin, > > > Congratulation to you and your bride on your upcoming wedding. May you have > a lifetime of happiness together. > > Thank you for all your leadership and contributions in moving this project > forward. I look forward to release 0.4 after your > life gets back to normal. More inline below... > > > Edwin Commandeur wrote: > >> Dear all, >> >> The original plan was to release GWT-OL 0.4 mid april, and I was hoping to >> be able to get that release done before my marriage next tuesday. However, >> my schedule didn't allow me to free time for making the release, and also I >> will be away until the 10th of may, so I cannot answer questions if the >> release would be coming week. >> >> My proposal is to release GWT-OL in may, around the 17th of may. Then we >> also have some more time to get the code base as consistent as possible. >> When I get back I can then work on getting the website and wiki ready. But >> if anyone can get one or more tutorials up on the wiki in the mean time that >> would be great. >> >> Finally, we have to vote on a name for the package. Here are my >> suggestions: >> >> org.gwtgis.openlayers >> >> org.openmapsforgwt.openlayers >> org.gwtopenmaps.openlayers >> org.gwtcommunitymaps.openlayers >> org.gwtmapbazaar.openlayers >> org.gwtslippymaps.openlayers >> >> >> I like org.gwtopenmaps.openlayers unless it is taken. Does not seem to be > taken. Thanks. > > -- > Regards, > Farrukh > > Web: http://www.wellfleetsoftware.com > > > |
|
From: Farrukh N. <fa...@we...> - 2009-04-19 13:06:41
|
Hi Edwin, Congratulation to you and your bride on your upcoming wedding. May you have a lifetime of happiness together. Thank you for all your leadership and contributions in moving this project forward. I look forward to release 0.4 after your life gets back to normal. More inline below... Edwin Commandeur wrote: > Dear all, > > The original plan was to release GWT-OL 0.4 mid april, and I was > hoping to be able to get that release done before my marriage next > tuesday. However, my schedule didn't allow me to free time for making > the release, and also I will be away until the 10th of may, so I > cannot answer questions if the release would be coming week. > > My proposal is to release GWT-OL in may, around the 17th of may. Then > we also have some more time to get the code base as consistent as > possible. When I get back I can then work on getting the website and > wiki ready. But if anyone can get one or more tutorials up on the wiki > in the mean time that would be great. > > Finally, we have to vote on a name for the package. Here are my > suggestions: > > org.gwtgis.openlayers > > org.openmapsforgwt.openlayers > org.gwtopenmaps.openlayers > org.gwtcommunitymaps.openlayers > org.gwtmapbazaar.openlayers > org.gwtslippymaps.openlayers > > I like org.gwtopenmaps.openlayers unless it is taken. Does not seem to be taken. Thanks. -- Regards, Farrukh Web: http://www.wellfleetsoftware.com |
|
From: Edwin C. <com...@gm...> - 2009-04-19 11:26:27
|
Dear all, The original plan was to release GWT-OL 0.4 mid april, and I was hoping to be able to get that release done before my marriage next tuesday. However, my schedule didn't allow me to free time for making the release, and also I will be away until the 10th of may, so I cannot answer questions if the release would be coming week. My proposal is to release GWT-OL in may, around the 17th of may. Then we also have some more time to get the code base as consistent as possible. When I get back I can then work on getting the website and wiki ready. But if anyone can get one or more tutorials up on the wiki in the mean time that would be great. Finally, we have to vote on a name for the package. Here are my suggestions: org.gwtgis.openlayers org.openmapsforgwt.openlayers org.gwtopenmaps.openlayers org.gwtcommunitymaps.openlayers org.gwtmapbazaar.openlayers org.gwtslippymaps.openlayers Greetings, Edwin |
|
From: Edwin C. <com...@gm...> - 2009-04-10 07:38:06
|
Hi Curtis, Thanks for your reply. I will remove the "Options" constructors shortly, so Options can be phased out of GWT-OL altogether. I had already changed that ControlOptions, LayerOptions, etc extend JSObjectWrapper instead of Options, since they are completely different objects. Greetings, Edwin 2009/4/9 Curtis <je...@us...> > Sorry for taking a while to reply. > Yes, I agree, the "Options" constructors can and should go away now > that we have your new Options getters/setters. > > -- > Curtis > > On Sun, Mar 29, 2009 at 2:58 AM, Edwin Commandeur > <com...@gm...> wrote: > > Hi Curtis, > > > > I think your solution with the extra constructors with String[] urls is > > indeed the best solution. > > > > I saw that OpenLayers it is also arranged in the constructor: The url > > parameter (the 2nd parameter in WMS constructor) can be single url or an > > urlArray. > > http://trac.openlayers.org/wiki/OpenLayersOptimization > > > > WMS has six constructors now, but two of them with Options as argument > are > > now obsolete with the changes to empower JSObject with getters/setters > for > > properties. So that would leave the nice number of four constructors for > the > > eventual 0.4 release I would say. > > > > Greetings, > > Edwin Commandeur > > > > P.S. > > For people that want to set custom properties on WMSLayerOptions they can > > do: > > WMSLayerOptions wmsLayerOptions = new WMSLayerOptions(); > > wmsLayerOptions.getJSObject().setProperty(...); //getJSObject route will > > eventually work on any GWT-OL object :-)... > > > > Instead of passing an Options object > > Options options = new Options(); > > options.setAttribute(...); > > > > > > 2009/3/29 Curtis Jensen <cu...@th...> > >> > >> Hi Edwin, > >> > >> The import was left over from some of my experimenting. Thanks for > >> cleaning it up. JStringArray is only used in WMS.java. I think it > >> can be done without the JStringArray class, but it is left in there > >> because I know it works that way. > >> > >> -- > >> Curtis > >> > >> On Sat, Mar 28, 2009 at 10:04 AM, Edwin Commandeur > >> <com...@gm...> wrote: > >> > Hi Curtis, > >> > > >> > Is it possible that not all changes for setting multiple WMS urls were > >> > committed. I saw a JStringArray, which is imported in WMSImpl but > never > >> > used > >> > there. > >> > > >> > I cleaned up the unused import for now. Possibly some stuff failed to > be > >> > committed. I was expecting a method on the WMS or in WMSOptions (I > >> > renamed > >> > WMSParams, so Options is now consistently used versus params). > >> > > >> > Greetings, > >> > Edwin > >> > > > > > > |
|
From: Curtis <je...@us...> - 2009-04-09 19:08:13
|
Sorry for taking a while to reply. Yes, I agree, the "Options" constructors can and should go away now that we have your new Options getters/setters. -- Curtis On Sun, Mar 29, 2009 at 2:58 AM, Edwin Commandeur <com...@gm...> wrote: > Hi Curtis, > > I think your solution with the extra constructors with String[] urls is > indeed the best solution. > > I saw that OpenLayers it is also arranged in the constructor: The url > parameter (the 2nd parameter in WMS constructor) can be single url or an > urlArray. > http://trac.openlayers.org/wiki/OpenLayersOptimization > > WMS has six constructors now, but two of them with Options as argument are > now obsolete with the changes to empower JSObject with getters/setters for > properties. So that would leave the nice number of four constructors for the > eventual 0.4 release I would say. > > Greetings, > Edwin Commandeur > > P.S. > For people that want to set custom properties on WMSLayerOptions they can > do: > WMSLayerOptions wmsLayerOptions = new WMSLayerOptions(); > wmsLayerOptions.getJSObject().setProperty(...); //getJSObject route will > eventually work on any GWT-OL object :-)... > > Instead of passing an Options object > Options options = new Options(); > options.setAttribute(...); > > > 2009/3/29 Curtis Jensen <cu...@th...> >> >> Hi Edwin, >> >> The import was left over from some of my experimenting. Thanks for >> cleaning it up. JStringArray is only used in WMS.java. I think it >> can be done without the JStringArray class, but it is left in there >> because I know it works that way. >> >> -- >> Curtis >> >> On Sat, Mar 28, 2009 at 10:04 AM, Edwin Commandeur >> <com...@gm...> wrote: >> > Hi Curtis, >> > >> > Is it possible that not all changes for setting multiple WMS urls were >> > committed. I saw a JStringArray, which is imported in WMSImpl but never >> > used >> > there. >> > >> > I cleaned up the unused import for now. Possibly some stuff failed to be >> > committed. I was expecting a method on the WMS or in WMSOptions (I >> > renamed >> > WMSParams, so Options is now consistently used versus params). >> > >> > Greetings, >> > Edwin >> > > > |
|
From: Edwin C. <com...@gm...> - 2009-03-31 19:25:21
|
Hi all, Yesterday I committed changes to the codebase in which I renamed Params objects to Options objects. I partially want to revert that and will commit that tomorrow. Eventually I would like to drop the Options class, as it is not conceptually a parent class for XxxOption clases, see below. Looking at the OpenLayers (OL) API I see that I was a bit to quick, at least for the WMS layer. The constructor for WMS is defined to have the parameters: name, url, params, and options. (see: http://dev.openlayers.org/releases/OpenLayers-2.7/doc/apidocs/files/OpenLayers/Layer/WMS-js.html ) For a Google layer the constructor is defined to have the parameters: name, options (see: http://dev.openlayers.org/releases/OpenLayers-2.7/doc/apidocs/files/OpenLayers/Layer/Google-js.html ) Thinking about things a little bit more I would like to suggest the following naming scheme: XxxOptions - for arguments that are defined as options in OL API XxxParams - for arguments that are defined as params in OL API Another thought I had is that ControlOptions, LayerOptions, and MapOptions all extend Options, but in fact these Options classes conceptually do not share a parent class (except that they are all javascript objects). Therefore, I would like to go further and remove Options from GWT-OL completely and let ControlOptions, LayerOptions and MapOptions all extend JSObjectWrapper directly. Options for specific Layer classes (WMS, Image) do share the parent LayerOptions (unlike WMSParams, which can also be a JSObjectWrapper), just as options for specific Format classes share the parent FormatOptions, etc. Greetings, Edwin |
|
From: Edwin C. <com...@gm...> - 2009-03-30 10:57:06
|
Hi all, I have made some changes to core utility classes in GWT-OL that may be perceived as invasive and I changed XxxParams in the layer subpackage to XxxOptions. To my mind this will make GWT-OL more powerful and more consistent. First a list of changes and below some explanation: JSObject - added getters/setters for properties JSObjectHelper - implements getters/setters for JSObject ElementHelper - stripped of methods that do stuff on JSObject instead of Elements (a child of JSObject) Options - reduced to a JSObjectWrapper, wrapping an empty javascript object OptionsImp, OptionsBase, OptionsBaseImpl - deleted as they are no longer relevant XxxParams (in Layer package) - renamed to XxxOptions For refactoring code based on GWT-OL before these changes mean: -change imports of XxxParams to XxxOptions (the objects did not change otherwise) -any code that uses setAttribute methods exposed by Options should change to setAttribute(...) to getJSObject().setProperty(...) Please let me know if other code broke for you. This could be if anyone was using methods in ElementHelper that were not used in the API at all (mainly for doing stuff with Arrays, for which JSObjectArray and children seem more appropriate). The methods for working with JSObject were previously in ElementHelper and to my mind they did not belong there. An Element is a very specific kind of Javascript object that represents a DOM element. There is a lot of functionality for working with the DOM in GWT, especially if we upgrade to GWT 1.5. In GWT 1.4 there's already com.google.gwt.user.client.DOM, com.google.gwt.user.client.Element and in GWT 1.5 almost all the functions that can be called on Element in javascript can be called on it directly from GWT (if not all). Somehow, GWT 1.5 added all kinds of methods for direct manipulation of Element objects, but not for direct manipulation of JavaScriptObject objects. This is why JSObject now has methods to do this. The benefit is that all objects in GWT-OL are, or should be JSObjectWrapper objects and therefore have a public getJSObject method, to get at the underlying javascript object. This way the GWT-OL API can stay clean, but it is still possible to get at the bare javascript objects if users want to do this and get and set properties on the underlying javascript objects. This is desirable given the nature of GWT wrapper libraries. The rationale for renaming XxxParams to XxxOptions is to make clear that they are Options objects (Params is not object in GWT-OL), and to be more consistent with terminology used in OpenLayers documentation, see this link: http://docs.openlayers.org/library/syntax.html Greetings, Edwin |
|
From: Edwin C. <com...@gm...> - 2009-03-29 09:58:46
|
Hi Curtis, I think your solution with the extra constructors with String[] urls is indeed the best solution. I saw that OpenLayers it is also arranged in the constructor: The url parameter (the 2nd parameter in WMS constructor) can be single url or an urlArray. http://trac.openlayers.org/wiki/OpenLayersOptimization WMS has six constructors now, but two of them with Options as argument are now obsolete with the changes to empower JSObject with getters/setters for properties. So that would leave the nice number of four constructors for the eventual 0.4 release I would say. Greetings, Edwin Commandeur P.S. For people that want to set custom properties on WMSLayerOptions they can do: WMSLayerOptions wmsLayerOptions = new WMSLayerOptions(); wmsLayerOptions.getJSObject().setProperty(...); //getJSObject route will eventually work on any GWT-OL object :-)... Instead of passing an Options object Options options = new Options(); options.setAttribute(...); 2009/3/29 Curtis Jensen <cu...@th...> > Hi Edwin, > > The import was left over from some of my experimenting. Thanks for > cleaning it up. JStringArray is only used in WMS.java. I think it > can be done without the JStringArray class, but it is left in there > because I know it works that way. > > -- > Curtis > > On Sat, Mar 28, 2009 at 10:04 AM, Edwin Commandeur > <com...@gm...> wrote: > > Hi Curtis, > > > > Is it possible that not all changes for setting multiple WMS urls were > > committed. I saw a JStringArray, which is imported in WMSImpl but never > used > > there. > > > > I cleaned up the unused import for now. Possibly some stuff failed to be > > committed. I was expecting a method on the WMS or in WMSOptions (I > renamed > > WMSParams, so Options is now consistently used versus params). > > > > Greetings, > > Edwin > > > |
|
From: Curtis <je...@us...> - 2009-03-27 14:16:40
|
If there are no objections (by the end of the weekend). I'll commit the change Mon. -- Curtis On Fri, Mar 27, 2009 at 2:22 AM, Edwin Commandeur <com...@gm...> wrote: > Seems to me that we should indeed change the return type to int. > > 2009/3/26 Curtis <je...@us...> >> >> Why does the Map.getZoom method return a string? >> >> The OpenLayers getZoom method returns an integer. >> >> -- >> Curtis >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Gwt-openlayers-devl mailing list >> Gwt...@li... >> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > |
|
From: Edwin C. <com...@gm...> - 2009-03-27 09:23:02
|
Seems to me that we should indeed change the return type to int. 2009/3/26 Curtis <je...@us...> > Why does the Map.getZoom method return a string? > > The OpenLayers getZoom method returns an integer. > > -- > Curtis > > > ------------------------------------------------------------------------------ > _______________________________________________ > Gwt-openlayers-devl mailing list > Gwt...@li... > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > |
|
From: Curtis <je...@us...> - 2009-03-26 20:32:19
|
Below is an example of a popup (DialogBox) being hidden by the map.
With this code every thing looks fine in Hosted mode and IE. When the
page is loaded with Firefox and you drag the dialog box over the map,
the map will be on top. Or if the page loads with the dialog already
overlapping with the map, I don't see the dialog at all.
private Widget getMapWidget()
{
MapOptions mapOptions = new MapOptions();
mapOptions.setControls(new JObjectArray(new JSObject[] {}));
mapOptions.setNumZoomLevels(16);
mapOptions.setProjection("EPSG:4326");
MapWidget mapWidget = new MapWidget("400px", "400px",
mapOptions);
Map map = mapWidget.getMap();
WMSParams wmsParams = new WMSParams();
wmsParams.setLayers("landsat7");
WMS wmsLayer = new WMS("WMS Layer",
"http://t1.hypercube.telascience.org/cgi-bin/landsat7", wmsParams);
map.addLayers(new Layer[] {wmsLayer});
map.addControl(new PanZoomBar());
map.addControl(new MouseToolbar());
LonLat center = new LonLat(-73.99, 40.73);
map.setCenter(center, 13);
return mapWidget;
}
public void onModuleLoad()
{
VerticalPanel mainPanel = new VerticalPanel();
mainPanel.setSize("100%", "100%");
mainPanel.add(getMapWidget());
RootPanel.get().add(mainPanel);
DialogBox simplePopup = new DialogBox();
simplePopup.setText("I am simple");
simplePopup.add(new Label("Can you see me?"));
simplePopup.center();
simplePopup.show();
}
On Mon, Mar 23, 2009 at 9:33 AM, Edwin Commandeur
<com...@gm...> wrote:
> Hi Curtis,
>
> I haven't been at my laptop that is set up for programming, but I saw from
> the CVS that you did not commit the modifications to the CVS.
>
> It is confusing in the current situation as there is an Options object and
> an OptionsBase object. The latter I have introduced to hide setAttribute
> methods for specific Options objects. I will think about how we can make
> this less confusing and make the Options objects more powerful. The simplest
> possibility is to remove OptionsBase and let Options objects extend Options.
>
> Are you using GWT-OpenLayers with plain GWT widgets?
>
> I am using GWT-OpenLayers with plain GWT widgets for the showcase and with
> Ext-GWT for several applications but I have never experience the Z-Index
> problem you are describing.
>
> The MapWidget is very minimalistic. It only creates a div which OpenLayers
> can use to put the map in. The MapWidget itself does not do anything with
> z-indexes of that div, that is all OpenLayers. Possibly the problem is also
> solved if you create a div within the Panel you are using and let the
> MapWidget use that div. Currently this is not possible, but there is some
> commented out code in MapWidget that you can uncomment to test if this works
> in principle.
>
> Greetings,
> Edwin
>
> P.S.
>
>
>
>
> 2009/3/23 Curtis Jensen <cur...@gm...>
>>
>> Hello,
>>
>> Sorry I haven't jumped in earlier. Me and the family got sick (I
>> still am). I hate winter.
>>
>> I had forgotten that I did modify the source to expose the the
>> setAttribute methods.
>>
>> Yes, it would be nice for me to have a setZIndexBase method. I kinda
>> would like the setAttribute method exposed too for the advanced needs.
>> If something comes up other than ZIndex or if ZIndex accessors are
>> never added, how else would we set the properties that aren't
>> explicitly in the API?
>>
>> Does anyone else have a problem with the OpenLayers map being hid by
>> other widgets? Or the map hiding other widgets?
>> If I create a popup panel, the map will be above the popup panel and I
>> can't see the popup. This only happens in Firefox. IE puts the popup
>> on top of the map. After looking at the zIndexes of the widgets, I
>> think that the map should cover the popup panel. Even though I want
>> the popup on top, it is incorrect to render it on top.
>>
>> --
>> Curtis
>>
>>
>>
>> On Mon, Mar 23, 2009 at 6:05 AM, Edwin Commandeur
>> <com...@gm...> wrote:
>> > Hi Farrukh,
>> >
>> > I will be adding the getter and setter for setZIndexBase().
>> >
>> > It does bug me a bit that the options objects don't have a setProperty
>> > method for advanced users who want to set properties not yet supported
>> > by
>> > the API. I will try to come up with a single method that allows setting
>> > properties of multiple types. At present I am thinking of sth like:
>> >
>> > setProperty(String name, PropertyValue value)
>> >
>> > Where PropertyValue can be of different types.
>> >
>> > Greetings,
>> > Edwin
>> >
>> > 2009/3/23 Farrukh Najmi <fa...@we...>
>> >>
>> >> Farrukh Najmi wrote:
>> >>>
>> >>> Edwin Commandeur wrote:
>> >>>
>> >>>>
>> >>>> Hi Farrukh,
>> >>>>
>> >>>> MapOptions extends OptionsBase, which intentionally hides the
>> >>>> setAttribute methods for non-children (see the Javadoc on
>> >>>> OptionsBase). The
>> >>>> idea behind this is that XxxOptions objects should only have setters
>> >>>> for
>> >>>> options that can actually be set on them. Also the setAttribute
>> >>>> methods
>> >>>> clutter the code suggestions by the IDE for the available setters
>> >>>> (another
>> >>>> option to prevent code suggestion clutter would be to have a
>> >>>> IMapOptions
>> >>>> interface with limited setters and let that be extended by a
>> >>>> MapOptions
>> >>>> class that extends Options).
>> >>>>
>> >>>> If it makes sense to support setting the Z-Index I would argue that
>> >>>> there should be a public setZIndex method, but if others feel that it
>> >>>> makes
>> >>>> more sense to expose the setAttribute methods than we should consider
>> >>>> making
>> >>>> all classes that extend OptionsBase extend Options instead (as in
>> >>>> GWT-OL
>> >>>> 0.2).
>> >>>>
>> >>>>
>> >>>
>> >>> Hi Edwin,
>> >>>
>> >>> I agree with your rationale.
>> >>>
>> >>> +1 on adding setZIndex(int zIndex) and getZIndex() methods.
>> >>>
>> >>> I think it would be better if you could do it as you are more familiar
>> >>> with code base.
>> >>>
>> >>> Please let me know if I can help. When its committed I will test it
>> >>> out.
>> >>> Thanks.
>> >>>
>> >>>
>> >>
>> >> Actually, perhaps the methods should be get/setZIndexBase() since they
>> >> wouldset the base for a set of zindexes.
>> >>
>> >> --
>> >> Regards,
>> >> Farrukh
>> >>
>> >> Web: http://www.wellfleetsoftware.com
>> >>
>> >>
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
>> > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
>> > easily build your RIAs with Flex Builder, the Eclipse(TM)based
>> > development
>> > software that enables intelligent coding and step-through debugging.
>> > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>> > _______________________________________________
>> > Gwt-openlayers-devl mailing list
>> > Gwt...@li...
>> > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl
>> >
>> >
>
>
|
|
From: Curtis <je...@us...> - 2009-03-26 20:30:51
|
Why does the Map.getZoom method return a string? The OpenLayers getZoom method returns an integer. -- Curtis |
|
From: Farrukh N. <fa...@we...> - 2009-03-24 17:38:46
|
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 |
|
From: Edwin C. <com...@gm...> - 2009-03-24 17:32:45
|
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. Greetings, Edwin 2009/3/24 Farrukh Najmi <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 > > > |
|
From: Farrukh N. <fa...@we...> - 2009-03-24 14:36:14
|
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
|
|
From: Edwin C. <com...@gm...> - 2009-03-24 07:36:12
|
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
|
|
From: Curtis J. <cu...@th...> - 2009-03-23 18:01:29
|
Below is an example of a popup (DialogBox) being hidden by the map.
With this code every thing looks fine in Hosted mode and IE. When the
page is loaded with Firefox and you drag the dialog box over the map,
the map will be on top. Or if the page loads with the dialog already
overlapping with the map, I don't see the dialog at all.
private Widget getMapWidget()
{
MapOptions mapOptions = new MapOptions();
mapOptions.setControls(new JObjectArray(new JSObject[] {}));
mapOptions.setNumZoomLevels(16);
mapOptions.setProjection("EPSG:4326");
MapWidget mapWidget = new MapWidget("400px", "400px", mapOptions);
Map map = mapWidget.getMap();
WMSParams wmsParams = new WMSParams();
wmsParams.setLayers("landsat7");
WMS wmsLayer = new WMS("WMS Layer",
"http://t1.hypercube.telascience.org/cgi-bin/landsat7", wmsParams);
map.addLayers(new Layer[] {wmsLayer});
map.addControl(new PanZoomBar());
map.addControl(new MouseToolbar());
LonLat center = new LonLat(-73.99, 40.73);
map.setCenter(center, 13);
return mapWidget;
}
public void onModuleLoad()
{
VerticalPanel mainPanel = new VerticalPanel();
mainPanel.setSize("100%", "100%");
mainPanel.add(getMapWidget());
RootPanel.get().add(mainPanel);
DialogBox simplePopup = new DialogBox();
simplePopup.setText("I am simple");
simplePopup.add(new Label("Can you see me?"));
simplePopup.center();
simplePopup.show();
}
On Mon, Mar 23, 2009 at 9:33 AM, Edwin Commandeur
<com...@gm...> wrote:
> Hi Curtis,
>
> I haven't been at my laptop that is set up for programming, but I saw from
> the CVS that you did not commit the modifications to the CVS.
>
> It is confusing in the current situation as there is an Options object and
> an OptionsBase object. The latter I have introduced to hide setAttribute
> methods for specific Options objects. I will think about how we can make
> this less confusing and make the Options objects more powerful. The simplest
> possibility is to remove OptionsBase and let Options objects extend Options.
>
> Are you using GWT-OpenLayers with plain GWT widgets?
>
> I am using GWT-OpenLayers with plain GWT widgets for the showcase and with
> Ext-GWT for several applications but I have never experience the Z-Index
> problem you are describing.
>
> The MapWidget is very minimalistic. It only creates a div which OpenLayers
> can use to put the map in. The MapWidget itself does not do anything with
> z-indexes of that div, that is all OpenLayers. Possibly the problem is also
> solved if you create a div within the Panel you are using and let the
> MapWidget use that div. Currently this is not possible, but there is some
> commented out code in MapWidget that you can uncomment to test if this works
> in principle.
>
> Greetings,
> Edwin
>
> P.S.
>
>
>
>
> 2009/3/23 Curtis Jensen <cur...@gm...>
>>
>> Hello,
>>
>> Sorry I haven't jumped in earlier. Me and the family got sick (I
>> still am). I hate winter.
>>
>> I had forgotten that I did modify the source to expose the the
>> setAttribute methods.
>>
>> Yes, it would be nice for me to have a setZIndexBase method. I kinda
>> would like the setAttribute method exposed too for the advanced needs.
>> If something comes up other than ZIndex or if ZIndex accessors are
>> never added, how else would we set the properties that aren't
>> explicitly in the API?
>>
>> Does anyone else have a problem with the OpenLayers map being hid by
>> other widgets? Or the map hiding other widgets?
>> If I create a popup panel, the map will be above the popup panel and I
>> can't see the popup. This only happens in Firefox. IE puts the popup
>> on top of the map. After looking at the zIndexes of the widgets, I
>> think that the map should cover the popup panel. Even though I want
>> the popup on top, it is incorrect to render it on top.
>>
>> --
>> Curtis
>>
>>
>>
>> On Mon, Mar 23, 2009 at 6:05 AM, Edwin Commandeur
>> <com...@gm...> wrote:
>> > Hi Farrukh,
>> >
>> > I will be adding the getter and setter for setZIndexBase().
>> >
>> > It does bug me a bit that the options objects don't have a setProperty
>> > method for advanced users who want to set properties not yet supported
>> > by
>> > the API. I will try to come up with a single method that allows setting
>> > properties of multiple types. At present I am thinking of sth like:
>> >
>> > setProperty(String name, PropertyValue value)
>> >
>> > Where PropertyValue can be of different types.
>> >
>> > Greetings,
>> > Edwin
>> >
>> > 2009/3/23 Farrukh Najmi <fa...@we...>
>> >>
>> >> Farrukh Najmi wrote:
>> >>>
>> >>> Edwin Commandeur wrote:
>> >>>
>> >>>>
>> >>>> Hi Farrukh,
>> >>>>
>> >>>> MapOptions extends OptionsBase, which intentionally hides the
>> >>>> setAttribute methods for non-children (see the Javadoc on
>> >>>> OptionsBase). The
>> >>>> idea behind this is that XxxOptions objects should only have setters
>> >>>> for
>> >>>> options that can actually be set on them. Also the setAttribute
>> >>>> methods
>> >>>> clutter the code suggestions by the IDE for the available setters
>> >>>> (another
>> >>>> option to prevent code suggestion clutter would be to have a
>> >>>> IMapOptions
>> >>>> interface with limited setters and let that be extended by a
>> >>>> MapOptions
>> >>>> class that extends Options).
>> >>>>
>> >>>> If it makes sense to support setting the Z-Index I would argue that
>> >>>> there should be a public setZIndex method, but if others feel that it
>> >>>> makes
>> >>>> more sense to expose the setAttribute methods than we should consider
>> >>>> making
>> >>>> all classes that extend OptionsBase extend Options instead (as in
>> >>>> GWT-OL
>> >>>> 0.2).
>> >>>>
>> >>>>
>> >>>
>> >>> Hi Edwin,
>> >>>
>> >>> I agree with your rationale.
>> >>>
>> >>> +1 on adding setZIndex(int zIndex) and getZIndex() methods.
>> >>>
>> >>> I think it would be better if you could do it as you are more familiar
>> >>> with code base.
>> >>>
>> >>> Please let me know if I can help. When its committed I will test it
>> >>> out.
>> >>> Thanks.
>> >>>
>> >>>
>> >>
>> >> Actually, perhaps the methods should be get/setZIndexBase() since they
>> >> wouldset the base for a set of zindexes.
>> >>
>> >> --
>> >> Regards,
>> >> Farrukh
>> >>
>> >> Web: http://www.wellfleetsoftware.com
>> >>
>> >>
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
>> > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
>> > easily build your RIAs with Flex Builder, the Eclipse(TM)based
>> > development
>> > software that enables intelligent coding and step-through debugging.
>> > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>> > _______________________________________________
>> > Gwt-openlayers-devl mailing list
>> > Gwt...@li...
>> > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl
>> >
>> >
>
>
|
|
From: Edwin C. <com...@gm...> - 2009-03-23 16:33:50
|
Hi Curtis, I haven't been at my laptop that is set up for programming, but I saw from the CVS that you did not commit the modifications to the CVS. It is confusing in the current situation as there is an Options object and an OptionsBase object. The latter I have introduced to hide setAttribute methods for specific Options objects. I will think about how we can make this less confusing and make the Options objects more powerful. The simplest possibility is to remove OptionsBase and let Options objects extend Options. Are you using GWT-OpenLayers with plain GWT widgets? I am using GWT-OpenLayers with plain GWT widgets for the showcase and with Ext-GWT for several applications but I have never experience the Z-Index problem you are describing. The MapWidget is very minimalistic. It only creates a div which OpenLayers can use to put the map in. The MapWidget itself does not do anything with z-indexes of that div, that is all OpenLayers. Possibly the problem is also solved if you create a div within the Panel you are using and let the MapWidget use that div. Currently this is not possible, but there is some commented out code in MapWidget that you can uncomment to test if this works in principle. Greetings, Edwin P.S. 2009/3/23 Curtis Jensen <cur...@gm...> > Hello, > > Sorry I haven't jumped in earlier. Me and the family got sick (I > still am). I hate winter. > > I had forgotten that I did modify the source to expose the the > setAttribute methods. > > Yes, it would be nice for me to have a setZIndexBase method. I kinda > would like the setAttribute method exposed too for the advanced needs. > If something comes up other than ZIndex or if ZIndex accessors are > never added, how else would we set the properties that aren't > explicitly in the API? > > Does anyone else have a problem with the OpenLayers map being hid by > other widgets? Or the map hiding other widgets? > If I create a popup panel, the map will be above the popup panel and I > can't see the popup. This only happens in Firefox. IE puts the popup > on top of the map. After looking at the zIndexes of the widgets, I > think that the map should cover the popup panel. Even though I want > the popup on top, it is incorrect to render it on top. > > -- > Curtis > > > > On Mon, Mar 23, 2009 at 6:05 AM, Edwin Commandeur > <com...@gm...> wrote: > > Hi Farrukh, > > > > I will be adding the getter and setter for setZIndexBase(). > > > > It does bug me a bit that the options objects don't have a setProperty > > method for advanced users who want to set properties not yet supported by > > the API. I will try to come up with a single method that allows setting > > properties of multiple types. At present I am thinking of sth like: > > > > setProperty(String name, PropertyValue value) > > > > Where PropertyValue can be of different types. > > > > Greetings, > > Edwin > > > > 2009/3/23 Farrukh Najmi <fa...@we...> > >> > >> Farrukh Najmi wrote: > >>> > >>> Edwin Commandeur wrote: > >>> > >>>> > >>>> Hi Farrukh, > >>>> > >>>> MapOptions extends OptionsBase, which intentionally hides the > >>>> setAttribute methods for non-children (see the Javadoc on > OptionsBase). The > >>>> idea behind this is that XxxOptions objects should only have setters > for > >>>> options that can actually be set on them. Also the setAttribute > methods > >>>> clutter the code suggestions by the IDE for the available setters > (another > >>>> option to prevent code suggestion clutter would be to have a > IMapOptions > >>>> interface with limited setters and let that be extended by a > MapOptions > >>>> class that extends Options). > >>>> > >>>> If it makes sense to support setting the Z-Index I would argue that > >>>> there should be a public setZIndex method, but if others feel that it > makes > >>>> more sense to expose the setAttribute methods than we should consider > making > >>>> all classes that extend OptionsBase extend Options instead (as in > GWT-OL > >>>> 0.2). > >>>> > >>>> > >>> > >>> Hi Edwin, > >>> > >>> I agree with your rationale. > >>> > >>> +1 on adding setZIndex(int zIndex) and getZIndex() methods. > >>> > >>> I think it would be better if you could do it as you are more familiar > >>> with code base. > >>> > >>> Please let me know if I can help. When its committed I will test it > out. > >>> Thanks. > >>> > >>> > >> > >> Actually, perhaps the methods should be get/setZIndexBase() since they > >> wouldset the base for a set of zindexes. > >> > >> -- > >> Regards, > >> Farrukh > >> > >> Web: http://www.wellfleetsoftware.com > >> > >> > > > > > > > ------------------------------------------------------------------------------ > > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > > easily build your RIAs with Flex Builder, the Eclipse(TM)based > development > > software that enables intelligent coding and step-through debugging. > > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > > _______________________________________________ > > Gwt-openlayers-devl mailing list > > Gwt...@li... > > https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl > > > > > |
|
From: Edwin C. <com...@gm...> - 2009-03-23 13:06:07
|
Hi Farrukh, I will be adding the getter and setter for setZIndexBase(). It does bug me a bit that the options objects don't have a setProperty method for advanced users who want to set properties not yet supported by the API. I will try to come up with a single method that allows setting properties of multiple types. At present I am thinking of sth like: setProperty(String name, PropertyValue value) Where PropertyValue can be of different types. Greetings, Edwin 2009/3/23 Farrukh Najmi <fa...@we...> > Farrukh Najmi wrote: > >> Edwin Commandeur wrote: >> >> >>> Hi Farrukh, >>> >>> MapOptions extends OptionsBase, which intentionally hides the >>> setAttribute methods for non-children (see the Javadoc on OptionsBase). The >>> idea behind this is that XxxOptions objects should only have setters for >>> options that can actually be set on them. Also the setAttribute methods >>> clutter the code suggestions by the IDE for the available setters (another >>> option to prevent code suggestion clutter would be to have a IMapOptions >>> interface with limited setters and let that be extended by a MapOptions >>> class that extends Options). >>> >>> If it makes sense to support setting the Z-Index I would argue that there >>> should be a public setZIndex method, but if others feel that it makes more >>> sense to expose the setAttribute methods than we should consider making all >>> classes that extend OptionsBase extend Options instead (as in GWT-OL 0.2). >>> >>> >>> >> >> Hi Edwin, >> >> I agree with your rationale. >> >> +1 on adding setZIndex(int zIndex) and getZIndex() methods. >> >> I think it would be better if you could do it as you are more familiar >> with code base. >> >> Please let me know if I can help. When its committed I will test it out. >> Thanks. >> >> >> > Actually, perhaps the methods should be get/setZIndexBase() since they > wouldset the base for a set of zindexes. > > > -- > Regards, > Farrukh > > Web: http://www.wellfleetsoftware.com > > > |
8 messages has been excluded from this view by a project administrator.
