gwt-openlayers-devl — Developer list. Fairly active.

Re: [Gwt-openlayers-devl] gwt-openlayers

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

Hi Robert,

The WFS functionality is a recent contribution by Dave, maybe he
recognizes the problem easily. I still need to get working on a Java
port of the Open Proxy that is necessary for the WFS functionality and
that is included in the OpenLayers examples.

How are you running your code? Is the Python Open Proxy implementation up?

The dev list is not publicly visible as far as I am aware, but I have
cc'd this reply to the devl list.

Greetings,
Edwin


On 4 February 2010 16:54, Robert Light <rob...@ve...> wrote:
> Edwin,
>
> I think I've found a bug either in openlayers or in gwt-openlayers code.
>
> if I create a WFS layer:
>             WFSParams wfsParams = new WFSParams();
>             wfsParams.setTypename("topp:states");
>             WFSOptions wfsLayerOptions = new WFSOptions();
>             wfsLayerOptions.setTransitionEffect(TransitionEffect.RESIZE);
>             wfsLayerOptions.setExtractAttributes(true);
>
>             WFS wfsLayer = new WFS(
>                     "states",
>                     "http://192.168.1.167:8080/geoserver/wfs",
>                     wfsParams,
>                     wfsLayerOptions);
>
> and then I want to get selection events so I do:
>
>             wfsLayer.addVectorFeatureSelectedListener( new
> VectorFeatureSelectedListener() {
>
>                 public void onFeatureSelected(FeatureSelectedEvent
> eventObject) {
>                     JSONObject map = new
> JSONObject(eventObject.getVectorFeature().getJSObject().getProperty("attributes"));
>                     System.out.println("Feature.id =
> "+eventObject.getVectorFeature().getId());
>                     for( String key : map.keySet()) {
>                         System.out.println(key+"="+map.get(key));
>                     }
>                 }
>             });
>
> This does not work... my VectorFeatureSelectListener never get's called.
>
> To make this work, I had to add the following:
>             SelectFeatureOptions selectFeatureOptions = new
> SelectFeatureOptions();
>             selectFeatureOptions.onSelect( new
> SelectFeature.SelectFeatureListener() {
>
>                 public void onFeatureSelected(VectorFeature vectorFeature) {
>                     JSONObject map = new
> JSONObject(vectorFeature.getJSObject().getProperty("attributes"));
>                     for( String key : map.keySet()) {
>                         System.out.println(key+"="+map.get(key));
>                     }
>                 }
>             });
>
>             SelectFeature selfeature = new SelectFeature(wfsLayer,
> selectFeatureOptions);
>             map.getMap().addControl(selfeature);
>             selfeature.activate();
>
>
> And now BOTH my VectureFeatureSelectListener AND my SelectFeatureListener
> get called when I select a feature.
>
> To put another wrinkle in the puzzle....instead of adding the SelectFeature
> Control as above, I do just the following:
>
>             SelectFeature selfeature = new SelectFeature(wfsLayer);
>             map.getMap().addControl(selfeature);
>             selfeature.activate();
>
> My  VectorFeatureSelectListener does NOT get called.
>
> Any ideas?   Is there a developer's list I should post this query to?
>
> Note, I'm working off the latest set of sources that I downloaded via
> mercurial.
>
> many thanks.
>
>    - Bob Light
>
>

Re: [Gwt-openlayers-devl] some hg advice

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

Hi Dave,

Here's my 50ct:

Every time in Mercurial that you commit to the local cloned repository
a new branch is created of the central repository, I presume with it's
own head.

The remote SF repo is setup such that it cannot contain multiple
heads, so if you and I clone it, and I push something first then you
will have to merge that changes before your next push, because then
you are in a different branch (and you would need  different heads to
push different branches).

If the merged worked fine then it is the new canonical line of
development and can be pushed to the head of the central repository
without problems.

So the cycle is:
commit -> push (if no other developer pushed anything before you)
or
commit -> pull -> update -> merge -> push (if someone pushed other
stuff before you)

See also:
http://www.ivy.fr/mercurial/ref/v1.0/Mercurial-Usage-v1.0.pdf

One other nasty thing that I forget sometimes with Hg cmdline is to do
'hg addremove' to actually add and remove files in the local repo.

Greetings,
Edwin

On 2 February 2010 03:41, Dave Koberstein <da...@ko...> wrote:
> Hi Edwin,
>
> I've got a commit.  I made it with 'hg commit'  Then I tried 'hg push' but
> got an error about creating new remote heads.  So next I tried an 'hg pull'
> and 'hg update'.  The pull worked but the update suggested I merge.  So now
> I've got a successful merge but lots of changed files.  Looks like the
> recent commits.
>
> So what do I do?  Can I commit this merge?  Is that going to do something
> funky to the repo when I 'hg push'?  I'm tempted to do another checkout just
> to be sure I don't mess up anything.
>
> Davek
>
>

[Gwt-openlayers-devl] contributions

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

Hi Dave,

Thanks for your contributions. I checked them out today.

Smart to add the getMap to the Control. One point: I renamed the
getMap method of OverviewMap to getOverviewMap (as it gets the ovmap
property) in order to avoid confusion with the getMap method of its
parent.

I closed ticket #31 after submitting changeset 214 with some very
basic example code to use SelectFeature in the DrawFeature example
(which appeared to be broken :(, but is fixed now :) ).  The unselect
method from SelectFeature was old code and could be removed.

About the showcase: I think it can be substantially improved if I had
the time but for now it works.

Greetings,
Edwin

P.S. To which mail adress can I best send mail addressed to you? The
mojix or komacke one, or some other?

[Gwt-openlayers-devl] about VectorFeatureAttributes

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

Hi Rafael,

I saw you added a class VectorFeatureAttributes.  I suppose the reason
to not work with a JSObject is to limit the type of attributes that
can be set. I am not sure, but it seems reasonable that a
VectorFeature does not have JavaScript function or object as
attribute.

However, it seems to me that this can be approached more generically
with an Attributes class, that allows for setting and getting
arbitrary properties that are more constrained than JSObject. Objects
that allow setting arbitrary attributes (not defined by any API) that
are not similarly constrained should use JSObject in my opinion.

With a generic Attributes class we get the least duplication of
JSObject functionality (that is getPropertyXxx/setPropertyXxx). The
Option objects for example set specific options, while the attributes
class would provide getters and setters that are as generic as those
on JSObject.

What do you (and other developers) think about refactoring
VectorFeatureAttributes to org.gwtopenmaps.openlayers.util.Attributes?
To me, there seems to be nothing in VectorFeatureAttributes that is
specific to a VectorFeature. While we are still pre 0.5 I think it is
still a good option to refactor.

If you agree I will go forward with the refactoring.

Greetings,
Edwin

Re: [Gwt-openlayers-devl] Building from maven

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

Hi Farrukh,

That is really great! If it is possible for you to update the wiki that
would be very nice, then I will update the website.

If I am correct GWT-OL is now in 0.5-SNAPSHOT, so there is a definitive 0.4
(There is a 0.4 tag in the Hg repo). There will maybe come a 0.4.1 update
release for the VectorFormat read method, but aside from that 0.5 will be
the next up.

Greetings,
Edwin

2009/9/18 Farrukh Najmi <fa...@we...>

>
> Hi Guys,
>
> I have taken the liberty to make 0.4 release available via maven from my
> maven repo. You need your maven pom file to look like below.
> Edwin, I can update wiki if you wish and then perhaps you can link to
> the wiki page contyent from:
>
> http://gwt-openlayers.sourceforge.net/
>
> Thanks.
>
> <project>
>
> ...
>
>  <dependencies>
>    <dependency>
>        <groupId>com.eg.gwt.openLayers</groupId>
>        <artifactId>openlayers_gwt</artifactId>
>        <version>0.4-SNAPSHOT</version>
>    </dependency>
>    ...
>  </dependencies>
>
>  <repositories>
>    <repository>
>      <id>wellfleet-repository</id>
>      <name>Wellfleet Repository</name>
>      <url>http://www.wellfleetsoftware.com/m2/repository/</url>
>      <layout>default</layout>
>      <snapshots>
>        <enabled>true</enabled>
>      </snapshots>
>    </repository>
>    ...
>  <repositories>
>
> </project>
>
> --
> Regards,
> Farrukh
>
> Web: http://www.wellfleetsoftware.com
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Gwt-openlayers-devl mailing list
> Gwt...@li...
> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl
>

[Gwt-openlayers-devl] Building from maven

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

Hi Guys,

I have taken the liberty to make 0.4 release available via maven from my 
maven repo. You need your maven pom file to look like below.
Edwin, I can update wiki if you wish and then perhaps you can link to 
the wiki page contyent from:

http://gwt-openlayers.sourceforge.net/

Thanks.

<project>

...

  <dependencies>
    <dependency>
        <groupId>com.eg.gwt.openLayers</groupId>
        <artifactId>openlayers_gwt</artifactId>
        <version>0.4-SNAPSHOT</version>
    </dependency>
    ...
  </dependencies>

  <repositories>
    <repository>
      <id>wellfleet-repository</id>
      <name>Wellfleet Repository</name>
      <url>http://www.wellfleetsoftware.com/m2/repository/</url>
      <layout>default</layout>
      <snapshots>
        <enabled>true</enabled>
      </snapshots>
    </repository>
    ...
  <repositories>

</project>

-- 
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com

Re: [Gwt-openlayers-devl] Measure control and styling in OL

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

*Hi Rafael,

Thanks for your reply! My responses below are in bold. But first up, the
OpenLayers developers have also noticed they have mixed up style and
symbolizer in many places, see:
http://trac.openlayers.org/ticket/1845

Ideally, style would be replaced by symbolizer in OpenLayers 3.0 (at least
it is scheduled for 3.0 with #1845). Personally, I think using the
terminology symbolizer is the only sensible choice, since that is OGC
standard terminology and that is why I would favor that for GWT-OL no matter
what OL does. We are not obliged to do a 1-on-1 mapping. We should off
course think well about diverging, but sometimes it is justified in my
opinion.

Greetings,
Edwin*

*P.S.* *I encountered some Natural Docs style comments in the code. Please
comment GWT-OL with plain JavaDoc, to have the befenits from tools like
Eclipse (all the other docs are JavaDoc comments).* *Documenting is greatly
encouraged, though I do not do it everywhere either (sometimes you just want
to get stuff in :-)...)*

2009/9/17 "Cerávolo, Rafael V.B." <raf...@gm...>

>  Hi Edwin,
>
> See my comments below (in red)
>
> Edwin Commandeur wrote:
>
> Hi Michel and Rafael,
>
> Hi there, I like to have your input on an issue regarding styling in OL.
> First I explain myself, after that I have a proposal. It all comes down to
> the fact that I think it should be fixed that
> 'org.gwtopenmaps.openlayers.client.Style' isn't a wrapper of
> 'OpenLayers.Style'.
>
> Michel made a start with the Measure control. This night (it's night here
> in the Netherlands), I started out implementing the listeners for Measure
> and MeasurePartial. That was the easy job and I committed it to Mercurial.
> After that, I started looking at styling the Measure control and that turned
> out to be somewhat more complex... This has to go via HandlerOptions (which
> I created a start of class hierarchy for) on which HandlerLayerOptions can
> be set that take a StyleMap... and wouldn't it be nice if we could create
> styles to fill the StyleMap in code... however, as yet, we can't.
> I created a class "StyleMap" (see
> http://sourceforge.net/apps/trac/gwt-openlayers/ticket/7), but I used and
> tested just on the StyleMap property of "Layer.Vector", if you could, try to
> use the "org.gwtopenmaps.openlayers.client.StyleMap" with HandlerOptions to
> see if it works.
>
> *Rafael,  I saw you created the StyleMap. The way I understand, the
StyleMap should work with HandlerOptions, and we can indeed create styles
for the map, because a style map takes symbolizers (and we wrap symbolizer*
*objects* *in* *org.gwtopenmaps.openlayers.client.Style). Yesterday, I
didn't immediately see it but the OL StyleMap is actually a SymbolizerMap.

The 'stylemap.html' example is especially misguiding, because it uses the
OpenLayers.Style constructor to construct objects that aren't styles at all.
It works because javascript sets all the properties on the object, but all
the properties are not actually properties of OpenLayers.Style. I like the
dynamic nature of JavaScript, but here you see where it can mess you up in a
large, complicate codebase (and OL is quite large now, it's awfully big for
a JS lib with over 600 kb in compressed, but not obfuscate form).
*

>
> If you look at the 'measure.html' example then you will see that an
> 'OpenLayers.Style' object is created with a rule that takes symbolizers. The
> symbolizers turn out to have the properties that our current
> 'org.gwtopenmaps.openlayers.client.Style' has (fillColor, strokeColor, etc).
> This prompted me to look closer at the 'OpenLayers.Style' class and if you
> look at the OpenLayers API doc, the style class properties do not correspond
> with the properties of 'org.gwtopenmaps.openlayers.client.Style'. In fact,
> 'org.gwtopenmaps.openlayers.client.Style' seems to wrap a symbolizer.
>
> As it turns out, Vector Layers in OL document they have a 'style property'
> and this 'style property' is not an 'OpenLayers.Style' object (To me this is
> confusing!!!), but it is the same type of object defined in:
> OpenLayers.Feature.Vector.style[default]
> You would expect to find a ready to use 'style object' there, but that is
> not the case! The object defined in OpenLayers.Feature.Vector.style[default]
> is actually a symbolizer as it is used in SLD's (have a look at the
> 'sld.html' example and inspect the sld variable on the Window object of the
> browser with Firebug). However, OL itself does not have a complete class
> hierarchy for creating a full SLD object. OL only has some of the classes
> that are used in creating SLDs and lacking is a Symbolizer class/are
> Symbolizer classes. Symbolizers are created in plain javascript object
> notation throughout OL.
> Yes, you're right, and know I'm a little confused too. Specially when
> looking at the StyleMap OL documentation (
> http://dev.openlayers.org/releases/OpenLayers-2.8/doc/apidocs/files/OpenLayers/StyleMap-js.html).
> The OL StyleMap class has a constructor that accepts a single style object
> or a hash of styles. And the examples I saw using StyleMap, they pass styles
> to the constructor as they where of the same class of
> OpenLayers.Feature.Vector.style[default], but as you said, they are not
> objects of the type 'OpenLayers.Style'.
>
> *We are not the only ones confused. The OL developers themselves are as
well, see #1845, which I already mentioned above:
http://trac.openlayers.org/ticket/1845

*

> So, what is referred to as a 'style' in the context of a Vector Feature &
> Vector Layer is actually a symbolizer. See also:
> OpenLayers-2.8\lib\OpenLayers\Feature\Vector.js
> Under:
> * Constant: OpenLayers.Feature.Vector.style
> you find:
> * Symbolizer properties:
>
> In the end it would be nice if we can create an SLD programmatically in
> GWT-OL, but first of all I think it would be nice if we avoid the naming
> confusion and use the word style in GWT-OL only to refer to something that
> is an 'OpenLayers.Style' object under the covers.
>
> I'm not very sure about that. The OL documentation uses the word "style" in
> many places for refering parameters and objects when they are in fact not an
> OpenLayers.Style object. So, someone that is new at OpenLayers and started
> using it directly with GWT-OpenLayers (as I did!), would expected that those
> places where the OL Docs says "style", should have a "Style" class in GWT or
> something closer to that. On the other hand if who is using GWT-OpenLayers
> have previously experience with OpenLayers.js than maybe is expected that
> the GWT Style class is the directly correspondent class for the JavaScript
> Style class.
>
> Other issue, is that changing the name of the Style class will break the
> compatibility with current code out-there using GWT-OpenLayers. We can do
> that, but we will need to put a very nice documentation about that!
> **
>
> *
**Rafael, I understand your* *concerns that people may get confused. But
actually, I think GWT-OL can take confusion away be already implementing
#1845, since it will give them different names for things that are different
and can let them see the difference*.* The JavaDoc should make it very clear
that the Vector.setSymbolizer() is equivalent to setting the style property
in OL. *

***Changing the name of Style will indeed breek compatibility with previous
code, and that should not be taken lightly, but GWT-OL is still in version
0.4. I would say that now is the time for making these kind of changes,
before we get stuck with something that we know we want to change in version
1.0 or above.*



The current org.gwtopenmaps.openlayers.client.Style object would than have
to be moved to some other class. For example, to:
org.gwtopenmaps.openlayers.client.style.Symbolizer

The symbolizer can have generic symbolizer state/behavior. I would like to
change the setStyle method in
org.gwtopenmaps.openlayers.client.layer.Vector  to setSymbolizer and explain
in the JavaDoc why it is named differently from the OL name.

There is no setStyle method yet on
org.gwtopenmaps.openlayers.client.feature.VectorFeature, but
OpenLayers.Feature.Vector does have a style API property. I would be in
favor to create a setSymbolizer method in GWT-OL instead of a setStyle
method.


What do you think about the name StyleProperties instead of Symbolizer? I
> think it will be easier to understand when following OL examples to do the
> same thing in GWT-OL.
>
> For example, when doing the following in JS:
>
> 	var template = {
>                 pointRadius: 10,
>                 fillColor: "red"
>             };
>             var style = new OpenLayers.Style(template);
>
> Will be better to "migrate" to GWT-OL using:
>
> StyleProperties template = new StyleProperties();
> template.setPointRadius(10);
> template.setFillColor("red");
>
> Style style = new Style(template);
>
>
> than when using:
>
> Symbolizer template = new Symbolizer();
> template.setPointRadius(10);
> template.setFillColor("red");
>
> Style style = new Style(template );
>
>  Or doing:
>
>  StyleProperties styleProp = new StyleProperties();
> styleProp.setFillColor("red");
> vectorLayer.setStyleProperties(styleProp);
>
>  Instead of:
>
>
> Symbolizer symb = new Symbolizer();
> symb.setFillColor("red");
> vectorLayer.setSymbolizer(symb);
>
>
*Rafael, thanks for providing the suggestion about StyleProperties, but I am
not really convinced that such a name would improve things. StyleProperties
would mean that we start introducing our own terminology. It is confusing
why StyleProperties is separate from Style and it is not standard OGC
terminology (OL terminology maps onto OGC terminology in a lot of places).

Also, I think we should follow in the footsteps of the 'stylemap.html'
example and create an OpenLayers.Style object, when it in fact has nothing
to do with an OpenLayers.Style object. That is dangerous, because we set
properties on an an Object that also has behaviour. Also, it is a waste of
memory, because a simple Object literal would suffice in Javascript to
create the StyleMap. For example, in the 'stylemap.html':

var myStyles = new OpenLayers.StyleMap({
                "default": {  pointRadius: "${type}",
                    fillColor: "#ffcc66",
                    strokeColor: "#ff9933",
                    strokeWidth: 2 },
                "select": {  fillColor: "#66ccff",
                    strokeColor: "#3399ff" }
            });
*
*This code example sidesteps the fact that StyleMap should have been called
SymbolizerMap.

What we could do alternatively, to not break code compatibility is to
deprecate Style and provide alternative methods that we recommend. **

**If Style is deprecated you could do both in GWT-OL 0.5:

Vector.setStyle(style); //deprecated, state in JavaDoc that setSymbolizer
should be used
Vector.setSymbolizer(Symbolizer symbolizer); //recommended

Then we would need to add/implement:
**org.gwtopenmaps.openlayers.client.style.Symbolizer
**org.gwtopenmaps.openlayers.client.style.SymbolizerMap *
*
For terminology see: http://www.opengeospatial.org/standards/sld

**The OpenLayers.Style class does not need to be wrapped just yet, but could
be wrapped under:
org.gwtopenmaps.openlayers.client.style.UserStyle (see constructor)
or just:
**org.gwtopenmaps.openlayers.client.style.Style
(As an aside: OpenLayers also doesn't distinguish between UserStyle and
FeatureTypeStyle, so although the constructor of OpenLayers.Style says it
creates a UserStyle, I am not to sure if that is really the case and if it
isn't the case that it creates something than can be a UserStyle or
FeatureTypeStyle.)*
*

*

> How do you guys feel about my suggestions? Do you have any suggestions?
> Currently, I have created a Symbolizer class under
> org.gwtopenmaps.openlayers.client.style. Is that package name okay or do you
> like org.gwtopenmaps.openlayers.client.symbolization better? The SLD spec
> states: "This document explains how the Web Map Server (WMS 1.0 [1] & 1.1
> [2]) specification can be extended to allow user-defined symbolization of
> feature data.", but also talks a lot about styling this and that.
>
> I would need to look more closely at the SLD and Symbology Encoding specs
> from the OGC and the SLD implementation in OpenLayers to see if it would
> make sense to have subclasses of Symbolizer, such as PointSymbolizer or a
> BaseSymbolizer (very generic), and different Symbolizers extending that
> class or one another.
> Greetings,
> Edwin
>
>  Regards,
> Ceravolo
>

[Gwt-openlayers-devl] Measure control and styling in OL

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

Hi Michel and Rafael,

Hi there, I like to have your input on an issue regarding styling in OL.
First I explain myself, after that I have a proposal. It all comes down to
the fact that I think it should be fixed that
'org.gwtopenmaps.openlayers.client.Style' isn't a wrapper of
'OpenLayers.Style'.

Michel made a start with the Measure control. This night (it's night here in
the Netherlands), I started out implementing the listeners for Measure and
MeasurePartial. That was the easy job and I committed it to Mercurial. After
that, I started looking at styling the Measure control and that turned out
to be somewhat more complex... This has to go via HandlerOptions (which I
created a start of class hierarchy for) on which HandlerLayerOptions can be
set that take a StyleMap... and wouldn't it be nice if we could create
styles to fill the StyleMap in code... however, as yet, we can't.

If you look at the 'measure.html' example then you will see that an
'OpenLayers.Style' object is created with a rule that takes symbolizers. The
symbolizers turn out to have the properties that our current
'org.gwtopenmaps.openlayers.client.Style' has (fillColor, strokeColor, etc).
This prompted me to look closer at the 'OpenLayers.Style' class and if you
look at the OpenLayers API doc, the style class properties do not correspond
with the properties of 'org.gwtopenmaps.openlayers.client.Style'. In fact,
'org.gwtopenmaps.openlayers.client.Style' seems to wrap a symbolizer.

As it turns out, Vector Layers in OL document they have a 'style property'
and this 'style property' is not an 'OpenLayers.Style' object (To me this is
confusing!!!), but it is the same type of object defined in:
OpenLayers.Feature.Vector.style[default]
You would expect to find a ready to use 'style object' there, but that is
not the case! The object defined in OpenLayers.Feature.Vector.style[default]
is actually a symbolizer as it is used in SLD's (have a look at the
'sld.html' example and inspect the sld variable on the Window object of the
browser with Firebug). However, OL itself does not have a complete class
hierarchy for creating a full SLD object. OL only has some of the classes
that are used in creating SLDs and lacking is a Symbolizer class/are
Symbolizer classes. Symbolizers are created in plain javascript object
notation throughout OL.

