Sep 16th, 2011, 11:16 AM
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
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