I have a module I want to submit. A simple static map block module that can work in conjunction with gmap module or independently. But providing a really basic interface for none node based maps.
| Comment | File | Size | Author |
|---|---|---|---|
| #25 | simplemap-1.0-update6.tgz | 13.95 KB | mistergroove |
| #24 | simplemap-1.0-update5.tgz | 13.63 KB | mistergroove |
| #22 | simplemap-1.0-update4.tgz | 13.64 KB | mistergroove |
| #21 | simplemap-1.0-update3.tgz | 13.19 KB | mistergroove |
| #16 | simplemap-1.0-update2.tgz | 13.15 KB | mistergroove |
Comments
Comment #1
mistergroove commentedThis is a basic module which allows the addition of simple static map blocks (via the block administration menu) without the overhead of setting up gmap module although it is designed to work in conjuction with gmap if it finds it installed. I find more sites I create require only a very simple map with one marker. It also allows themers to set images all or individual markers within the theme folder.
Comment #2
avpadernoPlease change only the status, when you upload new code.
The Apply for contributions CVS access reports that
Comment #3
avpadernoComment #4
avpadernoComment #5
mistergroove commentedHi KiamLaLuno.
I'm not really sure how the submission process works from here on. But here goes my reasoning behind this module...
I built this module to solve a different problem than gmap is designed to handle - the rapid creation of one off static map blocks.
Most of my clients just need a one off map block which usually shows just one location.
Gmaps is great for node based location maps - I wouldn't want to change gmap module to do the same it is good at what it does - this is in no means a replacement of functionality and this is why I made a concious desicion to make simplemap work in conjuction with the Gmap module - if it is installed - so you don't have duplication of google map api keys.
Having used both modules theres are definate merits to both. People building simple company information sites would probably find simplemap more practical for a one or two location map.
To create a one point map in gmap I would have to :
1. install gmap views and gmaps, and cck,
2. setup gmap,
3. create my view,
4. add a node type
5. add a location field
6. create one node
7. set up a block view and show my one node.
8. configure my block.
(8. configure my markers . optional)
To do the same in simplemaps :
1. Install simplemap.
2. setup key (if gmaps not installed)
3. Configure my map block.
(4. theme my markers - within the theme file)
There is a small degree of overlap and if there are ways to integrate the two more I'd be happy to do it. And there are definately different approaches to many of the problems in drupal mapping that can later be distilled into one. Also some of the jquery interface stuff which automatically updates the map from the address and vice versa and allows the map to interact with other page elements could also ultimately combined into gmaps.
By submitting this module the ultimate goal would be to help both modules - share where appropriate - and evolve the whole process.
Thoughts?
Jools
Comment #6
avpadernoIf the module only creates blocks, then the modules have two different purposes.
Comment #7
avpadernoIf the code would use
system_settings_form(), there would not be the need to use a submission function; the form would automatically save the values in Drupal variables.The code could use
module_load_include().The message would be shown all times the module is enabled. It would be better to add the information in the help text of the module.
All the constants name should start with the name of the module written all in upper case letters.
It would be better to merge the code of the two functions, rather than unconditionally include a file just to use a function.
The code would be simpler, if the functions would all be in the same file. For what I can see, only
simplemap_block_view()is defined in the module file.See the Drupal coding standards to understand how a module code should be written.
If the module help.module would not be enabled, the implementation of
hook_help()would not be invoked, and so would do_simplemap_help(). Thefore, there is no need to verify if that module is enabled.It's not clear to me why to put the code in a private function that is only called by the implementation of
hook_help().Comment #8
mistergroove commentedThanks KiamLaLuno,
Some really good points, thanks. I've been through your points and modified the code as suggested for your points (1,2,4,5 and 7).
For the remaining :
3. I think it's helpful to get instructions when a modules is installed. I've seen this in a few existing modules and I kind of liked it. But if this is not standard I'm happy to remove it.
6. This approach means that drupal doesn't include a lot of unnecessary code that is only used rare events - such as configuring. This is about keeping the drupal lean and fast. Drupal is moving further and further away from a having the code in a central body. There are some cases of using this technique in the drupal examples.
8. Good point. I borrowed some of the help stuff from another module as most of the modules I've written I don't add too much help to as I haven't released them. I've kept the code in a private function for the same reasons in the point 6. As there's no point including a massive block of help text on every single drupal execution.
I have attached my changes.
Cheers,
Jools
Comment #9
avpadernoIf you need to give instructions when a module is installed, then the message can be given in the installation function. The implementation of
hook_enable()is not thought to be executed when a module is installed, but when the module is enabled.I agree with that. Still, I don't see why to leave a single function on the module file, and the other ones in the file that is included; it would rather be better to move also
simplemap_block_view()in the other file.Comment #10
avpadernoComment #11
avpadernoThe code could use
drupal_set_html_head().The file simplemap.pages.inc is used for just a function. In that case, the code can be moved in the module file.
An external file is created for more that one function; differently, there would not be any vantage on using it (the overload to load the file would kill the vantage obtained to move the code outside the module file).
Comment #12
mistergroove commentedYeah I've attempted that before. This was after a bit of investigation. There's few long threads about this topic - excluding external javascript files. It's a while back but I think it's probably to do with when drupal has sent the headers or the position of the javascript include. I'm pretty sure this is the neatest way to do this until drupal gets an external include function.
I'm not sure about adding long blocks of text into a module as just means they will be parsed and processed on every single page you visit. Drupal includes the whole module file regardless of whether it's used. So all that text is processed every page you go on. This is about keeping the code lean and mean. Only including the minimum until something is used. Help text is only used on a few pages.
Comment #13
avpadernoWhen I have doubts about how to implement something, I look at what Drupal core code does.
Drupal doesn't use a file for just a function; I guess there would be a reason.
Comment #14
mistergroove commented:) Well maybe I'm not explaining my reasoning well. If you remember back to earlier versions of drupal then everything was included in one module file. As drupal has evolved it now there seems to be a lot more emphasis, quite rightly, on putting admin functions (hook_menu especially) into external files - and templates are now split into separate files. We build quite a lot of large sites which use quite a few modules - and you end up having to give php quite a high memory limit as drupal is using it to load lots of code which annoyingly is not even used (otherwise you end up with memory exceeded errors). My general philosophy here is only include the mininum unless used - save the processing for where it's needed. In my experience more and more of the popular modules are putting 'low use' code into included files.
How about I move the help functions into the simplemap.admin.inc file? Then we don't end up with a file with just one function in. I'd be happy to do that.
Comment #15
avpadernoI understood what you meant, and I agree with that. My point is that you should not create a file for just a function; it is perfectly fine if you move the function into simplemap.admin.inc, which is used also for other functions.
I would also move there
simplemap_block_view(); that would simplify the code that would not need to first verify if the function exists, then load the file and check again if the function exists.Really, the code could be simplified as:
Comment #16
mistergroove commentedCool. I moved the help functionality - think thats a little neater - thanks :)
Simplifying the hook_block that way would defeat some of the purpose the way I had it - it would still include all the administration and block configuration code (and now help text) on every map view page. I don't care if it php has to do a bit of extra work checking for a function on the configuration pages as it's a rare event - but loading it all on any view operation is costly. There are many of the very popular modules that do it this way for precisely this reason - and in some examples. I have changed the hook_block function code to remove the additional function check - I still have the other which I know this is not essential but it makes the code a little more watertight should a function not be declared.
Comment #17
avpadernoRemember to change status, when you upload new code.
Comment #18
mistergroove commentedOK. Is that correct to changed it to fixed? Sorry I'm a bit unsure of the next steps.
Comment #19
avpadernoComment #20
avpadernoThe IF-statements are not formatted as they would.
Constants must be written all in upper case characters.
The first argument of
t()must be a literal string, not a variable; differently the script to extract the strings to translate will not extract the string to translate.There should be a space before, and after the concatenation string.
The same is true for this code line.
Comment #21
mistergroove commentedThanks KiamLaLuno, All changed as suggested. I'm not using constants in point 2 (simplemap_get_location) so I couldn't understand that one. As for point 3 I need to be able to pass the user edited title into the translate interface so that people can add translations of the titles they add in. Cheers
Comment #22
mistergroove commentedFixed a couple more coding standards issues - and added a bit more functionality.
Comment #23
avpadernoChange the status to , when you upload new code.
As I reported, that doesn't happen, if the argument of
t()is not a literal string (in other words, it must be a constant value). Using a call liket($variable)has the same effect of using$variable.The error reported by the script that extract the strings to translate is the following: .
FALSEis a constant, and it should be written all in upper case characters; you wrotefalse.Comment #24
mistergroove commentedI see your point. After doing a bit of research it seems like t() is a massively misused function. Theres so much bad information out there. I have taken this out of the code for now though - I think I need to look into the usage of the tt() function as an alternative. Do you have any ideas on how to present user input text to the translate interface?
I have also updated all TRUE and FALSE constants.
Hope thats everything. Fingers crossed :S
Comment #25
mistergroove commentedAdded a couple of small enhancements and documented the marker theming example files better.
Comment #26
avpadernoIf you know the string that will be passed to
t(), and they are limited, you can create a file (possibily with a name prefixed by the name of the module) that will never be used from the module, and that contains something likeClearly, this can be done if the strings are in a closed set. If the strings are the input of users, then it is not possible to do what I said.
Comment #27
mistergroove commented:( Yes this is user input. I'll do some more investigation into this later. Whats the next step in getting this released?
Comment #28
avpadernoTo wait until somebody approves it, or reports something that needs to still be changed. :-)
Jokes apart, I will review the code later. As you can see, there are a lot of CVS applications that need to be reviewed.
Comment #30
mistergroove commented:) Sure. Thanks KiamLaLuno...
Comment #31
avpadernoThere are some IF-statements that need to be fixed.
Comment #34
avpaderno