So, what is referred to as a 'style' in the context of a Vector Feature &
Vector Layer is actually a symbolizer. See also:
OpenLayers-2.8\lib\OpenLayers\Feature\Vector.js
Under:
* Constant: OpenLayers.Feature.Vector.style
you find:
* Symbolizer properties:

In the end it would be nice if we can create an SLD programmatically in
GWT-OL, but first of all I think it would be nice if we avoid the naming
confusion and use the word style in GWT-OL only to refer to something that
is an 'OpenLayers.Style' object under the covers.

The current org.gwtopenmaps.openlayers.client.Style object would than have
to be moved to some other class. For example, to:
org.gwtopenmaps.openlayers.client.style.Symbolizer

The symbolizer can have generic symbolizer state/behavior. I would like to
change the setStyle method in
org.gwtopenmaps.openlayers.client.layer.Vector  to setSymbolizer and explain
in the JavaDoc why it is named differently from the OL name.

There is no setStyle method yet on
org.gwtopenmaps.openlayers.client.feature.VectorFeature, but
OpenLayers.Feature.Vector does have a style API property. I would be in
favor to create a setSymbolizer method in GWT-OL instead of a setStyle
method.

How do you guys feel about my suggestions? Do you have any suggestions?
Currently, I have created a Symbolizer class under
org.gwtopenmaps.openlayers.client.style. Is that package name okay or do you
like org.gwtopenmaps.openlayers.client.symbolization better? The SLD spec
states: "This document explains how the Web Map Server (WMS 1.0 [1] & 1.1
[2]) specification can be extended to allow user-defined symbolization of
feature data.", but also talks a lot about styling this and that.

