Start at a better country/province interface

Robert, thanks for the patch. I've been hoping for a while now that someone that knows JavaScript would submit the patch that forces a province selection to conform to the country selection on the browser-side.

But there's a couple of things that I'd like to work around:
(1) I tried the patch and it didn't work for all themes. Will locationext.module only work with the phptemplate engine?
(2) Also, I'd like for a 'blank' and/or 'Not listed' option to show in the narrowed-down list of province options, just in case our lists aren't comprehensive.
(3) How does the patch work when the country selection is hidden?

I'll try to find some time to play around with the patch and location.mysql to see what I can do about these issues before I make a commit. In anycase, thanks a lot again for the patch man. Like I said above, I've been hoping someone would post something that did this.

-Ankur

I've spent some time today looking into the Active Select module to allow us to do this. With this attached patch, the Active Select module allows us to filter the provinces/states based on the country selected. If the module is not available, or JavaScript is disabled then the province/state list behaves as currently. Otherwise, if you have a default country set then the list starts out with only the states for that country.

If no default country is set (i.e. '') then the whole list is shown. One downside is that when this is the case, if you select a state from the whole list and then select a country, the value gets overridden (possibly an issue for the Active Select issue queue) and you have to select it again. One way to get around this might be to move the country selection to the top of the list. Then most users will select a country first, and then continue to the rest of the list. I've seen a number of online forms do it this way.

Right now, this will only work properly for one location - the first in the list. We need to pass in the index of the location form to get this to work for more than one.

This is awesome stuff. +!!!!

Just wondering if you'd had the time to get any further with this as it sounds very interesting and location is very difficult to use for international locations at the moment.

tracking...

this patch seems to be out of date. i have been playing with it a bit, but i still have not been able to make it work. the patch fails on line 22 of the location.module file...

I have gotten the patch to work by manually copying in the code into the files and making some minor adjustments. module_exist() is now module_exists() and that will throw an error if not changed.

Thanks for trying it out and getting it working swill. I'd be grateful if you could post an updated patch.

Did you have any thoughts on usability, etc?

tracking as well

Just subscribing.

geodaniel's patch can be applied with a little renumbering.

However, performance on loading the page is abysmal (in Opera, anyway) - and
any existing county setting is lost when editing the page.

About the only way I can think of to make things usable is to do any editing of the country
on a totally separate page - i.e. to split things across two pages, one of which
edits the country, and the other has a restricted list of counties (and everything
else on the page). Major surgery. Maybe there's another solution using XML messaging.

On reflection, a reasonable solution would be to use
the ActiveSelect patch if there was no selected country,
and to only load the provinces associated with the country,
if a country already exists for the node.

That would mean two submissions if you wanted to
change the country - but IMO, this is a solution that is
technically managable - and that would actually be
usable.

Not quite sure what ActiveSelect means, but I would very much like to avoid the two-page idea. My problem is that I am very un-proficient in JavaScript, but I do know that JavaScript can solve the problem with the following condition currently implemented in the location form:

The value of the country options are lower-case two-letter ISO codes for each country (with the occasional variation -- United Kingdom is 'uk' instead of 'gb'). Now, the values of the options in the state/province select all start of with the country's ISO code. For example, California,US, is 'us-CA' and New York, US is 'us-NY' and so on. Now I'm pretty certain that we can add some kind of .onChange() type thing to the country-select form item that causes the filtering out of options in the state/province select so that we only keep those state/provinces that start with the ISO code used as the value for the selected country in the country-select form item.

I believe that the original patch given by RobertDouglass did just that, except it was hardcoded to the PHPTemplate engine, i think.

-Ankur

Ankur, that's pretty much what my ActiveSelect (see the ActiveSelect module) patch in #2 does I think (it's been a while since I've looked at this).

tracking

Subscribing

What do you folks think about Hierarchical Select? I just discovered it, but haven't fully explored either option at this point. It may be a more natural fit, but it hasn't been released yet. There's even a demo page with a county/city example over at http://drupal.org/node/216372.

The demo here: http://wimleers.com/demo/hierarchical-select look nice

If after the gmap are centered of the current focused region... that's cool.

Hierarchical select would be a great option for the country/province selection. It now has a formal release too.

And see here http://www.couchsurfing.com/mapsurf.html , the gmap is dynamically centered when you select location.

I suggested Hierarchical Select over here: http://drupal.org/node/231419#comment-761786. I also made it a DROP Task: http://drupal.org/node/230639.

Not sure if this should really go here, or over at #217512: [master][meta] Normalize location table / enable shared locations / fix location deletion / fix revisions / make forms not suck, but I wanted to mention an old interest of mine that's related to this:
#45593: adding support for a default province/state?
That's been marked duplicate -- seems like the mood in location.module these days is in favor of monster patches for big issues, as opposed to smaller discrete chunks...

