Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Related to #1950274: Spin off Openlayers integration into separate module, here's the initial stab at porting geofield code to the Openlayers module. It establishes the base code needed to define the widget, but I'm having an issue displaying maps that seems to be a proj4js issue, but I'm not entirely sure. Dumping patch here for now.
Comment | File | Size | Author |
---|---|---|---|
#6 | openlayers-geofield-handoff-1957630-6.patch | 11.99 KB | Brandonian |
#3 | openlayers-geofield-handoff-1957630-3.patch | 11.6 KB | Brandonian |
ol_geofield.patch | 26.77 KB | Brandonian | |
Comments
Comment #1
PolCool ! Good things begins :-)
Here's my first thoughs:
Another question is: Do you think we should create a new branch from 7.x-3.x ?
Thanks Brandonian !
Comment #2
Brandonian CreditAttribution: Brandonian commented1. I sort of rage-quit last night while building the patch, so apologies on the poor quality. I plan on rebuilding today.
2. No problem. I went with ol_geofield to save on keystrokes, but I can definitely make that change.
3. 2.x branch. I plan on adding a patch to #1950274: Spin off Openlayers integration into separate module that strips out all the Openlayers code from geofield.
4. I think we should hold off on doing another set of branches, and work with patches instead. I don't think this will be a super-involved patch, once we get code in place. However, if you're more comfortable working with branches, that's fine too. Locally, I'm on a separate branch, so it wouldn't affect my workflow much.
Comment #3
Brandonian CreditAttribution: Brandonian commentedUpdated patch. I've updated the module name and defined the OL behavior correctly (via the 2 ctools hooks and hook_openlayers_behavior()). JS is loading correctly, but I haven't yet fully refactored to take advantage of all the API additions that have gone into the module yet. Ideally, I'd like to see the behavior work on arbitrary maps, not just ones being displayed on the Geofield widget, but that can be addressed separately if needed. @Pol, any help on the JS side would be appreciated.
I'm going to move on to widget code next. Geofield's widget code has some fairly complicated bits dealing with the handling of complex geometries on the server side (i.e., should we save a GEOMETRYCOLLECTION as separate fields, or just one?). I'm wondering if there's a way to refactor in which Geofield keeps that code for use of other widgets (i.e., a hypothetical Leaflet input widget, or Geofield's own raw WKT input) and keep the rest in Openlayers. *thinking out loud*
Comment #4
PolHello Brandonian,
I'm trying to apply your patch, but I still got this error:
Do you know how to solve that ?
Thanks !
Comment #5
PolHere's my comment:
The definition of the behavior should be:
Then, in the behavior, the render() method:
There's no need to use drupal_add_[js|css], because we are using libraries.
Each behavior is a library and it's files are automatically loaded.
See hook_libraries_info() from OpenLayers.
I will try to test it in depth this week end as I'm having a lot of personnal work which involve OpenLayers and I'm quite busy getting other modules working with the new beta :-)
Comment #6
Brandonian CreditAttribution: Brandonian commentedTry this patch. I haven't run into an instance before where I needed to actually do a diff with a --full-index flag, but it seems to be hanging up on that with the .pngs. Applies locally to 7.x-3.x, but YMMV. No other changes ATM.
Comment #7
Brandonian CreditAttribution: Brandonian commentedHad trouble uploading a patch, and given the issues we've had with applying my patches, I decided to open up a sandbox instead. http://drupal.org/sandbox/brandonian/1964078
At this point, I have a very rough Geofield widget working. I've reworked the javascript to conform to the core behaviors setup, and made the suggested changes by @Pol, and basically have a proof of concept widget without any settings.
At this point, we need to drop in the ability to add the same widget settings that Geofield currently provides (point, path, or polygon selections in widget, how to store data).
I've also thought some more on my comment from #3 about Geofield holding onto the code that determines whether or not to save simple geometries per field or a single complex geometry, and I think the easiest way to make that happen would be to make them field settings instead of widget settings. It kind of makes sense to me that they belong there anyway, since it deals with data storage vs. input, but haven't had a chance to bounce the idea off of anybody. Reworking that would probably warrant dropping the settings into an advanced tab/fieldset to help lower confusion.
If anybody would like access to commit to the sandbox directly, please let me know. :-)
Comment #8
PolHello Brandon,
I tried your sandbox.
Right now, the geofield 'OpenLayers Map' formatter only display the default map, without adding the geofield behavior.
I tried to play with some element functions:
But I got nothing working. All I would like to do is to alter the default 'openlayers' element to add a textarea just under it.
I'll keep on digging, if you have some tips, don't hesitate...
Comment #9
m.stentaThis is a pretty old issue... but I think it is done now? Openlayers 3 comes with openlayers_geofield, which provides a widget and formatter. It also disables the widget and formatter provided by the Geofield module.
Marking as fixed... reopen if I'm wrong.