I would need to look more closely at the SLD and Symbology Encoding specs
from the OGC and the SLD implementation in OpenLayers to see if it would
make sense to have subclasses of Symbolizer, such as PointSymbolizer or a
BaseSymbolizer (very generic), and different Symbolizers extending that
class or one another.

Greetings,
Edwin

[Gwt-openlayers-devl] maven for gwt dependency

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

Hi all,

Please use Maven for the GWT-dependency of the main codebase and don't
enable 'use Google Web Toolkit' from the Google Eclipse plugin on the main
project. The Google Eclipse plugin will set paths that are specific to each
Eclipse + GWT SDK install.

The showcase still needs the GWT-plugin so there it is inevitable, but the
showcase can be loaded into Eclipse as a separate project on which you must
enable the Google Eclipse plugin.

Thanks for your appreciation,
Edwin

[Gwt-openlayers-devl] invoke methods

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

Hello Ying Xia,

Yesterday, I finally got round to making two test projects that were
identical except that one used the current GWT-OL (GWT-OL-normal) and the
other used a GWT-OL with centralized JSNI function invocation
(GWT-OL-invoke). I compiled them in detailed mode to see what the
differences would be.

Unexpectedly, quite a lot of extra javascript code is generated by GWT to
make the function invocation work. The GWT-OL-invoke was 150% the size of
GWT-OL-normal (45kb versus 30kb when obfuscated). Off course, extra code was
necessary because JSObject/JSObjectHelper contained more functionality, but
also in other classes significant amounts of extra code seems to be
generated.

