save aid within form_state when new addresses are saved

The basic idea behind your request sounds reasonable.

I'm not sure if your proposal is the best solution. The first things I notice are that

• The storage in $form_state would have to be part of the API. This is not obvious and some future maintainer might break some people's code by thinking that this setting was private to uc_addresses and either changing or deleting it. This problem could be solved by just adding a good comment.
• It creates an order dependency. If your submit handler is processed before mine, you're out of luck. This is a problem no matter how you try to get the $aid. If my submit handler hasn't run, $aid will be 0. I believe there are several ways to control the order of submit handler execution, so it might be possible to overcome this.
• Might be more useful to store the whole $address rather than the $aid (which might require you to do another database call).

A much better solution would be to create a hook function or two. Could you tell me more about how you would like to use the data when an address is added or edited?

OK, so if I understand you properly, you would be satisfied if uc_addresses provided a clean way to add additional address fields to the forms and databases. Correct?

I would love a patch. The idea sounds great. Now, let's look at the best way to write the patch. I guarantee that it is never as easy as it seems with uc_addresses.

One design pattern is to use some sort of "load" function (as with "user_load()"). Whenever an address is needed, load_addresses() is called which then calls module_invoke() (or equivalent) to allow other modules to add their data to the $address object. The additional data usually comes from a separate database table and requires a separate database fetch. This design pattern would be better than the hooks you suggest because it follows a standard Drupal practice for extending a database object.

uc_addresses was the first Drupal open source module I wrote and I inherited code written by others. I've since written uc_product_keys, which uses a much more efficient design pattern by taking advantage of the Drupal 6 drupal_write_record() function.

In this design pattern, you would add any new fields to the uc_addresses table and the schema. Records are read from the database by reading all fields (*) and creating an $address object. Records are inserted or updated by calling drupal_write_record(), which writes all the fields in the schema.

uc_addresses would need to ensure that the $address object is available for modification whenever it is reasonable to think that another module might want to update its fields. For forms, the $address object should be stored in $form or $form_state (I forget right now which is the appropriate one to use), but not in the submit handler—do this in the form creation function, so that the object is available for all submit handlers.

Since you modify the form after the form is created, the ordering problem is avoided. Any _alter() functions can be sure that the $address object has been defined and can initialize their own fields.

Outside of forms, any places where an $address object is created must call a hook to allow other modules to add their fields. Any other places where an existing $address object is modified needs to be analyzed to see if other modules might want to hook in as well.

Again, there is an example of this design pattern in uc_product_keys. It is more efficient to run and requires less code from those extending the database table (you don't need to write your own table insert/update/delete). It is just going to be a lot of work for you, if you decide to tackle this feature.

Why not just put in some quick-and-dirty hooks? Well, I believe that when code is written for re-use, it should aim for the best possible quality, performance and extensibility. By having one person take extra time, we save multiple developers time and reduce wasted CPU cycles on multiple installations.

Let me know if you still feel this is something you want to tackle. The hooks you suggest are a lot less work than anything I've suggested, so I can understand if you don't want to invest the time.

Hi freixas,

I'm currently trying to integrate your module with uc_extra_fields_pane and I came across this problem. It was no problem to save extra data when an address is edited, but not when an address is added. Did you make any progress on this?

By the way, I have made a patch to how I fixed it right now, but it's not the most neat solution.

With the 6.x-2.x version you are able to modify or use address data upon form submit. Feel free to reopen this issue if you encounter still issues with this.