Improve code that filters out the relevant part of the form in an AJAX request

Please make sure #tree is set to TRUE on every level that leads to the HS and report back. I'm pretty sure that's the cause.

I'll have to make that part of the code more robust I guess.

I agree; that's why I wrote that I have to make this more robust in the first place.

I will have a look at how D6's Forms API handles this, I hope that they do support this, but I actually doubt it.

The cause is in either of these functions, or in how they work together:
- _hierarchical_select_collect_form_parents() -> stores $element['#parents'] in the database for each HS, so that we can find out which part of the form we should render in a AJAX update (AJAX updates happen in hierarchical_select_json())
- _hierarchical_select_get_form_element() -> retrieves an $element of a $form with the given $parents structure

The former stores an inaccurate #parents tree when #tree is FALSE somewhere along the line, the latter then can't find it. You could say we could "improve" the latter to find it anyway, but then you might end up with the wrong element or you might have to search for a long time. So we'll have to find a way to detect the "real" parents of the $element in the former (i.e. calculate our own #parents as if #tree was always set to TRUE along the line). The problem is we only get $element, not $form… (because _hierarchical_select_collect_form_parents() has to be called from the #process callback for the HS form element).

That will probably not be understandable or at least partly so, unless you know the Forms API very well. Let me know if you're going to give it a shot!

Views exposed filters work just fine here.

I just remembered: I found a bug in Views, which caused this very problem. You have to install the 5.x-dev version of Views or apply this patch: http://drupal.org/files/issues/hs_compatibility.patch.

This *is* documented in the README:
* Views 5.x-1.x-dev tarball of May 11 or later (http://drupal.org/project/views)

This does not yet fix the #tree stuff though.

My fears have been confirmed:

WimLeers: hm, while I accidentally pinged you, here's a FAPI problem I'm facing. I want to render a specific form item in an AHAH callback. No problem, store #parents, and then find it back. However, I also need it to work if somewhere in the form item hierarchy #tree == FALSE… Do you know of an *elegant* way?
WimLeers: chx ^^
chx: i think no

So, there are only 2 100% reliable ways around this:
1) set some recognizable form property (e.g. '#hs_anchor' => <random number>) and then scan the entire form for these properties with those specific random numbers in an #after_build callback. This allows us to do this "full form scan" only once, i.e. in the first rendering.
2) force form developers to add a new #real_parents property that the developer must fill out himself. This results in faster code, but slower development.

I'm going for option 2. It's not *that* bad to expect this from the developer, and it prevents the code from getting complexer than it already is.

Fixed. Committed patch is attached.

As you can see, #real_parents will simply be used when it is set and is not the empty array.

Let me know if it works for you!

Good remark. I'll have to play a bit with the $phase parameter I guess.

Reopening.

As said in #8, there are only 2 reliable solutions. The first one requires no further work of the developer (it's "automatic"), but is more work. The second one is much easier but requires work of the developer for EACH form.

I implemented the second. But now I will have to implement the first, to solve these issues:
- http://drupal.org/node/260896
- http://drupal.org/node/273702
- possibly also http://drupal.org/node/266960

Implemented!

I'm now storing the #name property of each item to find the hierarchical_select form items back. While these properties are NOT guaranteed to be unique, it's up to the developer to make sure that they are. Even the Forms API itself assumes this, and unless you're doing something VERY, EXTREMELY, SUPERDUPER special, you should not bump into any issues.
I mean, if CCK, Views and other complex don't even notice this, we should be safe! :)

Almost forgot: thanks to Earl Miles (merlinofchaos) for the #name tip. I was adding a custom #tracker property, but this makes much more sense. #name is also based on #parents (it's basically: $form['#name'] = implode($form['#parents'], '-');), so I really should've thought of this myself. Thanks, Earl! :)