I have looked a bit at other GWT libraries wrapping Javascript libraries and
in the SmartGWT library I found they also have a lot of helper methods for
doing setProperty/getProperty (setAttribute/getAttribute there), but no
helper methods for method invocation. I guess this might have a reason,
considering my findings.

Eventually, a smaller Javascript file for the user is more important than to
make it easier for us developers in my opinion. This is why I currently
think we should keep the Impl methods, so that GWT is more efficient at
generating Javascript.

Greetings,
Edwin

Re: [Gwt-openlayers-devl] Measure

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

Hi Michel,

At first sight this looks like formatOutput, but an important difference is
that handleMeasurements is not a function on the Measure control and you
have to do all the work for the output.

First up: In my opinion, the handleMeasurement function should not return
output (it also doesn't in the OpenLayers examples), because it's a
callback. You never know when people stop measuring and therefore when
measure will fire.

Looking at it my first impression is that you would want to make it easy to
set a handler for the onMeasure and onMeasurePartial events. The
SelectFeature control has something like this, using interfaces defined on
the class. For Measure this would be something like:

public interface MeasureListener(){
  void onMeasure(String measurements); // assuming that measurements are
passed as a String, which is a guess
}

The Measure control could have a setMeasureListener(MeasureListener
listener) method, that registers the listener. To see how that works, look
at the setFeatureControl

A user would then do:

Measure m = new Measure( args here );//instantiate control
m.setMeasureListener(new MeasureListener(){
  void onMeasure(String Measurements){
     // get place to write output the GWT way
     // do formatting and write to output place (e.g. a DOM element)
     // OR
     // call some other function to write output, that can also be called by
onMeasurePartially
  }
})

Greetings and I hope this is useful to you,
Edwin

2009/8/27 Michel vitor <mic...@gm...>

> Dear Edwin,
>
> I would like to further your explanation, my problem and I implemented the
> following function Measure of OpenLayers so that now I want to display the
> screen output in any format (ft, m etc.). And this is possible in java
> ecript.
> I'm trying to recreate in the java gwt-openlayers the following function
>
>             var control;
>             control = new
> OpenLayers.Control.Measure(OpenLayers.Handler.Path);
>             control.events.on({"measure":
> handleMeasurements,"measurepartial": handleMeasurements});
>             map.addControl(control);
>             map.setCenter(new OpenLayers.LonLat(0, 0), 3);
>         }
>
>         function handleMeasurements(x) {//this
>             var geometry = x.geometry;
>             var units = x.units;
>             var order = x.order;
>             var measure = x.measure;
>             var element = document.getElementById('output');
>             var out = "";
>             if(order == 1) {
>                 out += "measure: " + measure.toFixed(3) + " " + units;
>             } else {
>                 out += "measure: " + measure.toFixed(3) + " " + units +
> "<sup>2</" + "sup>";
>             }
>             return out;//return this value for component
>         }
>
> that looks a bit like formatOutput, but want to get the value and display
> in a component can you give me a help and my doubts as to the role that this
> prominent.
> --
> Michel Vitor A Rodrigues
> 6° Periodo de Computação
> Grupo Intec,Viçosa MG
>
>

[Gwt-openlayers-devl] GWT-OL OpenLayersObjectWrapper

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

Hi Michel,

What exactly are the doubts you have about OpenLayersObjectWrapper?

It extends JSObjectWrapper and wraps JSObject. JSObject is a class that adds
some functionality to JavaScriptObject. JavaScriptObject is the handle GWT
provides on Javascript objects (makes sense :-)....). For a deeper
understanding of JavaScriptObject and interacting with Javascript from GWT,
I would have to refer you to the GWT documentation. JSObject and other
classes from util help dealing with the Javascript/Java communication.