I tried both. Hierarchical Select is good for small project because it isn't AJAX capable yet. Active Select is better for large project because it's AJAX capable.

For a large project with 100,000+ vocabulary (20MB taxonomy database) AJAX capable dropdown menu means faster loading because the data is loaded on request only. And not AJAX capable dropdown menu means very slow loading because all data is preloaded.

True. I'm start working on a more scalable version of Hierarchical Select. See http://drupal.org/node/226067.

Hierarchical Select is good for small project because it isn't AJAX capable yet

I don't understant, if i'm go on the demo page http://wimleers.com/demo/hierarchical-select and active my firebug extension... the data are clearly loaded on the fly (with the http://wimleers.com/hierarchical_select_json files). So Hierarchical Select use ajax, no?

False. Hierarchical Select version 2.1 doesn't use AJAX please find below proof. But Wim Leers the developer said that he wants to add this new feature in a future release: http://drupal.org/node/226067#comment-786393

The module Active Select is AJAX capable though. But limited to 3 levels only: http://drupal.org/project/activeselect

Here is one way to know if a module is AJAX capable or not:

Step 1 – I open my internet browser. Firefox in my case. I go to the page http://wimleers.com/demo/hierarchical-select I don’t click or select anything on the page.

Step 2 – I click “View” menu, then “Page Source”. Please find screenshot “View_source_with_firefox_step_2.jpg”.

Step 3 – A new window will open. That’s the source page. Everything I see in the source page is preloaded. To test this search for the term “A-Klasse” into the source page. “A-Klasse” is there so it’s preloaded. In other words not AJAX capable because I haven’t yet selected the option “Merceded > A-Klasse”. In this case that’s just fine because there’s only 12 items (A few bytes) in this particular dropdown menu. But if I have 100,000 items (20MB or so) this is too big and slow when all preloaded. Please find screenshot “View_source_with_firefox_step_3.jpg”.

Not AJAX capable 12 items are preloaded:
Aston Martin
-DB9
-Vanquish S
BMW
-3 series
--318i
--325i
-7 series
--714i
Mercedes
-A-Klasse
-M-Klasse

AJAX capable 8 items are preloaded. The balance is loaded on user request:
Aston Martin
BMW
-3 series
--318i
--325i
-7 series
--714i
Mercedes

Onopoc: not quite. Hierarchical Select is fully AHAH driven. The only reason everything is "preloaded", is that's what Hierarchical Select degrades to when JS is disabled. And that's exactly what's the cause of the scalability issue.

Fixing this scalability issue is my top priority currently, so you can expect it within a few weeks at most.

Great I’m looking forward to a Hierarchical Select AJAX capable. It would be a very nice feature.

Maybe I wasn’t clear in my last post. I was refering to the users' point of view not the developer's point of view. What I meant by Hierarchical Select 2.1 is not AJAX capable is that actually everything gets pre-loaded in the webpage. In other words, every possible combination within the same taxonomy (vocabulary) gets pre-loaded here’s the proof: http://drupal.org/node/31609#comment-787452 JavaScript (JS) on or off every possible combination gets pre-loaded. I tested both cases.

In simple terms if I have a large project with 100,000 items in a dropdown menu the 100,000 items get pre-loaded. That’s a pain for the users because 100,000 items represent 20MB or so. Loading time for a 20MB webpage:

• 49 minutes with a dial-up modem at 56 Kb per second.
• 7 minutes with a DSL/ADSL at 128 Kb per second.
  
  Source: http://www.onlineconversion.com/downloadspeed.htm

Who would wait 49 minutes or 7 minutes to see a webpage? Plus during the loading time the webpage is blank nothing at all.

Here’s the results of the testing I did with the module Hierarchical Select (version 2.1). Total webpage size is 20MB including webpage and dropdown menu. Loading time is 49 minutes with a dial-up modem at 56KB per second & 7 minutes with a DSL/ADSL at 128KB per second:

      -Taxonomie level 1 (root) PRE-LOADED

      --Taxonomie level 2 (level 1 child) PRE-LOADED

      ---Taxonomie level 3 (level 2 child) PRE-LOADED

Here’s the results of the testing I did with the module Active Select (version 1.0). Total webpage size is 100KB including webpage and initial dropdown menu (level 1 (root)). 14 secondes with a dial-up modem at 56KB per second & 2 secondes with a DSL/ADSL at 128KB per second:

      -Taxonomie level 1 (root) PRE-LOADED

      --Taxonomie level 2 (level 1 child) NOT PRE-LOADED

      ---Taxonomie level 3 (level 2 child) NOT PRE-LOADED

