Integration with new core Drupal 7 features & simple field elements?
| Project: | Country codes API |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
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
#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.