There are two ways to "wrap" a Javascript object:
a) provide a wrapper class that holds on to the Javascript object via the
handles GWT provides (in our case JSObject)
b) extend JavaScriptObject/JSObject directly, which GWT calls Overlay types

In GWT we have choosen for the first option. The only difference is that in
option (a) you do getJSObject() to get at the handle on the Javascript
object you are wrapping, while in option (b) you can access the handle on
your Javascript object via this.

Overlay types were not available when GWT-OL was created and I have a slight
favor for the explicit wrapping, as it makes it more clear that you are
"wrapping" something. It is a case of favoring Composition over Inheritance.
Also, then we do not need to do anything to hide methods defined on JSObject
to users.

OpenLayersObjectWrapper simply defines methods/properties that every
OpenLayers object will have, so these can be share by all classes wrapping
OpenLayers objects. Currently I it only has getClassName() and getEvents().
The latter is defined there because you also might want to test if a class
has an Events object (and fires events).

If you are wrapping a Javascript object and it is an OpenLayers object, then
you should extend OpenLayersObjectWrapper. If it is an OpenLayers object
that fires event, then you should extend OpenLayersEObjectWrapper. Otherwise,
you shouldn't extend OpenLayers(E)ObjectWrapper

StyleMap is an OpenLayers object so it would extend OpenLayersObjectWrapper.

If you do:
var sm = new OpenLayers.StyleMap();

Then you get an object with a CLASS_NAME. That is why it should be wrapped
by OpenLayersObjectWrapper.

Greetings,
Edwin





2009/8/21 Michel vitor <mic...@gm...>

> Dear Edwin,
>
> I'm trying to make a function in Measure OL  but I have a doubt about the
> class OpenLayersObjectWrapper and
> you could give me a description of their functionality
> because I need to create a class StyleMap.js.
>
> --
> Michel Vitor A Rodrigues
> 6° Periodo de Computação
> Grupo Intec,Viçosa MG
>
>

[Gwt-openlayers-devl] new developer

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

Hi Michel,

I added you as a developer to the project. You can try to add your changes
to Marker. Please check the outgoing changes with

hg outgoing

Before you do a 'hg push'.
If you do not feel comfortable with Mercurial yet, please work through the
Selenic tutorial or the Hg book (http://hgbook.red-bean.com/).

The developer reference describes how to set up Mercurial for commit access.

It would be nice to know what you plan to work on.

My task list (in the order presented below) is:
- Look at suggestion from Ying Xia to also add invoke methods to JSObject in
additon to get/setProperty. I am going to make 4 simple tests to see what
the GWT Compiler makes out get/setProperty and invoke, to see better
evaluate if it makes sense to have get/setProperty from the perspective of
the javascript that get's generated. Eventually it is more important that
effecient Javascript is generated than that we as developers can get around
using JSNI.

- Work on WFS support, including adding a Java proxy to the showcase that
works the same as the Python proxy.cgi

- Wrap WMSGetFeatureInfo Control and create showcase example

- Make it possible to add GWT Panels to OpenLayers Popups

- Create Markers showcase example

- Create Google Maps showcase example

Greetings,
Edwin

Re: [Gwt-openlayers-devl] Change GWT-OL

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

Hi Vitor,

Thanks for sending me the files. I also saw you nicely documented the
methods. I have been looking at the code and thinking about a way to avoid
having to change OpenLayers Markers.js. I noticed a small error in setLonLat
in MarkerImpl: you have to pass the Marker JSObject to the method as well,
to set/invoke stuff on it.

Any real change to OpenLayers code itself means that we would have to
maintain our own branch of OpenLayers or force users to build a custom
OpenLayers with our patches, so that would be a problem for maintenance.

I guess OpenLayers is not keen on adding the change, since they seem to
approach the problem differently. If I look at the markerResize example then
I see that they keep a reference to icon and change the properties of the
icon.

The way I see it now is that it would be less invasive to add a getIcon()
method to Marker in GWT-OL, that uses JSNI to get the icon property of the
Marker. On that Icon you can then change it's URL and it's size: Is that
sufficient for your purposes? I wonder if we can put sth into icon to also
be able to change the offset.

I see in your solution you create a new Icon and copy it's properties to the
icon of the Marker. I think that would not be necessary if we provide a way
to get at the icon and change it's properties directly.

Also for the setLonLat I would propose to set the lonlat via JSNI in GWT-OL
and not add anything to OpenLayers Markers.js (in order to avoid also having
to maintain OL code vs the way we use OL for our purposes). I think it
should be as simple as changing getIcon and setLonLat in MarkerImpl to:

    public static native JSObject getIcon(JSObject self)/*-{
        return self.icon;
    }-*/;

    public static native JSObject setLonLat(JSObject self, JSObject
lonlat)/*-{
        self.lonlat = lonlat;
    }-*/;

I am interested to know what you think. If we do stuff with "private"
variables in GWT-OL than it is up to us to maintain it, which I think is ok,
as long as people can just drop in a regular OpenLayers build and we don't
need a customized OpenLayers for GWT-OL to work.

If you are still interested I would be happy to add you to the team of
developers. There is a lot of stuff in OpenLayers we do not yet wrap and
every help on getting GWT-OL to wrap OL as completely as possible is
appreciated. Also, convenience stuff like making it able to do things with
the Icon of Markers is where GWT-OL can add value in addition to providing
type safety :-)...

Greetings,
Edwin

2009/8/19 Michel vitor <mic...@gm...>

> Dear Edwin,
>
> I am sending you an attachment with the two classes that also the modified
> form's javascript file Openlayers with the two new functions.
> As they leave that changed the sources did it for personal use.
> If you have any suggestions on how to do this in anything but I am
> available.
>
> --
> Michel Vitor A Rodrigues
> 6° Periodo de Computação
> Grupo Intec,Viçosa MG
>
>

[Gwt-openlayers-devl] More suggestions about org.gwtopenmaps.openlayers.client.util.JSObject

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

Hi Ying Xia,

Sorry I misspelled your name on a previous post. I have deleted that post.
Here it is the content again for the developer list:

I have been playing a bit with implemeting one or more invoke methods.

When functions are invoked it is on OpenLayers objects (The
getProperty/setProperty methods are for the config objects, and it's never
necessary to invoke functions on config objects). Often these functions
return values and I think it may get messy to get the return values by their
correct type.

Maybe you have some suggestions when you looking at what I have written
below, since it looks like you were already using code to invoke functions
(or did you create that after seeing getProperty/setProperty?). What did you
do if a function returned a String, floating point number, or integer?
Please read on to see what I mean.

I found that I needed the following to code to invoke toString of Size and
have it return a String (for an easy example and for briefness I made a
variant to invoke functions that do not take arguments):

in JSObjectHelper:
public static native Object invoke(JSObject object, String name) /*-{
  return object[name].apply(object);
 }-*/;


in JSObject:
public final Object invoke(String name) {
  return JSObjectHelper.invoke(this, name); };

invoking toString of Size:
public String toString(){
  return (String) getJSObject().invoke("toString");
}

As you might have notice an Object is returned.by the
JSObjectHelper/JSObject return methods. Returning a JSObject did not work,
because that cannot be cast to a String and I also could not get a working
narrowToString function on JSObject. It is a bit vague to my why returning
Object did work. As an implementation of narrowToString I tried:

public static native String narrowToString(JSObject object) /*-{
  return object; //Gives a ClassCast exception
 }-*/;

Although this works, and I can image it works with your way to pass
arguments, I can foresee some uglyness when an integer or float is returned
from the invoked function. Right now a lot of the API works with primitives
and there is a mismatch between Object and primitives. I'd rather avoid
autoboxing so then you may get things like:

