The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Taken from here: #711550: Some layers can't be added and shouldn't be added
The problem is that Views Data Layers show up in the layers list (admin/build/openlayers/layers) which means there is an Edit and Clone operations for them. The Views Data Layers should not show up in this list.
We could use a "ui_visibility" property like with behaviors. This could be on a layer or layer_type level. But technically we do want it in the preset UI.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | openlayers_views_handling.patch | 3.89 KB | tmcw |
Comments
Comment #1
tmcw commentedMarking as 2.x. I think that views layers should show up in the list, but shouldn't have the operations available to modify them via that interface. And actually I'm starting to think that it should be possible to edit openlayers views layers through that interface - which could be useful in special cases like restricting the zoom levels in which they appear.
Comment #2
zzolo commentedMakes sense. Either way, we need some special logic for views data layers.
Though, for something like the zoom level, I would think that putting that in the Views interface as an option might be good, more from a UI standpoint. Having to go back to the Layers interface to edit the zoom level seems like a lot. Just a thought.
Comment #3
tmcw commentedPatch attached that prevents users from exporting and cloning OpenLayers data layers. I think that this is the way to go (instead of redirecting) because it keeps the user experience consistent (doesn't jump interfaces) and also educates users in how OpenLayers Views work. Can you give this a quick look? I've tested it and think it's ready to commit.
Comment #4
zzolo commentedThanks @tmcw. A quick site review: seems like all the logic is good. Some minimal things that can be addressed later are there are a couple coding standard mishaps, and there is probably a better way to make that code shorter. But I would give the go ahead if you are confident with it.
Comment #5
tmcw commentedCommitted: http://drupal.org/cvs?commit=367040
As far as code style, some of this is a bit ugly, but passes coder with no warnings, and one must balance the evils of creating lots of 'alias variables' and looking at long variable addressing like $form['#parameters'][2]->data['layer_type']
Comment #6
zzolo commentedSure. No big deal. Please note, though, that Coder does not actually get 100% coding standards.