Open GoogleCodeExporter opened 9 years ago
Fixed pos. 1.
Original comment by wolfram.winter
on 17 Sep 2013 at 11:22
Add point 5.): the query builder is not able to get a second query
A few remarks at this point (I've done a lots of debugging...):
- with 4.) and 5.) the query panel is NOT fit for production
- my WFS geoserver stops showing the contents of layer attributes, if something
on the GXP side is going wrong!!
- there seems to be more GREAT holes in GXP as I suspected - this library seems
not very stable at this point for me - have a look at the recursive line code:
at this point the next error message popped up!
I really like this query box but again: NOT for any production purposes!
What shall we do???
Original comment by wolfram.winter
on 20 Sep 2013 at 10:18
Attachments:
hi, any news with the resolution of this issue?
Original comment by martinsv...@gmail.com
on 18 Sep 2014 at 6:24
Hi Martin, I've had a quick look on it because there have been some GXP fixes
meanwhile - but the problems still remains - tested for 3.) - 5.).
Original comment by wolfram.winter
on 19 Sep 2014 at 10:07
yes, I have problems with points 3 and 5. Thanks for your answer, Wolfram.
Original comment by martinsv...@gmail.com
on 19 Sep 2014 at 12:31
Is there a specific version of 'Geoserver' where the points 3 and 5 are working
properly?
Original comment by martinsv...@gmail.com
on 19 Sep 2014 at 3:11
It seems like points 3 and 5 are about the same issue. I've tested on both
Chrome and IE 11+9 with
http://lib.heron-mc.org/heron/latest/examples/querybuilder/index.html but could
not reproduce. I can always query multiple times. What happens now and then is
that the WFS from OpenGeo/Boundless is down or very busy.
The only thing I noticed was a failure in the WFS Layer when zooming in the
first time, but this is unrelated to the Query Builder:
Uncaught NamespaceError: Failed to execute 'setAttributeNS' on 'Element': 'undefined' is an invalid namespace for attributes. OpenLayers.js:258OpenLayers.Format.XML.OpenLayers.Class.setAttributeNS OpenLayers.js:258OpenLayers.Format.WFST.v1_0_0.writers.wfs.OpenLayers.Util.applyDefaults.Query Heron.js:88OpenLayers.Format.XML.OpenLayers.Class.writeNode OpenLayers.js:260OpenLayers.Format.WFST.v1.writers.wfs.GetFeature Heron.js:73OpenLayers.Format.XML.OpenLayers.Class.writeNode OpenLayers.js:260OpenLayers.Protocol.WFS.v1.OpenLayers.Class.read OpenLayers.js:842OpenLayers.Strategy.BBOX.OpenLayers.Class.triggerRead OpenLayers.js:1057OpenLayers.Strategy.BBOX.OpenLayers.Class.update OpenLayers.js:1055OpenLayers.Events.OpenLayers.Class.triggerEvent OpenLayers.js:135OpenLayers.Map.OpenLayers.Class.moveTo OpenLayers.js:200OpenLayers.Map.OpenLayers.Class.setCenter OpenLayers.js:193OpenLayers.Control.Navigation.OpenLayers.Class.wheelChange OpenLayers.js:1044OpenLayers.Control.Navigation.OpenLayers.Class.wheelUp OpenLayers.js:1044OpenLayers.Handler.OpenLayers.Class.callback OpenLayers.js:600OpenLayers.Handler.MouseWheel.OpenLayers.Class.wheelZoom OpenLayers.js:681OpenLayers.Handler.MouseWheel.OpenLayers.Class.onWheelEvent OpenLayers.js:681(anonymous function)
Original comment by jus...@gmail.com
on 22 Sep 2014 at 9:46
The above error, though unrelated to this issue and Chrome-like browsers only
has been fixed in rev r1564. The problem was the include order in index.html
of examples: Heron JS must always be before config JS!
Still the original items needs to be verified if they are still there
especially 3/5...
Original comment by jus...@gmail.com
on 22 Sep 2014 at 11:38
Hi, my problem with the points 3 and 5 was solved by changing the IP layer
called WMS in openlayers (DefaultOptionsWorld.js file). Example: localhost:8080
to 192.168.0.101:8080 (ip in local network)
This hope is helpful for those who have the same problem.
In spanish:
Mi problema con los puntos 3 y 5 se solucionó cambiando la ip de llamado de
capas WMS en openlayers (archivo DefaultOptionsWorld.js). Ejemplo:
localhost:8080 a 192.168.0.101:8080 (ip en la red local)
Espero sea de ayuda para los que tienen el mismo problema.
Original comment by martinsv...@gmail.com
on 25 Sep 2014 at 12:40
?? I am somewhat confused here: how can changing localhost:8080 to
192.168.0.101:8080 be a generic solution for all?
I still cannot reproduce issues 3 and 5 on any browser.
Can someone look into and report here:
- why/how issues 3 and 5 are the same?
- report the exact context of possible errors of 3 and 5?
Original comment by jus...@gmail.com
on 25 Sep 2014 at 1:21
Hi everybody - I started again to examine this issue with the last rev 1566
(see #4). Using the 'latest examples link' I could NOT reproduce error 3 + 5
(newest FF, IE8, IE11)!! Using the examples from the trunk on our own web
server the IE8 doesn't work: the query listbox is not populated (new behavior -
was not so formerly).
I tried to find the differences between both scenarios and ended with: the
'latest examples' are using the 'Heron.js' method, the trunk example is using
the 'DynLoader.js' version.
I'm a bit confused now - I thought both versions should be identical, or ...???
Original comment by wolfram.winter
on 25 Sep 2014 at 7:03
Regarding Heron.js vs DynLoader.js: the examples within SVN/trunk import
DynLoader.js i.e.
<script type="text/javascript" src="../../lib/DynLoader.js"></script>
This is mainly to facilitate local debugging (otherwise Heron.js would need to
be built after each edit). For example in my local dev environment I always
have the webserver point to the SVN Heron trunk directory such that after each
edit the changed files can be immediately tested by reloading the example in
the browser. This would also be the case when using the "startheron.sh|bat"
script.
The Heron distribution build process will change this to:
<script type="text/javascript" src="../../script/Heron.js"></script>
Mainly for efficiency. The examples on
http://lib.heron-mc.org/heron/latest/examples are from the distribution that is
built each time someone checks in code into SVN. So yes, this may be somewhat
confusing, but there is a reason. DynLoader.js should never be used in
production.
Still: both DynLoader.js and Heron.js should behave identical, but appearantly
they are not. Is there again not some sort of caching going on?
Original comment by jus...@gmail.com
on 27 Sep 2014 at 11:22
Original issue reported on code.google.com by
wolfram.winter
on 17 Sep 2013 at 10:54