Float f = (Float) getJSObject().invoke("getHeight");
return f.floatValue();

An uglier problem is how to combine this with the possibility that a complex
Javascript object is returned, because that would have to be returned as a
JSObject. In Java functions with the same signature but different return
tyehpes are not allowed, so we cannot have both:
public final Object invoke(String name){ ... };
public final JSObject invoke(String name){ ... };

Re: [Gwt-openlayers-devl] Some suggestions about org.gwtopenmaps.openlayers.client.util.JSObject

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

Hi Jing Xia,

I have been playing a bit with implemeting one or more invoke methods.

When functions are invoked it is on OpenLayers objects (The
getProperty/setProperty methods are for the config objects, and it's never
necessary to invoke functions on config objects). Often these functions
return values and I think it may get messy to get the return values by their
correct type.

Maybe you have some suggestions when you looking at what I have written
below, since it looks like you were already using code to invoke functions
(or did you create that after seeing getProperty/setProperty?). What did you
do if a function returned a String, floating point number, or integer?
Please read on to see what I mean.

I found that I needed the following to code to invoke toString of Size and
have it return a String (for an easy example and for briefness I made a
variant to invoke functions that do not take arguments):

in JSObjectHelper:
public static native Object invoke(JSObject object, String name) /*-{
  return object[name].apply(object);
 }-*/;


in JSObject:
public final Object invoke(String name) {
  return JSObjectHelper.invoke(this, name); };

invoking toString of Size:
public String toString(){
  return (String) getJSObject().invoke("toString");
}

As you might have notice an Object is returned.by the
JSObjectHelper/JSObject return methods. Returning a JSObject did not work,
because that cannot be cast to a String and I also could not get a working
narrowToString function on JSObject. It is a bit vague to my why returning
Object did work. As an implementation of narrowToString I tried:

public static native String narrowToString(JSObject object) /*-{
  return object; //Gives a ClassCast exception
 }-*/;

Although this works, and I can image it works with your way to pass
arguments, I can foresee some uglyness when an integer or float is returned
from the invoked function. Right now a lot of the API works with primitives
and there is a mismatch between Object and primitives. I'd rather avoid
autoboxing so then you may get things like:

Float f = (Float) getJSObject().invoke("getHeight");
return f.floatValue();

An uglier problem is how to combine this with the possibility that a complex
Javascript object is returned, because that would have to be returned as a
JSObject. In Java functions with the same signature but different return
tyehpes are not allowed, so we cannot have both:
public final Object invoke(String name){ ... };
public final JSObject invoke(String name){ ... };

I would like to hear your thoughts on how we can make

Greetings,
Edwin Commandeur

P.S.  If a JSObject comes back that would just have to be narrowed to the
appropriate type, for example:
Bounds.narrowToBounds(getJSObject().invoke("getBounds"));


Hi Jing Xia,
>
> The reason to extend JavaScriptObject and to have setProperty and
> getProperty methods is because OpenLayers works a lot with config objects.
> These config objects are not existing javascript objects so they necessitate
> creating javascript objects from scratch, which in turn requires JSNI. To
> reduce the amount of JSNI the setProperty/getProperty methods were
> introduced.
>
> The setProperty and getProperty methods on JSObject can already be used to
> set methods (or rather functions in javascript) on the JSObject via
> setProperty(obj:JSObject). A function is a JSObject, see for example
> setFormatOutput on 'MousePositionOptions'  and formatOutput on
> 'MousePositionImpl' .
>
> The Impl classes will be necessary at least for create methods that call
> existing constructors.
>
> I need to take a closer look at your code to understand the impact.
>
> There are already helper classes for working with Arrays by the way. Notice
> that an Array created by GWT does not pass the instanceof Array test in
> javascript (that is why there are relay methods in the javascript file that
> comes with GWT-OL)
>
> Greetings,
> Edwin
>
> 2009/8/12 岚山.隐 <642...@qq...>
>
> I spend hours to see the source code of the project. I think it is very
>> cool when I saw the encapsulated methods "setProperty" and "getPropertyAs*"
>> which makes all set and get javascript property code come to one place.
>> Then I think about for minutes, if property can, why not method! So I
>> started to encapsulate method just as how you have done on property.
>> The following is my code, whether it could be used on this project? I
>> think that piece this together with the JSObject class will disappear all
>> the "*Impl" classes in this project.
>>
>>
>> package com.yingxia.client.jsni;
>>
>> import com.google.gwt.core.client.JavaScriptObject;
>>
>> public class JavaScriptObjectWrapper extends JavaScriptObject {
>>
>>  protected JavaScriptObjectWrapper() {
>>  }
>>
>>  public static native JavaScriptObjectWrapper createNew() /*-{
>>   return {};
>>  }-*/;
>>
>>  public final JavaScriptObjectWrapper invokeJSMethod(String methodName,
>> Object... objs) {
>>   JavaScriptObjectWrapper arguments =
>> JavaScriptArrayHelper.toJSArray(objs);
>>   return JavaScriptObjectWrapperImpl.invokeJSMethod(this, methodName,
>> arguments);
>>  }
>>
>> }
>>
>> package com.yingxia.client.jsni;
>>
>> public class JavaScriptObjectWrapperImpl {
>>
>>  public static native JavaScriptObjectWrapper
>> invokeJSMethod(JavaScriptObjectWrapper jsObject, String methodName,
>> JavaScriptObjectWrapper arguments) /*-{
>>   return jsObject[methodName].apply(jsObject, arguments);
>>  }-*/;
>>
>> }
>>
>> package com.yingxia.client.jsni;
>>
>> public class JavaScriptArrayHelper {
>>  /**
>>   *
>>   * @param objs : must be primitive type or JavaScriptObject, now just
>> support few you can extend
>>   * @return
>>   */
>>  public static JavaScriptObjectWrapper toJSArray(Object... objs) {
>>
>>   JavaScriptObjectWrapper jsArray = createJSArray();
>>
>>   for(int i = 0; i < objs.length; i++) {
>>    setJSArray(jsArray, i, objs[i]);
>>   }
>>
>>   return jsArray;
>>  }
>>
>>  private static native JavaScriptObjectWrapper createJSArray() /*-{
>>   return [];
>>  }-*/;
>>
>>  private static void setJSArray(JavaScriptObjectWrapper jsArray, int
>> index, Object value) {
>>   if(value.getClass().equals(java.lang.Integer.class)) {
>>    setJSArray(jsArray, index, (int) Integer.valueOf(value.toString()));
>>   }
>>   if(value.getClass().equals(java.lang.Float.class)) {
>>    setJSArray(jsArray, index, (float) Float.valueOf(value.toString()));
>>   }
>>   if(value.getClass().equals(java.lang.Double.class)) {
>>    setJSArray(jsArray, index, (double) Double.valueOf(value.toString()));
>>   }
>>   if(value.getClass().equals(java.lang.Boolean.class)) {
>>    setJSArray(jsArray, index, (boolean)
>> Boolean.valueOf(value.toString()));
>>   }
>>   if(value.getClass().equals(java.lang.String.class)) {
>>    setJSArray(jsArray, index, value.toString());
>>   }
>>   if(value.getClass().equals(JavaScriptObjectWrapper.class)) {
>>    setJSArray(jsArray, index, (JavaScriptObjectWrapper) value);
>>   }
>>  }
>>
>>  private static native void setJSArray(JavaScriptObjectWrapper jsArray,
>> int index, int value) /*-{
>>   jsArray[index] = value;
>>  }-*/;
>>
>>  private static native void setJSArray(JavaScriptObjectWrapper jsArray,
>> int index, float value) /*-{
>>   jsArray[index] = value;
>>  }-*/;
>>
>>  private static native void setJSArray(JavaScriptObjectWrapper jsArray,
>> int index, double value) /*-{
>>   jsArray[index] = value;
>>  }-*/;
>>
>>  private static native void setJSArray(JavaScriptObjectWrapper jsArray,
>> int index, boolean value) /*-{
>>   jsArray[index] = value;
>>  }-*/;
>>
>>  private static native void setJSArray(JavaScriptObjectWrapper jsArray,
>> int index, String value) /*-{
>>   jsArray[index] = value;
>>  }-*/;
>>
>>  private static native void setJSArray(JavaScriptObjectWrapper jsArray,
>> int index, JavaScriptObjectWrapper value) /*-{
>>   jsArray[index] = value;
>>  }-*/;
>> }
>>
>>
>> Greetings,
>> ying xia
>>
>
>

