Add multiple address component, select box support, pre-existing markers #69
Conversation
The available options for values from the geocode request do not include a street only address, e.g., 123 Main St instead of 123 Main St, Anytown, USA. This option was added. The setDetail function failed to set select dropdowns with the proper value. I personally was using them for state selection, but it should work for anything where the returned value from the geocode is a match for the select option's value or text. This has been added now.
fixed the $element.is("select") branch so it works
| @@ -363,7 +363,7 @@ | |||
|
|
|||
| // Set the values for all details. | |||
| $.each(this.details, $.proxy(function(key, $detail){ | |||
| var value = data[key]; | |||
| var value = (key !== "street_address_only") ? data[key] : data["street_number"] + " " + data["route"]; | |||
There was a problem hiding this comment.
Unfortunately the layout will depend on the country. In some places it is route number in other places number route or number, route.
There was a problem hiding this comment.
I agree that different regions need different street address formats. Addresses are one of the largest headaches I've come across. I think it would be a good option for a user of this plugin to be able to fill the desired form field with the street address of their choice. I would propose to either offer multiple format types, such as street_number_route, route_street_number, etc., or give the option for multiple types in the data attribute on the input. For example, data-geo="street_number route" which would fill with "123 Main St" or data-geo="route street_number" which would fill with "Main St 123". It at least still gives the option for the user of the plugin to use the street address in the format they choose. I think the second option is cleaner. If either option is something you'd like to merge into the plugin, I'll see what I can do to get it done.
…ess component support Added the ability to set multiple address component types to a single input field. The components will be set in the input in the order in which the markup lists them. For example, on a return from google of "123 Main St, Anytown, AA", using the detailsAttribute of `data-geo` and setting `data-geo="street_number route". Behavior remains the same for inputs that have a repeated component type as the first data-geo attribute. Only the first input will be filled.
somehow removed a comment line on accident. put it back in.
Inputs with sharing the same first component type in their `dataAttribute` attribute were being filled with whatever the first instance was calling for.
…to init the marker location Added the ability to pass in a pre-existing map marker to the initialization options. Can also specify whether the plugin should set the marker's position during initialization.
I added in the ability to input multiple address components into the same input.
For example, using the
detailsAttributeset todata-geoand settingdat-geo="street_number route"would result in the input being set to123 Main St. The order of the result is the same as the order in which the components are listed in the detail attribute. This can be used with any combination of address components so long as the first component in the set of components being set is unique relative to the first component in any other input in the group. This matches the original code. It should be relatively straightforward change if necessary to fill any input without the above restriction, if needed.Also added in the functionality to change the value of a select box. If the detail is set to be updated in a select box, then it will find an option that matches either value or text. This works with or without options nested within optgroups. If no match is found, no change is made.
Pre-existing markers can now be passed in to the
markeroptions parameter and geocomplete can be told whether to set the position of the marker during initialization by setting theinitMarkeroption to true/false.