Hi Rick … went more through this great module taking advantage of the recently added functions to trigger events on features and maps from outside of the Leaflet context (i.e. http://drupal.org/commitlog/commit/25100/58fccdbfd6d0e16e2f97092a88d8f36…).
Wasn't that easy at all (due to missing examples of this new leaflet (& leaflet markerclusterer) funcs, but finally I implemented this very successfully on this page (work in progress …):
http://www.italomairo.com/geoblogcms/en/ip-locations-leaflet
Just try to mouseover and mouseout the "zoom in map" highlighted in the left list … to see how this (successfully) works.
Some changes (code upgrade) should be made to the Leaflet and Leaflet Markerclusterer Modules, and already opened issues on this (http://drupal.org/node/2005328 & http://drupal.org/node/2005334) to better expose map and features properties to the outside of the Leaflet js context,
but the first thing we need is to pass specific features' feature_id from the view to the leaflet features themselves, both for nodes' or taxonomy terms view.
This is essential to set up the relational logic between the map features and the page DOM/Views elements we want to build the interaction of.
I came up with a good solution for your module (for the leaflet map) little upgrading the following files of the ip_geoloc in the following way:
views/ip_geoloc_plugin_style.inc:
--- a/sites/all/modules/ip_geoloc/views/ip_geoloc_plugin_style.inc
+++ b/sites/all/modules/ip_geoloc/views/ip_geoloc_plugin_style.inc
@@ -465,6 +465,13 @@ function ip_geoloc_plugin_style_extract_locations($views_plugin_style) {
$tag = $tag_field->theme($row);
$location->marker_tag = _ip_geoloc_plugin_style_add_label_and_styling($tag_field, $tag);
}
+
+ // We define a variable/property for the $location that is the $node->nid (noded view) or the $term->tid (taxonomy terms views)
+ $feature_id = '';
+ if(isset($row -> nid)) $feature_id = $row -> nid;
+ if(isset($row -> tid)) $feature_id = $row -> tid;
+ $location->feature_id = $feature_id;
+
$locations[] = $location;
}
elseif ($error_count++ == 0) {
views/ip_geoloc_plugin_style_leaflet.inc:
--- a/sites/all/modules/ip_geoloc/views/ip_geoloc_plugin_style_leaflet.inc
+++ b/sites/all/modules/ip_geoloc/views/ip_geoloc_plugin_style_leaflet.inc
@@ -332,13 +358,17 @@ class ip_geoloc_plugin_style_leaflet extends views_plugin_style {
$feature['icon'] = array(
'iconUrl' => $icon_path . "/$color.png",
'iconSize' => array('x' => $marker_width, 'y' => $marker_height), // width, height
'iconAnchor' => array('x' => (int)(($marker_width + 1) / 2), 'y' => $marker_height), // center baseline
'popupAnchor' => array('x' => 0, 'y' => -$marker_height - 1), // just above topline, center
//'shadowUrl'
//'shodowSize'
//'shadowAnchor
);
}
+
+ /* Define the feature_id of the feature as the $location->feature_id (valid/useful both for node and taxonomy terms ids) */
+ $feature['feature_id'] = $location->feature_id;
+
$features[] = $feature;
}
// If auto-box is chosen ($center_option==0), zoom only when there are 0 or 1 markers #1863374: Let "Initial zoom level" control work with Auto-box
That's it … to set up a proper way for good /and relatively easy) interaction … (attached the diff files)
Here is to know more about the js/jQuery logic and code snippets I used (and might be reused): http://drupal.org/node/1998596
I think else the Leaflet Module should implement an easer way to pass views nids/tids to the leaflet features map …
but for the ip_geoloc module all these might be an easy and very useful step forward, since now.
Hoping to see reviewed and implemented soon in the next dev release.
Cheers and thanks so much
Italo
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | select_Leaflet_interaction.jpg | 323 KB | itamair |
| ip_geoloc_plugin_style_leaflet.inc_.diff | 1.04 KB | itamair | |
| ip_geoloc_plugin_style.inc_.diff | 784 bytes | itamair |
Comments
Comment #0.0
itamair commentedsyntax
Comment #1
rdeboerHi Italo,
Great work figuring this all out!
I have no problem with the patch as far as IPGV&M goes.
Just wondering, is it not possible that a Views row has both the tid and the nid set at the same time? In that case your code would return the tid in favour of the nid. Is that desired behaviour?
What is the use case for the taxonomy term tid? If you hover over a taxonomy term in the text outside the map, will the map than somehow highlight ALL nodes/locations that share that tid?
Cheers,
Rik
Comment #2
itamair commentedhi Rick … very proper highlights from you.
that code is not perfect probably and for sure not exhaustive, and I already thought that, but worked well for my view made on (just) node entities.
The $row->nid is a property of the view results and seems to be get just in the case it is a nodes view, or terms view, or users view … or whatever entity.
I am not getting any exposed field nid or tid, but just the id of the row result, so I guessed it is quite difficult to have a view of different entity types … and so both a $row->nid and a row->tid … isn't it? might I have a ip leaflet map of nodes and terms, and users, and whatever at the same time?
I guessed not …
The use case for the taxonomy term tid might simply happen if I make a map of taxonomy terms (that might have geo field attached to).
It is not to for the use case of nodes with a specific taxonomy term: this would be much more difficult to obtain (and never seen such), also because would/should cover a many to many relationship between nodes and map features, and interactions (zooms, popup opening … impossible …).
So far I just set up the main logic I needed: we need to pass to leaflet js some unique id (feature.feature_id) of the view feature that corresponds to the drupal entity id … besides the feature.leaflet_id that leaflet manages to index the mapping features by itself (and that is better not to touch/override, I realized).
So, probably some further consideration must be done, to go ahead … and write some more/robust defensive code, probably aligning and sharing the best logic and use cases with leaflet (& leaflet markeclusterer ?) module maintainers.
Comment #3
rdeboerHi Italo,
I checked in a change similar to what you asked for, but using $feature['leaflet_id'] rather than $feature['feature_id'], because it looks what you've implemented already exists.
See file leaflet.drupal.js inside the Leaflet module.
Or am I mistaken?
Rik
Comment #4
itamair commentedyes Rick … I looked at it, and realized that …
it passes the feature.leaflet_id (auto generated by leaflet js) to the leaflet marker (lFeature), but seems it is really better to leave the (auto)generation of the feature.leaflet_id handled by Leaflet itself, without forcing the override of it above.
Indeed, I already noticed/tested that if the view plugin passes to the leaflet js the $node->nid, or $term->tid (that anyway we need to add and implement), such as
$feature['leaflet_id'] = $location->feature_id; (instead of $feature['feature_id'] = $location->feature_id …)
this ends throwing errors in the console.log of the browser on the js interaction events (mainly in the markeclustered map).
I already highlighted this in the issues forwarded to the Leaflet and Leaflet Markeclusterer modules with this note:
Note: I tried to assign the $node->nid to the feature.leaflet_id property included in the leaflet api (and that the leaflet drupal module associate with the lFeature._leaflet_id) but this caused weird behavior (and continuous errors throwing in the browser console.log : TypeError: 'undefined' is not an object (evaluating 'this._map._panes'), especially with the marker clustering and the map.setView() method. Probably the lFeature._leaflet_id is something that should be left to the Leaflet apis management, without overriding it
It seems that it is better not to override the Leaflet Api future.leaflet_id property, as seems to be an identifying id it likes to manage by itself for generated features indexing … in the management of the map state (and lFeatures regeneration, like in markeclustering zooming in and out).
Thus I preferred to add our new property (feature.feature_id) that would match the id from drupal original entity (node/term/entity).
In this way everything works without any error in the browser, with or without the markeclustering …
Am I understandable? I hope so ...
Comment #5
itamair commentedthat said, as feature.feature_id might be quite confusing as property name (with feature.leaflet_id existing), I am minding better to change that code in this:
views/ip_geoloc_plugin_style.inc:
views/ip_geoloc_plugin_style_leaflet.inc:
so that the feature.drupal_entitiy_id would be available to the Leaflet js, and then passed/forwarded to the interacting external modules (events bindings) by the Leaflet Module with the already existing following code …
Isn't it?
Comment #6
rdeboerYEP I get you.
Will change accordingly.
Rik
Comment #7
rdeboerOk...
So in the latest IPGV&M code I've gone for
$location->id(with id referring to either nid or tid) and$feature['feature_id']to be passed to the Leaflet JS. In the context of Leaflet, feature_id, which is what you had first, is a good name I think.Rik
Comment #8
itamair commentedGreat! Thanks Rick …
I adviced the Leaflet module to follow this issue (https://drupal.org/node/2005328#comment-7481698), so that they might align to our achievements ...
Comment #9
itamair commentedJust to mention, with this new feature I went even further, experimenting the use of a Select and its "change" event triggered … (screenshot attached).
Here it's a matter of personalizing the views unformatted list style (to make it becoming a select), but it works (and works really great), as you can experiment in the same updated page: http://www.italomairo.com/geoblogcms/en/ip-locations-leaflet
;-)
Comment #10.0
(not verified) commentedsyntax
Comment #11
rdeboerIPGV&M now has this as a fully-fledged option: https://www.drupal.org/node/2427455#comment-9793009