Re: [Gwt-openlayers-devl] Some suggestions about org.gwtopenmaps.openlayers.client.util.JSObject

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

Hi Ying Xia,

Thanks for diving into the code, and good to hear you like the
setProperty/getProperty idea. The package name was intentionally changed to
org.gwtopenmaps.openlayers vs org.openlayers, so we could some day move GWT
utility stuff out to org.gwtopenmaps.commons or something like that. I guess
GWT doesn't include that stuff, because the real power of GWT is when you
use native GWT vs native javascript, but truly porting OpenLayers would be a
very big job!

I now understand the idea of your code is not to "set a function" on a
JSObject, but to "call a function" on a JSObject. The latter means that the
function should already be defined on the object in Javascript. That is
actually an interesting idea.

I can image that JSObject offers a method "invoke" which calls a function on
the javascript object represented by JSObject. I will try that out and see
if how it works out in GWT-OL. One first thing that comes to mind is what to
do with functions that return values. If invoke is generic it will probably
return JSObject (maybe have an "invokeVoid" for functions that do not return
values, and "invoke" for functions that return values). I am always a bit
hazy on how good casting works in GWT. Anyway, I will play around with it.

In GWT-OL the name "wrapper" is used for classes that keep a reference to
the object they wrap, and that delegate method invocations to wrapped object
reference. For example JSObjectWrapper has a JSObject property. Methods
exposed by a class that extends JSObjectWrapper are eventually called on the
JSObject. To my mind, your JavaScriptObjectWrapper is actually extending
JavaScriptObject, rather than wrapping it, but that is just a difference in
terminology.

Greetings and thanks for thinking with us,
Edwin

2009/8/12 岚山.隐 <642...@qq...>

> I spend hours to see the source code of the project. I think it is very
> cool when I saw the encapsulated methods "setProperty" and "getPropertyAs*"
> which makes all set and get javascript property code come to one place.
> Then I think about for minutes, if property can, why not method! So I
> started to encapsulate method just as how you have done on property.
> The following is my code, whether it could be used on this project? I think
> that piece this together with the JSObject class will disappear all the
> "*Impl" classes in this project.
>
>
> package com.yingxia.client.jsni;
>
> import com.google.gwt.core.client.JavaScriptObject;
>
> public class JavaScriptObjectWrapper extends JavaScriptObject {
>
>  protected JavaScriptObjectWrapper() {
>  }
>
>  public static native JavaScriptObjectWrapper createNew() /*-{
>   return {};
>  }-*/;
>
>  public final JavaScriptObjectWrapper invokeJSMethod(String methodName,
> Object... objs) {
>   JavaScriptObjectWrapper arguments =
> JavaScriptArrayHelper.toJSArray(objs);
>   return JavaScriptObjectWrapperImpl.invokeJSMethod(this, methodName,
> arguments);
>  }
>
> }
>
> package com.yingxia.client.jsni;
>
> public class JavaScriptObjectWrapperImpl {
>
>  public static native JavaScriptObjectWrapper
> invokeJSMethod(JavaScriptObjectWrapper jsObject, String methodName,
> JavaScriptObjectWrapper arguments) /*-{
>   return jsObject[methodName].apply(jsObject, arguments);
>  }-*/;
>
> }
>
> package com.yingxia.client.jsni;
>
> public class JavaScriptArrayHelper {
>  /**
>   *
>   * @param objs : must be primitive type or JavaScriptObject, now just
> support few you can extend
>   * @return
>   */
>  public static JavaScriptObjectWrapper toJSArray(Object... objs) {
>
>   JavaScriptObjectWrapper jsArray = createJSArray();
>
>   for(int i = 0; i < objs.length; i++) {
>    setJSArray(jsArray, i, objs[i]);
>   }
>
>   return jsArray;
>  }
>
>  private static native JavaScriptObjectWrapper createJSArray() /*-{
>   return [];
>  }-*/;
>
>  private static void setJSArray(JavaScriptObjectWrapper jsArray, int index,
> Object value) {
>   if(value.getClass().equals(java.lang.Integer.class)) {
>    setJSArray(jsArray, index, (int) Integer.valueOf(value.toString()));
>   }
>   if(value.getClass().equals(java.lang.Float.class)) {
>    setJSArray(jsArray, index, (float) Float.valueOf(value.toString()));
>   }
>   if(value.getClass().equals(java.lang.Double.class)) {
>    setJSArray(jsArray, index, (double) Double.valueOf(value.toString()));
>   }
>   if(value.getClass().equals(java.lang.Boolean.class)) {
>    setJSArray(jsArray, index, (boolean) Boolean.valueOf(value.toString()));
>   }
>   if(value.getClass().equals(java.lang.String.class)) {
>    setJSArray(jsArray, index, value.toString());
>   }
>   if(value.getClass().equals(JavaScriptObjectWrapper.class)) {
>    setJSArray(jsArray, index, (JavaScriptObjectWrapper) value);
>   }
>  }
>
>  private static native void setJSArray(JavaScriptObjectWrapper jsArray, int
> index, int value) /*-{
>   jsArray[index] = value;
>  }-*/;
>
>  private static native void setJSArray(JavaScriptObjectWrapper jsArray, int
> index, float value) /*-{
>   jsArray[index] = value;
>  }-*/;
>
>  private static native void setJSArray(JavaScriptObjectWrapper jsArray, int
> index, double value) /*-{
>   jsArray[index] = value;
>  }-*/;
>
>  private static native void setJSArray(JavaScriptObjectWrapper jsArray, int
> index, boolean value) /*-{
>   jsArray[index] = value;
>  }-*/;
>
>  private static native void setJSArray(JavaScriptObjectWrapper jsArray, int
> index, String value) /*-{
>   jsArray[index] = value;
>  }-*/;
>
>  private static native void setJSArray(JavaScriptObjectWrapper jsArray, int
> index, JavaScriptObjectWrapper value) /*-{
>   jsArray[index] = value;
>  }-*/;
> }
>
>
> Greetings,
> ying xia
>

Re: [Gwt-openlayers-devl] GWT OpenLayers 0.4 finally released

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

Hi Edwin,

Congratulations and many thanks for the hard work.

Edwin Commandeur wrote:
> Hi there,
>
> GWT-OL 0.4 is finally out of the pipeline. I think I have updated 
> every bit that needs to be updated. If you find anything that isn't 
> working, please let me know. I hope to get the API docs online soon. I 
> found there are some warnings that need to be taken care off. I will 
> look deeper into the API docs for version 0.5.
>
> Now we can move on to make GWT-OL even better with GWT-OL 0.5.
>
> If you got milestone issues for 0.5 please add them to the tracker. I 
> still have to find the best way to get some kind of overview of what 
> GWT-OL x.y covers and what coming releases intend to cover. 
> Suggestions are more than welcome. For now, the Tracker is the place 
> to put the latter.
>


