Custom HS implementations: through UI instead of code by (ab)using Views! [#679168]

This is such a great module. However, what I want to be able to do is integrate Hierarchical Select with Views and center it around nodes, not taxonomy. Is that possible?

For example, here's what I would like to do. I would like to create a hierarchical select where the first select contains the results of one view, and the second level contains the results of a second view, driven by an URL argument, or something.

Is there any development toward this end, or perhaps another module which supports this functionality? This would be awesome, since it would allow users to drive their selects by whatever creative permutation of views they could think of (not just Taxonomy).

Comments

Comment #1

Wim Leers

Ghent 🇧🇪🇪🇺

CreditAttribution: Wim Leers commented 8 January 2010 at 19:09

I've thought about this myself too :) I discussed it with yoroy a year or so ago, and he didn't see the immediate value of it.

It's very doable, and not *that* hard, but it would be a lot of work to make it easy to use. But indeed, the possibilities would then be endless :)

There are more urgent issues for HS though. So if this would be implemented, it won't be soon if it has to happen in my free time (which has become very sparse). If somebody would contribute it, I'd gladly review the patch! :) Or if somebody would be willing to sponsor this, I'd definitely go for it :)

Comment #2

joelstein CreditAttribution: joelstein commented 8 January 2010 at 20:32

The big advantage to this approach is that it would eliminate the need for a specific HS Taxonomy module, since everything would be "powered-by" Views. However, I have no experience making modules for Views, so I can't help there.

I just found this module, which again, could be merged into this larger Views integration:
http://drupal.org/project/hs_nodereference

Comment #3

Wim Leers

Ghent 🇧🇪🇪🇺

CreditAttribution: Wim Leers commented 8 January 2010 at 23:22

No, that won't work. You forget that Views is slow.

To make it even remotely usable, a lot of caching will be needed to make this possible.

So yes, the flexibility is awesome and allows for anything imaginable. *But* either performance will be terrible (poor/not scalable at best) or we will need a lot of caching. Even when caching is added, performance will be worse than using Taxonomy directly.

Just think about the consequences: the root level will be the results of one view. But the child level of each of the items in the root level would be generated by a *different view call* (that is, the same view, but different arguments). And so on for deeper levels.
As you can see, the performance implications are huge. In any case, it'd have to be used with care.

I also didn't have experience with AHAH, or advanced Forms API, or Views, or Taxonomy API …
That doesn't mean you can't learn it ;) :)

Comment #4

Wim Leers

Ghent 🇧🇪🇪🇺

CreditAttribution: Wim Leers commented 28 February 2010 at 09:04

Title:	Broader integration with Views (not just Taxonomy)	» Custom HS implementations: through UI instead of code by (ab)using Views!
Component:	Miscellaneous	» Code
Status:	Active	» Postponed