When comparing those two results we can affirm that AJAX capable module loads 210 times faster (2 secondes compare to 7 minutes).

Again I’m looking forward to a Hierarchical Select AJAX capable.

No, you're misunderstanding me, onopoc :)

That's not preloading, it's for the degradation (i.e. when JS is disabled). Hierarchical Select already uses AHAH callbacks to the server to update the per-level selects and for the dropbox (when multiple select is enabled).

Great thanks for the info Wim. I'll try again with multiple select enabled.

Adding to/removing from the dropbox are just 2 cases of callbacks to the server. When updating the hierarchical select is another case.

Enabling multiple select will just allow you to use the first 2 callbacks. It won't make Hierarchical Select scalable all of a sudden.

Sorry for not making that clear enough.

subscribing.

Wim: Yep you're right. I tested it and enabling or disabling "multiple select" the loading time is still 49 minutes with a dial-up modem & 7 minutes with DSL/ADSL.

Sorry about that I should have post on "Hierarchical Select > Feature request". To avoid confusion I'm opening a feature request here: http://drupal.org/node/241513 (AJAX capable dropdown menus)

I *know* about that, as I've repeated numerous times by now. Please stop adding noise to the issue.

Reply at: http://drupal.org/node/226067#comment-792269

Hi,

Hierarchical select and location integration would be great for selecting countries/regions/city,
Is there still progress in this field?

greetings,
Martijn

Not yet. But it's coming soon! :)

I wanted to start working on this, but it seems there are several missing pieces and important things I need to know first. I contacted Bdragon, so I'm awaiting his feedback.

subscribing

EDIT: Subscribing for drupal 6 HS Location solution.
greetings,
Martijn

I'll write the HS integration if there's enough interest. Definitely if it'll ship with Location. HS version 3 is ready for prime time for D5 and D6.

Hi Wim,
+1 for HS integration!
Greetings,
Martijn

subscibe... exactly what i've been hoping this would turn into eventually

Subscribing... It would be really great to select Countries / provinces with dependant dropdown menus, it's far more intuitive than the autocomplete field.

Subscribing

tagging.

This would really ease some of the location data entry UI woes we've been having on http://evolver.net for international locations.

Love to see this Wim!

Some of the tags, I'm using to try and help start a documentation faq for location, so I'll add that one back.

See other tags in the start of the faq at:
#434714: documentation/faq/help

(Aside: I started using the tags, and in a couple instances have wondered if it is better to tag something or just do a search on a word. Like I figure we dont need a location tag, because we can just search in the location issue queue, or use location in the search field. I wonder if there is some guidelines for what is effective use of the tags on issues in d.o.)

subscribe

subscribe

Hi,
I am confused or someone is working on this? Here http://drupal.org/node/230639: it is put to this thread.
But it is about location AND Hierarchical_select support?

Would love to have Hierarchical_select support on location_cck country, province and city field. It would be great if location would use taxonomy for this filling, but that would be to much to ask...
greetings,
Martijn

There didn't seem enough interest, which is why I didn't write this.

Hi Wim,
I think there is a lot of interest. Especially if it would be integrated with taxonomy I think.
If you look at the google search "location province" you see a lot of people struggling with the UI.
It would be great if you would build the location HS still?
Thanks for considering this in advance!

greetings,
Martijn

How could this possibly be integrated with Taxonomy?

It'd definitely be Location-only.

Ok, I understand. I was thinking two things in one I think :( Sorry Wim. Off course Location only and then in location may be a glue module to have location country/province/city be mapped to taxonomy.
Greetings, Martijn

I submitted a patch that may be an interm solution: http://drupal.org/node/624842

The patch allows for multiple province selection using the autocomplete field. For multiple countries, you can expose the country field and province field, then select provinces using the autocomplete textfield. There's a couple of steps involved: select country, click apply, type in province and autocomplete will fill in the province name, click apply and view will display those provinces. You can enter multiple provinces that are comma separated.

I think HS would be fantastic from the user's point of view, but from the admin point of view (if you don't need to expose the country or province) I still need the ability to select multiple provinces for a display.

I'm not sure if there is still a request for this, but I do know that since this issue was originally posted, the province selection has been changed to an autocomplete field that completes only to province names in the selected (or hidden default) country.

It this is something that needs to be re-opened, please change the version to 7.x-4.x as that is where are new features are going at this time.

Hierarchial Select (with capitals) is the more common term. changing to that so the lesser used one (with all lowercase) can be deleted. https://www.drupal.org/project/issues/search?projects=&project_issue_fol...