-- 
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com

[Gwt-openlayers-devl] GWT OpenLayers 0.4 finally released

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

Hi there,

GWT-OL 0.4 is finally out of the pipeline. I think I have updated every bit
that needs to be updated. If you find anything that isn't working, please
let me know. I hope to get the API docs online soon. I found there are some
warnings that need to be taken care off. I will look deeper into the API
docs for version 0.5.

Now we can move on to make GWT-OL even better with GWT-OL 0.5.

If you got milestone issues for 0.5 please add them to the tracker. I still
have to find the best way to get some kind of overview of what GWT-OL x.y
covers and what coming releases intend to cover. Suggestions are more than
welcome. For now, the Tracker is the place to put the latter.

Greetings,
Edwin

[Gwt-openlayers-devl] 0.4 up for download, removed CVS

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

Hi all,

A binary for GWT-OL 0.4 is now available to download and I tagged Mercurial
for the 0.4 release. The only thing I cannot easily update is the website as
my ftp settings are broken. Somehow SourceForge broke something and I need
to find out how to connect again...

I turned off the CVS repository, as it is confusing for outsiders that there
are two repositories, and all the version history of the CVS repository is
inside the Mercurial repository.
According to the feature settings page the CVS data is retained:
"If you disable a feature, data will be retained, but will not be visible
until the feature is re-enabled."
I cannot check that however, because the feature settings page won't
correctly show additional features right now (hopefully this is temporarily)

Right now I am working on describing how to get the showcase running easily,
and I would also like to enhance the showcase. For users it seems a
showcase.zip download with the eclipse project is the best option, for
developers the mecurial repo is the place to get the showcase code. It seems
two repository clones, one for the GWT-OL codebase and one for the showcase
codebase, is the best option for development.

The two things I am still unhappy with are the Tracker and the wiki. The
Tracker because it is not user and admin friendly, and the wiki because it
is awfully slow. I tried enabling Trac, but that only seems to work well
with SVN enabled. Does anyone has any suggestions as to the tracker and
wiki?

Greetings,
Edwin

Re: [Gwt-openlayers-devl] migrated cvs to hg

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

Hi Edwin,

Thanks very much for this valuable contribution!

Edwin Commandeur wrote:
> Dear all,
>
> I finally managed to migrate the CVS repository to our Mercurial 
> repository. This has cost me quite some time, fiddling with cygwin 
> (for cvsps) and finding my way around mercurial.
>
> The base package is now renamed to 'org.gwtopenmaps.openlayers.client' 
> and everything seems to work.
>
> Feel free to clone the central repo, and let me know if it all works 
> for you! I added some information about using Mercurial on the 
> developer reference on the wiki.
>
> Now that the Mercurial repository is up and running I will have a look 
> how I can make a tag and release 0.4 into the wild. I have a base 
> example running, that I need to describe a bit on the wiki, which I 
> plan to do when I have another bit of spare time for the release.

-- 
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com

[Gwt-openlayers-devl] migrated cvs to hg

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

Dear all,

I finally managed to migrate the CVS repository to our Mercurial repository.
This has cost me quite some time, fiddling with cygwin (for cvsps) and
finding my way around mercurial.

The base package is now renamed to 'org.gwtopenmaps.openlayers.client' and
everything seems to work.

Feel free to clone the central repo, and let me know if it all works for
you! I added some information about using Mercurial on the developer
reference on the wiki.

Now that the Mercurial repository is up and running I will have a look how I
can make a tag and release 0.4 into the wild. I have a base example running,
that I need to describe a bit on the wiki, which I plan to do when I have
another bit of spare time for the release.

Greetings,
Edwin

Re: [Gwt-openlayers-devl] release 0.4 imminent

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

Hi Edwin,

Kudos on this terrific news and all the hard work. I hope to try out the 
new release soon. Thanks again.

Edwin Commandeur wrote:
> Dear all,
>
> We are closing in on releasing 0.4 if it's up to me...
>
> -The Options class is now refactored out of the codebase, and I have 
> create XxxOptions for all Controls (most of 'em empty, but they will 
> be filled with methods in release 0.5). The handlers are also 
> refactored, since the handler classes seemed to be the only bit of 
> code with a getJSClass method instead of a create method. In the quest 
> to make all methods as typesafe as possible, DrawFeature now takes a 
> Handler as argument instead of a JSObject.
>
> -I started creating a User Reference and Developer Reference on the 
> wiki, which should have some minimal content for 0.4. I will also 
> adjust the website to point to these reference documents and to link 
> to the API docs.
>
> -The Mercurial repository is enabled and I have committed the first 
> files into the repository. I am disappointed about the Eclipse support 
> for Mercurial, but the commandline mercurial tool works very good, and 
> it's not complicated at all. I am already happy to have only one .hg 
> directory with the complete repo and history, which is very nice.
>
> TO DO:
> - Rename the package to 'org.gwtopenmaps.openlayers' and commit that 
> to Mercurial (I will also see if I can move the CVS history to Mercurial)
>
> - Make a build (test maven and ant build scripts), test if it works, 
> make a 0.4 tag in Mercurial and release the build
>
> - Update the website
>
> - Keep enhancing the documentation
>
> - Make a roadmap for 0.5 :-)...
>


-- 
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com

Re: [Gwt-openlayers-devl] [offtopic] Seeking suggestions for a map API for Java Swing

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

Hi Farrukh,

Have you looked at the swing client in GeoTools? According to what I heard
the Swing client is progressing in GeoTools 2.5.x ... but I only know an old
demo and I never used it in production.

GeoTools can be a bit daunting, but if you know what you're looking for then
you should be able to get at it.

Let me know if you find something that works good. We are now using
mapXtreme from mapinfo in a Swing application, but we are not very happy
with it and would like to replace it. But who knows, maybe mapXtreme is oke
for you?

Greetings,
Edwin


2009/5/4 Farrukh Najmi <fa...@we...>

> 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
>
>
>
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Gwt-openlayers-devl mailing list
> Gwt...@li...
> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-devl
>

[Gwt-openlayers-devl] release 0.4 imminent

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

Dear all,

We are closing in on releasing 0.4 if it's up to me...

-The Options class is now refactored out of the codebase, and I have create
XxxOptions for all Controls (most of 'em empty, but they will be filled with
methods in release 0.5). The handlers are also refactored, since the handler
classes seemed to be the only bit of code with a getJSClass method instead
of a create method. In the quest to make all methods as typesafe as
possible, DrawFeature now takes a Handler as argument instead of a JSObject.

-I started creating a User Reference and Developer Reference on the wiki,
which should have some minimal content for 0.4. I will also adjust the
website to point to these reference documents and to link to the API docs.

-The Mercurial repository is enabled and I have committed the first files
into the repository. I am disappointed about the Eclipse support for
Mercurial, but the commandline mercurial tool works very good, and it's not
complicated at all. I am already happy to have only one .hg directory with
the complete repo and history, which is very nice.

TO DO:
- Rename the package to 'org.gwtopenmaps.openlayers' and commit that to
Mercurial (I will also see if I can move the CVS history to Mercurial)

- Make a build (test maven and ant build scripts), test if it works, make a
0.4 tag in Mercurial and release the build

- Update the website

- Keep enhancing the documentation

- Make a roadmap for 0.5 :-)...

With kind regards,
Edwin