I would like to request the following feature:

  • The values for city, state and country of an address field are not only a string, but can be a nodereference to another cck node.
  • The content types for city, state, country can be freely designed with CCK.
  • In the configuration form of an address field, you can setup, that the city field is also a nodereference to a city node and you can setup the content type that should be used for city nodes (e.g. node-city). You must also setup which field of that content type should be used for the name of the city. So if a user enters a new address, the NodeID (nid) of the selected city node is stored with this address field, instead of the name of the city. If the address is to be displayed, the name of the city is read from the referenced node out of the defined field that contains the name. The same applies for, state and region.
  • If a user creates content, that has such an address field, the name of the city is looked up via autocomplete from the set of existing city nodes. If there is no existing node for a city, yet. A new empty city node is created with the name entered by the user. The same applies for state and country.
  • When entering an address, the user first selects the country (reference to a country node via autocomplete textfield). Next he can select the state in another autocomplete textfield (but only existing states of the previously selected country are shown). Next he can select the city in another autocomplete textfield (but only city names that belong to the previously selected state and country are shown).
  • There should be a special formatter available, which themes the city, state and country values of an address field as links to the referenced city, state and country nodes.

Comments

rconstantine’s picture

rconstantine commented
Status: Active » Closed (won't fix)

Wow! That is some feature request. However, although I can understand the usefulness of such features, it would require an entire rewrite of this module, which I cannot do at this time and I'm not sure I would want to.

However, you might be able to design an add-on module for this one. I'll address your points in order:
1) I am unfamiliar with how node reference currently works, but an add-on module could form-alter the fields you mention to be text fields with auto-complete. It would also possibly need to override the validation and submission functions.
2) This would not directly be handled by the add-on module, unless you mean that you can choose which content type is associated with each field when you setup the address field. I think a better way is what I describe in #4 below.
3) I partly addressed this one in #2. Selection of which field of a node to use might prove tricky. Is there a reason not to give the city nodes' title the name of the city and then just stick to that? I think the tables for this module could be expanded on by the add-on module to include the nid that the state, city, or whatever points to. It seems to me that each should have just one node, and many of these fields can point to the same node. In other words, you will have many references to Dallas in the address field of many nodes, but only one Dallas City Node, right?
4) To speed things up, I would also suggest storing a copy of the node title in the address tables. This would only require a hook_nodeapi case to deal with title changes. For states and countries, this would allow the use of existing add-on modules to populate country and state lists. Country and state could operate as they do now if the add-on module, rather than having the address field set the node reference, allowed a user to associate a node with an address field. What I mean is this: You are thinking of associations of address parts to nodes. What if you turned that around and associated nodes to address parts. For example, with cck_address installed as well as an add-on module which modifies the tables, you could have options of fields to place on nodes called address references. So let's say that you make a city node. That node has the add-on module's state reference field in it. You are presented with a country drop down and a state drop down. The node ID of the state node you just made is then added to the address master table of states. Then, automatically, all nodes that use the standard address field could have their display altered to link the state field to that node. Am I being clear in my explanation? In other words, when you create a city, state, region, or country node, tie it to the address module there, then automatically turn address display text into links to those nodes (or add a simple checkbox to the content type creation to prevent links from being made).
5) Your first two sentences are how things work now. The third sentence has been addressed somewhat in the past. However, I think you are thinking of simple text-field autocomplete, which has not been considered before and should work. Previously, users requested that this module come with lists of cities, which would be impractical due to the number of cities and the number of new cities each year.
6) The add-on module could do this.

I hope you find this view of things useful. Like I said, I'm not going to tackle this myself, but would welcome a contributed add-on module to roll with the tarball of this one. That would allow users to choose which functionality they want. I was writing my suggestion in #4 on-the-fly, so it may not be as clear as it could be. If you would like clarification, let me know.

sandeepyadav’s picture

sandeepyadav commented

hi
I want to add more country an states corresponding that countries. How would this possible?
Is there any possible node to add them ?