I needed to attach more behaviors to the map created by mapstraction, and the most direct way to do it was to override the theme function. Instead, I switched mapstraction to use a template, which gave me access to preprocess functions.

The ways of Views plugin theming was a little odd to me. I thought I'd have to change more than I did, but I just renamed the functions and created a template file, and adjusted the variables in the template preprocess function. There are no changes to the mapstraction_theme or mapstraction_views_plugins. (mapstraction_theme looks strange anyway, because the arguments don't match up with the actual function's arguments.)

With this support, I can create preprocess functions that add to Drupal.settings and load more scripts to control the map.

I also added the rows to Mapstraction's array in Drupal.settings, which I suspect won't be great for everyone.

CommentFileSizeAuthor
#3 mapstraction-preprocess-support.patch3.69 KBAnonymous (not verified)
mapstraction-preprocess-support.patch3.43 KBAnonymous (not verified)

Comments

dixon_’s picture

Status: Needs review » Needs work

Yeah, separating the theme function into a preprocess function and a template file is a good thing!

But the patch doesn't apply after the last commit I made. And I rather see that we move the actual markup to the template, instead of putting it in $vars['output'].

Anonymous’s picture

It could go either way, couldn't it? While it is markup, I can't imagine needing to override it after it has been rendered. I can only think of adding to it, and that can be supported with template suggestions.

Can you advise on an implementation that doesn't break because somebody foolishly changes the div's ID or removes the scripts?

What about breaking the output into two pieces? Instead of just $output, we break it into $api (the tiny scripts from mapstraction.api.inc) and $output (the element where the map is inserted)?

Anonymous’s picture

StatusFileSize
new3.69 KB

Here's what I've done. It works with your latest commit.

Anonymous’s picture

Status: Needs work » Needs review
dixon_’s picture

Looks nice! But I have some more thoughts on this...

I could definitely see situations where one would like to modify the markup. I've recently started a discussion on the Mapstraction mailing list about a bug in setInfoDiv(). In a scenario where that function is implemented here, you might want to add a div inside the mapstraction map div to show additional information in. So the best thing would be to have as much of the markup as possible in the template file (as your patch does now).

And regarding the provider API scripts -- I'd like to see some kind of rewrite here... As of now, the scripts are included just before the map div, in the middle of the page. This creates a sudden break while loading the page request. An ideal solution to this would be to print the provider API scripts at the bottom of the page, so the page can render without any sudden breaks.

A possible solution would be something like this:

Break out the markup into a template file and keep all the logics in a preprocess function (as you already did). Then, in the preprocess, load all necessary API scripts into a function with a static variable (mapstraction_set_provider() or something similar) instead of a template variable. This function should keep track of which providers that are set. Then, in hook_footer(), print all scripts that was statically cached in mapstraction_set_provider() at the bottom of the page. That way, we don't need to add the scripts in the template file and the page seems to render faster.

What do you think about this?

Anonymous’s picture

I'll take your word on the setInfoDiv() problem. I'm just a beginner with Mapstraction.

hook_footer sounds nice. I think this is an important goal. I wonder how this all is affected with new Views plugins caching, though? If the scripts are being stashed in a static variable and then output separate from the view itself, how will the scripts be called up if the mapstraction view is cached?

Does that issue prevent this patch from being evaluated as is?

levelos’s picture

Status: Needs review » Fixed

Implemented in the new 2.x branch.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

-Mania-’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev
Status: Closed (fixed) » Needs work

I can't get this to work. I copied the mapstraction-map.tpl.php file to my themes folder but none of my changes come up. If I make changes directly in the module's directory then it's working as expected. And yes, I've cleared cache etc.

levelos’s picture

I can confirm the bug, but have no clue as to the cause? Anyone else? I'll try again tomorrow with a fresh set of eyes.

levelos’s picture

Status: Needs work » Fixed

Alright, figured it out and it's now resolved. For anyone else, here's the deal. The array key within the theme definition won't accept a hyphen, it wants an underscore. E.g., In the following two snippets, the first version works correctly, but the second doesn't.

function mapstraction_theme($existing, $type, $theme, $path) {
  return array(
    'mapstraction_map' => array(
      'arguments' => array('api_script' => NULL, 'map_id' => NULL, 'width' => NULL, 'height' => NULL),
      'template' => 'mapstraction-map',
    ),
  );  
}

function mapstraction_theme($existing, $type, $theme, $path) {
  return array(
    'mapstraction-map' => array(
      'arguments' => array('api_script' => NULL, 'map_id' => NULL, 'width' => NULL, 'height' => NULL),
      'template' => 'mapstraction-map',
    ),
  );  
}

However, they both work when the function theme('mapstraction-map') is called from the same module.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.