| Project: | Country codes API |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
This is a follow up of http://drupal.org/node/409218#comment-2120404
The countries_api is a great module, we used it ourselves on a few accasions to get the ISO2 base for countries, but the playing field has changed slightly in Drupal 7
Core Drupal 7 now maintains a simple iso2 / name list. If a module developer is going to create a new db record based on ISO2 codes, there should be no dependency of having to install another module to replicate what core does, the only dependencies should arise when additional features are required. The module that I have written at http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/countries/, is an extension of this new Drupal way of handling the cores values to managing these core country codes. Currently the only usage of these values in core is on the users default country.
Three main features where I was going with this:
- To allow additions / modifications via drupal_alter('country')
- An interfaces to handling simple country fields - enabled status, name, codes, etc
- Country FAPI element and field widget.
If no to any of these, then there is absolutely no overlap, as dropping the additional columns other than enabled and code would have no bearing on anything it does (except for the continent filter) as it falls back to using core Drupal country ISO2 / Names array. Any ISO2 country database is a duplication of what core does! Also, I personally would not want to see any additional features added to a low level country api; services / regions etc. I have never used a simple regions / country relations. Every implementation we have used regions have been different, usually based down to the city / town level, but I do see this need for this in many use cases.
I really do not care about code ownership, I just have a real need for all three of the above features. If you want to expand this module to do this and take lead, I'm happy for you to rip as much as you want from the CVS version into your own, or I can even transfer ownership of the committed module to you if you want to run with it. The only thing that I would want to do to the committed version is to add i18n support for the country names.
Cheers
Comments
#1
It is still too early to start looking at i18n for Drupal 7, as the core issues are still very active and no work with porting i18n itself has started yet.
Closing the issue, contact me via http://drupal.org/user/198838/contact to discuss further if you want, but I don't see any overlap.
#2
Feedback from others are all pushing these features to be merged into the countries api.
Anyway, the 2 line idiom for a country options list by any module should be:
<?phpinclude_once DRUPAL_ROOT . '/includes/locale.inc';
$countries = country_get_list();
?>
I don't see how you would maintain the basic guarantee of the field mapping between different services, eg: name => ISO2 etc once the names become editable, which is my primary focus, but the community has spoken and I will rest my case. If you disagree, and you do not want these features in Countries API, please reopen #394006: Reopen and reassign Countries project.
The repository version of countries was for the HEAD version of Drupal updated Oct 11. I think this was before the core Drupal 7 refactoring of the theme arguments into the single $variables argument, so the code is probably no longer functional. Anyway, feel free to use or ignore this as a base for any new features. It would be great to include at least a Country field, it seems nasty to make user enable two separate modules to provide this functionality, and is bad for performance.
#3
Subscribing.
#4
Subscribing. I've checked the countries module out from cvs and it looks very promising. It would be great to see collaboration and consolidation in this area.
#5
Well it's still too early for me to deal with Drupal 7 but there is a solution for Drupal 6.
Introducing countries_api_cck module: the (attached) module exposes (using underlying countries_api API) a field to CCK subsystem.
Features:
It works with countries_api version 6.x-1.1 (
$Id: countries_api.info,v 1.1.4.1 2009/02/28 20:44:59 mrfelton Exp $).#6
Nice work. Some tiny side notes:
You should not include the trailing "?>" on the install, as this can lead to issues if a whitespace gets mistakenly added after this.
The element "countries_api_cck_select" would be best named "countries_select" or "countries_api_select" and be independent to CCK. This allows developers to use it outside of CCK :) But as of Drupal 8, everything will probably be fields though!
And as performance = 1 / # modules, maybe see if you can integrate this into the module. Ask mrfelton what his thoughts are.
If they are to be separate, I'd almost consider cut n' pasting the countries options from Drupal 7 core into an include and using this as the primary method of generating the countries list. Then adding countries_api support for the additional fields formatters, etc.
Also consider the namespace. CCK is nearly dead and Drupal 7 is already in the early production stage. While there is no alpha to xxx upgrade support, as of beta 1, there should be update paths to all new future betas, rc's and standard releases now. AKA, it should be safe to start long term development products with Drupal 7 now.
#7
It will be sad if it takes 4 or 5 modules need to be created just to handle the new features that I added in the countries module. Since you appear to have some time, maybe you could volunteer to merging the two modules.
See #394006: Reopen and reassign Countries project. I've just added a run down on the API overlap.
On top of this there is also:
cheers
#8
PS: This is a Drupal 7.x issue, there just isn't a D7 version to assign it to yet. There is a simpler D6 version of countries is in the repository.
#9
There will not be a Drupal 7 version of countries_api. Instead, the countries module should be used. With that said, I don't think there is anything that needs to be done here now - please correct me if I'm wrong!