As far as I see you are refactoring the whole location module and I am very anxious what will be the result.
If I am right, especially the input fields will become a sort of cck fields.
Now I am wondering if it will be possible then to make the input-fields dependent on a taxonomy by the use of the Taxonomy Fields module?
If that would work, it would be possible to offer to the user only those fields, which are necessary for the type of location he is going to submit, e.g. not display the "street" field if he wants to fill in information for a whole town or a country.

Comments

yesct’s picture

Status: Active » Fixed

In the new versions, fields can be either required/ allowed or hidden. So I think this implements the feature you are looking for. I'll mark this fixed.

smitty’s picture

Thanks for the hint. Unfortunately I've no time to test this at the moment.

But are you sure, that I can include a taxonomy in the node and show/hide the Location-Input-Fields on the fly when changing the selected taxonomy?

yesct’s picture

Status: Fixed » Postponed (maintainer needs more info)

oh, i think i did not quite understand. can you give an example to clarify?

smitty’s picture

Well, I just want to include a taxonomy field at the beginning of the form, where the user can make a choice if the location he wants to describe is a ‘real’ location (e.g. a restaurant), a town, a province or a country. If he chooses, that it’s a country only the location field ‘country’ should show up. If it’s a province additionally the location field ‘province’ should be shown and so on. So the user can fill in e.g. the street only for a ‘real’ location but not for the other areas.

There is a module called taxonomy fields http://drupal.org/project/taxonomy_fields which supports this for ‘normal’ CCK fields but could not be used for the location field because this fields were not CCK fields.

yesct’s picture

Have you tried that using the location cck fields?

yesct’s picture

Title: Make input fields dependent on location type » Show input fields dependent on location type (taxonomy_fields module or ajax or ...)
Status: Postponed (maintainer needs more info) » Active
Issue tags: +location cck, +location theme edit form, +location compatibility with other modules, +location hierarchial select or ajax

So, you are not looking to "fill in" the input fields, but to display them or not display them?

This sounds similar to an approach where a user would select the country first, then depending on the country, the next field might be a state, or might be a city (if the country does not have any states, or whatever). I think this kind of thing might be handled in the location.xx.inc files and might be related to an Ajax kind of hierarchial select.

I wonder if you might be able to hack it by making up some "country" xx files .... hmmm but I think the ability to do this might be far out using the native location fields. Another approach people are trying seems to be using form_alter (search for form_alter in the location issue queue).

Well, I cant be more specific, but maybe they will inspire someone to reply, or you might find other posts to help you.

Hmm, a thought: if you had a different content type for "real" or "town" or "country" then I think you could "do not collect" or "require" fields for each of those content types. so they would not pick a drop down exactly, but click on what kind of location they wanted to create, and it would be a different content type?

smitty’s picture

Unfortunately i haven't got the time to do some tests at the moment. But I hope I can do it in some weeks and then I'll report here.

To use different content-types is possible of course. But then you have to support them too and every change has to be made several times (for each content-type). Furthermore if a user chooses the wrong content-type he can't just change a checkbox but he has to delete the node and create another node. So the usability is not so good.

yesct’s picture

Good points. Maybe using one content type, then using a node-contenttype.tpl.php file you could control the fields that are displayed. Not a nice GUI UI, but the change would be in one file. Well, it's just a stop gap idea.

ankur’s picture

Version: 6.x-3.x-dev » 7.x-4.x-dev
Status: Active » Closed (won't fix)

Something like this might be possible in 7.x-4.x. Closing the issue for now. If the request still stands, feel free to re-open it and it will be evaluated later for 7.x-4.x.