Google Maps and existing fields

[alexh]

We talked about this a while ago, but I don't think we had a solution yet.

I have an existing set of forms that feed into one formtools form. The address field is broken down to:

Street Number/Name (i.e.) 123 Main St.
City is a dropdown box, to limit which cities can be entered
Enter Zip Code: 12345
State is always CA.

I would like to create a google map field with the full address.. but I would have to somehow merge those fields into one.

Any ideas?

Alex

[Ben]

Hey Alex,

I really want to do this, too. With my own work, I've found that we need to keep the address fields separate, so we just can't use the Google Maps field type. It's a big shame because, well, Google Maps is awesome, and clients would sure love it.

The thing is, I haven't settled on a decent solution that doesn’t require a Core change yet. Let me sketch out the most workable solution I’ve come up with, then highlight the problems and get your feedback.

First, we need to keep the module simple (obviously!) and what it does right now is pretty cool: it has a single field where you add the field, click "update" and the map updates. It’s simple and it has a valid use-case; it’s easy to set up and doesn’t require sifting through any documentation. This I like.

We need to extend it for both options: single field input like now, or to allow it to pull from other multiple fields.

The field type currently has 4 unique settings:
- Map Size (i.e. height)
- Show Lat/Lng when editing
- View / Export (how the content is exported - address/lat lng)
- Field Comments

So maybe the simplest way to update it would be to add two new fields:
1. - Address Source (radios): "single, inline field" (default, works like now) and "other fields"
2. --- other fields: where they’d specify which other fields contain the address, city, state etc. (this setting would be relevant only if you selected "other fields" in the previous field).

That would provide the module enough information to pull the data from the other fields. However, there are problems, the first two caused by limitations with the Edit Field dialog (which is where those settings would be added).

Problems

#1. (and this one’s relatively minor): the second new settings is only ever relevant when you pick “other fields” for the first setting. It *should* be enabled / disabled when the first option changes value. However, the Edit Fields dialog doesn't permit that yet. From a usability perspective, this would suck. The textarea field type currently suffers from this same objection: when you pick word counter or text counter, there’s a second field to add the permitted count. It’s up to the user to put 2 & 2 together and enter a value for that second field (this is bad, and I had to hold my nose when I was doing it).

#2. (this objection’s more serious): there has to be a way for the user to specify which of the other fields contains the address info. *Ideally*, you'd be able to specify them through dropdowns containing the field lists, but that's not possible yet without a Core change. The field type options section is very basic: each field type just specifies a hardcoded list of options / field types. So for this module, you’d need the user to enter (say) a comma delimited list of field names. It would have to be ordered - address first, city next etc. - so the module would know in what order to assemble the address info to pass to the Google Maps field.

This I don't like... it would require the user to locate the field names (or column names). And what if they changed? That would mean they’d need to remember that those values were hardcoded in the Google Maps field configuration and go in and re-edit them later. This, well, sucks. It’ll lead to confusion.

#3. What if you set up the Google Maps field to pull the data from fields X, Y and Z, but the View that it's put on doesn't contain one or more of those fields? It would prevent the field type from working properly since it wouldn't have all the information in the page. However, I don't see a way to prevent that with the existing UI.

So yeah, technically it could be done now, but I hesitate to launch into work on something that isn’t as good as it should be, you know?

Thoughts?

- Ben

[alexh]

Ben, thanks for the explanation. I totally see how this isn't as cut and dry as I figured it would be. I guess there is a real trade-off to making the submission more idiot-proof for the person submitting the data vs. the person setting up the back-end.

As we all know, trusting everyone to enter an address in the correct format is not exactly realistic. Unless of course, there was a way to "verify address" on submission. That of course would take some thought.

If there was a way to verify address on submission, and have the user submit the data in the google maps module way (123 Main St, Anytown, CA 99999) I would then not be able to sort data by city. Since right now, I have the city as a drop down, I can sort the data easily.. and even filter data so some of my clients can only see submissions in their city, which is important.

I guess if it were possible, I'd be happy dealing with the difficulty of initial setup, if it meant I could get it working correctly. I understand that means tons of documentation and a million questions when lots of people can't figure it out, or get stuck on something. You're right, the module you wrote is super easy to use, and requires little documentation.

[alexh]

I just thought of a possible solution for my problem. Your map of formtools installations made me think about it.

I could have a google maps field that allows someone to enter an address, and have a button like yours that maps that address (so they can verify it's valid), and then submits it.

My issue was that I wanted to sort data by city. Can't I just set up a filter that checks that field for the specific city name "San Francisco"? Instead of doing an exact match (equal to) like I do with the dropdown, it's just a partial match.. "San Francisco" anywhere in the field.

What do you think??