Add zoom_to_layer option in CCK

As discussed in this issue: #726876: No map while creating node

Currently there is no way to do this in the 2.x branch without a map_alter, or by creating a view (which seems unnecessary in my opinion).

Due to multiple people asking about this feature and it being in 1.x and it being relatively easy to implement, I am putting this a feature request.

Shouldn't this include the possibility of adding any layer-specific behavior to a CCK layer? Although CCK layers are an obvious kink in the workflow.

Sure! Couldn't hurt. Are you thinking about trying to denote behaviors as layer-specific, therefore we could abstract the widget options to be whatever behaviors are layer-specific?

We'll update this ticket?

So one would think the way to implement this is to assign a drupalID to CCK-generated layers, and then tack that 'possible layer' on to the 'assign to layer' dialogs for zoomToLayer, etc. I'll get cracking on a patch soon.

I am a little confused by your comment. Just to clarify what I was thinking and what gets done in 1.x as far as the interface: There is a checkbox option on the CCK widget for "Zoom to Layer" and also a "Zoom Level" for single features. If checked, then when the map is displayed on the output side (formatter) then it will be zoomed to the CCK generated layer.

(Please note that this would actually be a better option for a formatter, but there are not options for those)

Yeah, that doesn't really fit into the 2.x structure. zoom_to_layer is a behavior that belongs to a preset. I don't really think it's a great idea to do modification of a preset at the CCK level / grow the CCK module any more than it should grow / or duplicate this functionality in the CCK module.

But this is a feature of the field (specifically the formatter) and should be implemented like that. There is no need for it to be a part of a preset as a preset can be used in multiple places. Also, we cannot maintain that relationship between that field layer and the preset if someone exports it. The values will be exported with the field.

I think this is a very valid feature request and has been asked about multiple times (in the 1.x version).

I do like your idea of adding a property of behaviors to denote something as layer specific. That way, we can just grab the option forms for those behaviors and add good functionality easily to the CCK field. Either way, we can utilize the options forms from specific behaviors and not duplicate code, but instead utilize the robust system that we have created.

But this is a feature of the field (specifically the formatter) and should be implemented like that. There is no need for it to be a part of a preset as a preset can be used in multiple places. Also, we cannot maintain that relationship between that field layer and the preset if someone exports it. The values will be exported with the field.

Yes; this introduces a dependency between exported presets and CCK fields that is undesirable, and it also introduces a small bit of CCK-specific code in OpenLayers core, I won't deny that. I also don't think that there's a better solution. Putting OpenLayers configuration into the CCK widget is just a rehash of how configuration was spread out in the old OpenLayers views implementation - it becomes a nightmare to maintain. That approach also basically requires you to reimplement a bunch of UI in OpenLayers CCK.

I don't see a big problem with needing to clone map presets a bunch of times - sites can have twenty views and fifteen openlayers presets and be maintained decently well. I think that splitting up map configuration into a bunch of places, as was done in the old implementation of OpenLayers Views, is a much greater evil.

Basically my idea is that CCK is a hack and OpenLayers CCK is a hack and this approach is a hack, but it's the best thing that can be implemented without 1) growing the OpenLayers CCK module 2) Splitting up the configuration of map presets. I think that this solution is doable and decently well architected. The alterative seems like a larger hack and a larger chunk of work, which means that it would be even longer until it's implemented.

I agree that OpenLayers CCK is a not a good solution. This module should not be handling the storage of geographical data. But we either we support it or don't, and it's a decent solution given the options in Drupal at the moment. I would actually be ok with taking out CCK at this point. I think it might actually push innovation to other solutions.

Nonetheless, if we are going to support this feature we should not hinder it. It makes much more sense, IMO, architecturally and interface-wise to keep this configuration in the field as they're specific to the field, not the preset. We currently create the CCK vector layer on the fly and that is not managed in the presets. It does not make sense to have the behaviors that are specific to that layer be managed in a different place as well. And I don't think the CCK layer should be managed in the preset space either.

I think your solution is more "hackish" because it will create a hard linkage in the actual core architecture as opposed to having the CCK module utilizing the core architecture and allowing the two to be separated.

