should go = shouldn't go
Sry, again...

Am 25.08.2010 11:21, schrieb Slawomir Messner:
>  Ok, now I have realized it completely.
> But the third point also matters in the case of "static" maps.
> @Andreas: Sry, the first mail should go directly to you.
> Regards,
> Slawomir
>
>
> Am 25.08.2010 11:05, schrieb Andreas Hocevar:
>> Again, Control.Permalink and Control.ArgParser were designed for maps 
>> where users cannot add or remove layers. Once you realize that, 
>> you'll see that these controls do their job well.
>>
>> For maps where users can add and remove layers, you need your own 
>> permalink and argparser implementations.
>>
>> Regards,
>> Andreas.
>>
>> On Aug 25, 2010, at 10:23 , Slawomir Messner wrote:
>>
>>>   Hi,
>>> if I read the code of Permalink and ArgParser right it's a pretty
>>> confusing behaviour at all, especially if you have an application with
>>> dynamic loading of layers.
>>> While I'm working with these controls I noticed some other things:
>>> 1. If A sends his link, then changes the visibility of the third layer
>>> during his work than A has the same url like B. I think for a normal
>>> user pretty confusing to have to different links for one view.
>>>
>>> 2. If we change Andreas's example a little and B has "&layers=BFT" in
>>> the url. At the beginning the views of A and B are equal(if we assume
>>> the default config is all layers visible) because ArgParser configures
>>> the layer only if there are the same number of layers in url and map:
>>>
>>> "if (this.layers.length == this.map.layers.length) {"
>>>
>>> If a user now adds a layer then she/he wonders why his first overlay
>>> layer is not visible. This can also happen when he forgets why she/he's
>>> on the site because removes the second adds a new one, removes the
>>> "second", adds a new one... all is as expected till he adds the third
>>> then the second is not visible. This happens because the addlayer
>>> listener of ArgParser is unregistered after the line above. That's why
>>> standard Permalink and ArgParser combination is only useful to change
>>> the initial configuration, this should be mentioned in the 
>>> documentation.
>>>
>>> 3. One thing, i would separate visibility and base/overlay-layer. When
>>> you have two baselayers in your map ArgParser doesn't parse the "0" for
>>> baselayers which are not visible(or not THE baselayer of the map) and
>>> the unvisible baselayer becomes an overlay. So something like
>>> "&layers=BTBFOTOF" would be better for two baselayers(first the
>>> baselayer) and two overlay layer (first visible, second not)... or just
>>> make ArgParser parse "0".
>>>
>>> configureLayers: function() {
>>>
>>>          if (this.layers.length == this.map.layers.length) {
>>>              this.map.events.unregister('addlayer', this, 
>>> this.configureLayers);
>>>              for(var i=0, len=this.layers.length; i<len; i++) {
>>>                  var layer = this.map.layers[i];
>>>                  var c = this.layers.charAt(i);
>>>                  if (c == "B") {
>>>                      this.map.setBaseLayer(layer);
>>>                  } else if (c == "0") {
>>>                      layer.isBaseLayer = true; //trigger change-event?
>>>                  } else if ( (c == "T") || (c == "F") ) {
>>>                      layer.setVisibility(c == "T");
>>>                  }
>>>              }
>>>          }
>>>      },
>>>
>>> Regards,
>>> Slawomir
>>>
>>>   Am 24.08.2010 15:38, schrieb Andreas Hocevar:
>>>> On Aug 24, 2010, at 15:15 , Marc Jansen wrote:
>>>>
>>>>> Hi Andreas,
>>>>>
>>>>> first of all, sorry for cross-posting in the past. I thought it was
>>>>> useful in this case.
>>>>>
>>>>> I'd disagree about the not handling of the layeradd/layerremove event
>>>>> for the Permalink-control -- but can easily live without this 
>>>>> addition
>>>>> to OpenLayers :-)
>>>>>
>>>>> Your suggestions of alternative ways of handling application 
>>>>> "state" are
>>>>> valid and often better suited, yet I think the addition of two
>>>>> additional listeners to the control would be very intuitive.
>>>> This is where I have to disagree. Let's say you have a map with two 
>>>> pre-configured layers. Now user A, who uses the Permalink control 
>>>> as is, adds a layer, resulting in a permalink with "&layers=BT".
>>>>
>>>> User B has the same map, adds a completely different layer, but 
>>>> uses your add/removelayer aware Permalink control, resulting in a 
>>>> permalink with "&layers=BTT".
>>>>
>>>> Now the interesting part comes when both users send this permalink 
>>>> to someone who opens the permalink. That person will see exactly 
>>>> the same layers with both permalinks - because the map will load 
>>>> only the two pre-configured layers.
>>>>
>>>> This is why I wouldn't consider adding add/removelayer handlers to 
>>>> the Permalink control useful or intuitive at all.
>>>>
>>>> Regards,
>>>> Andreas.
>>>>
>>>>> Best regards,
>>>>>
>>>>> Marc
>>>>>
>>>>>
>>>>>
>>>>> On 24.08.2010 14:49, Andreas Hocevar wrote:
>>>>>> Hi,
>>>>>>
>>>>>> first of all, please don't cross-post dev and users.
>>>>>>
>>>>>> I am not sure if a permalink as provided by OpenLayers is what 
>>>>>> you really want for applications where the user can add or remove 
>>>>>> layers. The permalink only stores the visible/invisible state of 
>>>>>> the available layers in their order. It does not know anything 
>>>>>> about what these layers are. So a permalink will look exactly the 
>>>>>> same for any map with the same extent with let's say 3 layers 
>>>>>> that are all visible.
>>>>>>
>>>>>> If you want to store information on what layers are actually 
>>>>>> configured, you should look into Format.WMC, Format.OWS or 
>>>>>> solutions like the OpenGeo Suite's GeoExplorer 
>>>>>> (http://suite.opengeo.org/geoexplorer), which stores layer 
>>>>>> configurations in a database and provides a permalink with a map id.
>>>>>>
>>>>>> Regards,
>>>>>> Andreas.
>>>>>>
>>>>>> On Aug 24, 2010, at 14:31 , Marc Jansen wrote:
>>>>>>
>>>>>>
>>>>>>> Hi Slawomir,
>>>>>>>
>>>>>>> I'd consider this a bug with a (on first sight) reasonable easy 
>>>>>>> fix:
>>>>>>>
>>>>>>> In the Permalinks draw-method:
>>>>>>>
>>>>>>>          this.map.events.on({
>>>>>>>              'moveend': this.updateLink,
>>>>>>>              'changelayer': this.updateLink,
>>>>>>>              'changebaselayer': this.updateLink,
>>>>>>>              'addlayer': this.updateLink,
>>>>>>>              'removelayer': this.updateLink,
>>>>>>>              scope: this
>>>>>>>          });
>>>>>>>
>>>>>>> Or one could think of triggering a changelayer event when a 
>>>>>>> layer has
>>>>>>> been added/removed in Map.js.
>>>>>>>
>>>>>>> I am unsure which design is better, so I'd suggest opening up a 
>>>>>>> ticket
>>>>>>> (I cc'ed the developer list so the core developers notice this 
>>>>>>> discussion).
>>>>>>>
>>>>>>> Regards,
>>>>>>> Marc
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 24.08.2010 13:53, Slawomir Messner wrote:
>>>>>>>
>>>>>>>>    Hello,
>>>>>>>> Does anyone know why Permalink doesn't listen to 
>>>>>>>> addlayer/removelayer?
>>>>>>>> Every time I add a new layer I have to change a property(i.e.
>>>>>>>> visibility) to refresh the link. It's a bug or a feature?
>>>>>>>> Regards,
>>>>>>>> Slawomir
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Dev mailing list
>>>>>>> d...@openlayers.org
>>>>>>> http://openlayers.org/mailman/listinfo/dev
>>>>>>>
>>>>> -- 
>>>>>
>>>>>    .................................................................
>>>>>     Karten im (Inter|Intra)net?
>>>>>
>>>>>     OpenLayers - Webentwicklung mit dynamischen Karten und Geodaten
>>>>>     von M. Jansen und T. Adams, OpenSourcePress, München.
>>>>>
>>>>>     ISBN: 978-3-937514-92-5
>>>>>     URL:  http://openlayers-buch.de
>>>>>    .................................................................
>>>>>
>>>>>
>>>>>    Dipl.-Geogr. Marc Jansen
>>>>>    - Anwendungsentwickler -
>>>>>
>>>>>    terrestris GmbH&    Co. KG
>>>>>    Irmintrudisstraße 17
>>>>>    53111 Bonn
>>>>>
>>>>>    Tel:    ++49 (0)228 / 96 28 99 -53
>>>>>    Fax:    ++49 (0)228 / 96 28 99 -57
>>>>>
>>>>>    Email:  jan...@terrestris.de
>>>>>    Web:    http://www.terrestris.de
>>>>>
>>>>>    Amtsgericht Bonn, HRA 6835
>>>>>    Komplementärin:  terrestris Verwaltungsgesellschaft mbH
>>>>>    vertreten durch: Hinrich Paulsen, Till Adams
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users@openlayers.org
>>>>> http://openlayers.org/mailman/listinfo/users
>>>
>>> -- 
>>> -----------------------------------------------
>>> Slawomir Messner
>>> Forschungszentrum "Deutscher Sprachatlas"
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users@openlayers.org
>>> http://openlayers.org/mailman/listinfo/users
>>
>>
>
>


-- 
-----------------------------------------------
Slawomir Messner
Forschungszentrum "Deutscher Sprachatlas"
06421-28-24981

_______________________________________________
Users mailing list
Users@openlayers.org
http://openlayers.org/mailman/listinfo/users

Reply via email to