Posted by magnus.ramon on September 12, 2010 at 11:49pm
Location module is not fulfilling some needs, so I've got into a point where there nothing else to do but start coding. The idea is to do the following patches as soons as I can, based on 6.x-3.1 version:
- one country only
I think a great part of Drupal sites are national wide (created for users of one country only); so there is a lot of code in Location module that can be jumped for that kind of site - district/county/subregion field
some countries, like Brazil, have their cities divided into districts or counties or subregions; so location based sites can't help their users efficiently without this field - auto-complete re-use of locations
in many sites (like the event/venue model) repeated locations are the most common; so it will be much easier and space saver to have a location load auto-complete field (name or street) - zip code based locations
in Brazil, zip codes are strictly numeric and summarize state, city, district AND street portion (bigger streets have 2 or more zip codes); this way table location needs to handle just the fields name, number, additional and zip code; the rest of location data will be left for zipcodes table* with the zip code as index
*: this table have no reason to be pre-filled, like UK or US model, as the amount of zip codes is an 8-digit number - location load auto-complete zipcode field
brazilian location based sites can have their location form with just 3 fields: zip code, number and additional (for locations already in the db);
The project is to make them independent, to be applied combined or not, according the site needs.
Comments, ideas and contributions will be welcome.
Comments
Generally it isn't a 'Drupal
Generally it isn't a 'Drupal pattern' to have features addable or removable with patches - not only because patches can be difficult to combine, but also that many site-building paradigms don't make patches trackable enough to guarantee that module upgrades don't wipe out added features. There's also the fact that some of these things are just straight-up features, which the location module would certainly accept outright if they were developed with assistance of the lead developers, and other ones would probably be very useful if they were to consider countries other than Brazil.
Essentially, with site deployment, depending on patches for features is a dangerous thing, and having your code in the mainline of a project is something of an automatic boost to the code quality. I'd highly recommend that you try to get these changes into the mainline of Location or into another contrib module, rather than jutting out on your own. It's open source: when you hit limits, 'coding' is not the only option: there's also talking and contributing.
When I said 'patches' I was
When I said 'patches' I was stupidly referring to new features, not necessarily implemented as patches. Considering the open source vision and Drupal community, remembered by tmcw, I'm thinking the solution for one country only and auto-complete re-use of locations problems as containing module oriented (not sure if containing module is the term form modules wrapped in the main module release).
Here are my ideas:
I'll give a look into the possibility of making multiple countries locations as an option, a containing module for Locations
another optional module, in case the site needs unique locations only
But about district field problem, I'll wrap the open source vision with some of my own thoughts:
the simplicity of this feature is not proportional to the way processing, querying and storage will be increased with a contributed module solution; in this case I think starting with a patch is better to see if there is enough users interested in the feature and then care about making it right
if so, I'm thinking of it as a default feature, reflected this way in db, with a containing module to disable it (including it's column elimination)
At last:
I'll give a look into it only after the other features have been implemented
Again: comments, ideas and contributions are very welcome.
Magnus