Nonetheless, if we are going to support this feature we should not hinder it. It makes much more sense, IMO, architecturally and interface-wise to keep this configuration in the field as they're specific to the field, not the preset. We currently create the CCK vector layer on the fly and that is not managed in the presets. It does not make sense to have the behaviors that are specific to that layer be managed in a different place as well. And I don't think the CCK layer should be managed in the preset space either.

This is misunderstanding the proposed fix: the CCK layer would not be managed in the preset space. It would have a standard drupalID, to which behaviors could point. The OpenLayers CCK layer could not appear in the layer management of presets without a fair bit of bad hacking.

I think that the architectural advantage of 'keeping behaviors specific to CCK fields within the fields themselves' is skin-deep. When it comes down to it, behaviors are assigned to layers but belong to presets.

I don't think that the introduced dependency is much of a killer - if OpenLayers CCK is disabled, nothing terrible happens. There's just a layer option in the preset editor which is invalid. And this would be killed with an if module enabled, although that does suck. The two can easily be separated with the proposed fix.

I used to be against CCK, but a lot of people use it.

On second thought go for it; this is a hack either way. I think that your solution is a worse hack, but it's completely confined to the OpenLayers CCK module, which is nice.

Created a patch. It works pretty smoothly. It could actually be a lot less code if I reused the openlayers_ui_get_behavior_options() but I didn't want to get into dependencies. Since the CCK field does provide a drupalID for the layer, it was easy to make that the only option. It's also set up to make it really easy to switch to a system that looks for a layer-specific property on behaviors.

Here's a version of that patch that cleans up the code a bit and tries to make some improvement to the CCK landscape.

A quick site review of patch looks good. If you are confident it works, I would say go ahead and commit it.

One thing on the 80 character limit. Not really my thing, but I am fine with it and you are putting the effort into it. But specifically for string breaks, like this one:

        '#description' => t('Choose the features that are allowed to 
          be inputed on the map.'),

It would be good to use a string operator here since, I believe, the translation interface will read all that space and the line break. Like so:

        '#description' => t('Choose the features that are allowed to ' .
          'be inputted on the map.'),

Though I am not sure how Coder will react to this.

Fixed that bit (moved to string concatenation), and committed: http://drupal.org/cvs?commit=363638

The last patch works fine but i want have multi zoom for each field, so i added a cck layers for preset in this little patch

@ndm, this is the whole point of the previous commit. We can't put the CCK layer into the preset interface (or specifically the behavior definition) because we don't know if it will be there, so we offer layer specific behaviors in the field interface.

I am confused on what you are trying to do here?

So, in hope, i will be understable. (i prefer write and speak in french).

I want add cck with the map many times in a panel, each map with a different zoom, and the cck point as center. The solution, i used, is to have 3 presets with 3 zooms, this presets are specially dedicate for this contexts.

The result, a single cck, 3 times in a panel, each with one preset defining a different zoom.

If i use the previous patch i cannot have many zooms. This is just one zoom by cck field, and i cannot define a dynamic choice for the zoom, or i don't find how to make that.

With a cck layer in preset this is possible. I find this is a good solution, but maybe, this would be better if a help text informing users that the cck layer is inactive in another context than in node view and preview.

For the point

We can't put the CCK layer into the preset interface (or specifically the behavior definition) because we don't know if it will be there

For the moment, i cannot be more specific on openlayers and make a better patch (with by exemple an addition of the cck layers on the screen in the same place that the data views layers), and i have made a simple proposition in hope that this can be usefull for others persons. (For my site this is a good solution, which functions).

I think I understand what you are trying to accomplish.

I think the best solution would be to implement a Views Data layer that gets your node (by utilizing arguments), then you can create your presets with your different zoom levels that utilize that data layer.

Overall, its more flexible to use Views to display maps. The CCK display has its benefits, but not as flexible.

Hope that makes sense.

I understand your point, it's a good idea. For the moment i guard the solution explain behind, because if i want use a preset with another cck field, i can.

Thanks for your comment, which learned me another way.