Allow layers to be weighted in presets.

This is not a bug. This is a feature request, and I think, a valid one, though not high priority. Marking as such.

Here's an initial patch working on this. I think that this is a rather important feature.

I agree it is important. Should also be allowed to hooks to specify/change order. Will try the patch as soon as I have a chance.

tmwc: I applied your patch but can't see any effect in preset layers ui. I do have jQuery UI module enabled.

Am I supposed to see the classic move handle cross ?

Found the issue, you miss to add a 'draggable' class to the rows:

- $rows[] = $row;
+ $rows[] = array( 'data' => $row, 'class' => 'draggable' );

in theme.inc, for both base and overlay layers

btw, does it make sense to drag base layers ? since they are always shown at the bottom, and always only one....

The attached version of the patch (to apply against current HEAD) only touches the theme function
and properly groups the table elements togheter for better visual feedback to user.

In addition, it drops reordering capabilities for base layers.

ouch, of course only touching the theme won't save the actual ordering..

strk: yes, it makes sense to manage the order of base layers; at least in order to order them in the layerswitcher

After many hours of frustration I realized that the problem here is basically the fact that we are showing *all* candidate layers
in that form table while we'll only save the ones actually enabled.

Thus there will be some "weight" information which won't be put in the saved data.

One possibility I may think of is just order the 'layers' element of the preset based on the weight
and have the form elements initially follow that ordering (appropriately splitting base from overlay).
But you can see that doing so will forget any ordering you'd give to layers which you're not enabling.

This new patch is cleaner for the UI part.
It will work with and w/out jQuery ui, with or w/out javascript.

Still missing handling of the form, which needs some more thinking: do we save all weights or only the ones for layers we're actually using in the preset ?

Ok. this new version works. Still only sorts overlay layers, not base ones, but it's good to commit for me (base layers ordering can be added later).

Basically the form generator only needs to make sure the form elements are printed in the order they are in the preset data.
Saving in the preset data seems to be handled directly by browser, which is sending the parameters in the order they are rendered in the page (which is affected by JS). Will check this with IE too, but if it works reliably like that I'd keep it rather than adding a 'weight' array in the preset.

Annoyingly enough, the higher position shown in layer manager the lower z index :/

17:19 < crschmidt> Yes. If you dislike it, you can pass ascending:true

I guess we want to expose such configuration in the layer switcher behavior or something like that

Just started to test this, and it introduces a bunch of warnings, plus there definitely are ways to clean up the code. Hold off on committing.

Alright, with http://drupal.org/node/897560 you can now configure the layer switcher.

The default (crschmidt didn't recall correctly) is ascending:true which makes layers with higher
Z-index (closer to user) appear on the bottom.

This is kind of counter-intuitive for me.
Usually GIS clients show higher-level layers on top.

Should we take the intuitive path for layers ordering ? I'd think we should...

See if you like this one (reduces the code used to order things up when printing the form).
I can't see any warning here, let me know what do you get if anything.

Ok, last one. I'd commit this one.
With this one layers toward the top of the page are the ones that will be shown on top of others (toward user).
I like it very much.

This works fine on the preset form side, but there is no logic in here to actually sort the layers on the JS/OL side.

On the JS/OL side first layer added to map gets lower Z-index.
Last added covers previous ones.

I haven't looked at the JS code populatin gthe map but I guess
it does something like 'for (layer in preset.layers) map.addLayer(layer)'
that is, it depends on the order preset.layers get scanned.
Being an associative array rather than an ordered array makes things
a bit more confusing, but per ECMA order of assoc array elements are
also predictable, just a bit harder to deal with.

If you tried the patch and found a misbehavior please notice here
the steps to reproduce the bug. If you haven't please do.

So, since zzolo mentions his JS impelmentation doesn't retain order of object properties (and I've read somewhere online that javascript is really not guaranteed to keep such ordering) the attached patch adds a weight property in the PHP side of rendering (based on predictable order of PHP associative array elements) and uses that property on the JS side to sort the array.

Advantage of this patch is that it doesn't add any information in the preset.
Tests welcome.

Note that this patch must be applied _in addition_ to the previous.

I've handled to reproduce the problem reported by zzolo using google chrome.
Attached is a complete patch which should apply to the branch tested to work on firefox, google chrome and IE8.
Basically implements the sorting on the javascript side.

To make testing and contributing easier, I've put the code in a branch on github:
http://github.com/strk/dol-6--2/tree/sortable_layers

Note that the master branch there is in sync with CVS

Committed what I had in the branch.
http://drupal.org/cvs?commit=421396

Hi @mitchellj. Yes, that should be the case.