New module: Hierarchical Select
Almost 3 weeks two months ago now, I have released the Hierarchical Select module. (This post was originally written during the DrupalCon, but time has been sparse since then and bugs were there, which is why I’m posting this so late.) It defines a new form element: hierarchical_select. It makes the selection of something in a hierarchy much more usable. By default, selects of the taxonomy module (on node forms) are forced to use hierarchical selects - if the vocabulary is hierarchical. The same is applied to content_taxonomy CCK fields, when the select widget is used.
Note that the hierarchical select form element does not support the selection of multiple items. And obviously, it only selects the “deepest” item.
I’ll immediately skip to the demo, because a live demo says so much more than words.
And it has an API!
This part is only interesting to people who want to make use of this form element for other modules than taxonomy.
The module comes with an API, so that any module that manages some sort of hierarchy, can define a rendering function that will be used to render the hierarchical selects. It can’t be done completely automagically, because it varies greatly from case to case what input data is necessary to generate the necessary tree structure.
For example: taxonomy needs a vocabulary id and the id of the currently selected term (term id). Another module may only require one id, while another may require 3 ids. You will always get the id of the newly selected item in any of the selects back (which is the term id in the case of taxonomy).
hook_hierarchical_select_render($hsid, $selection, $params)-
$hsid: hierarchical select id, will just be used as a unique identifier in the HTML$selection: the value of the item that was selected by the user$params: an array of parameters that are passed around, these are considered “static”, e.g. the vocabulary id
You can look at modules/taxonomy.inc for an example implementation. See API.txt for details.
Future: Drupal 6 and CCK 2
There’s room for improvements in the API. But that’ll be for a second version, which will be Drupal 6 only, because of the interesting change in CCK 2: CCK widgets will simply be FAPI form elements. That means that we’ll be able to use the hierarchical select form element for several CCK fields!
Comments
demo link
The demo link is broken. You got us all curious and now we don’t get a demo. cry
Fixed!
I had noticed it already. It’s fixed :)
Awesome!
Very cool selection method! Definately beats CCK Taxonomy Super Select Ultra!
Fine, really needed for a
Fine, really needed for a while. Thanks!
Breaks in Konqueror :-)
Wim, that’s totally awesome! I can’t wait to see this become a normal formatter in Drupal 6.
Just one problem, though. I tried it in Konqueror, and it locked up with the “script is running too long” error, then crashed the browser window. :-(
Bah.
Bah.
Considering the amount of problems Konqueror has with Javascript, I won’t even bother to fix it. I don’t think I’m nearly knowledgeable enough to do it either :P And by the way, it may not be an issue of the module’s Javascript, but of jQuery Interface, on which it relies for the horizontal slide effects.
Really nice; Drupal needed this better interface!
I hope you are leading us to the promised land of CCK implementations that can use taxonomy, but are focused for a given purpose to provide a vastly better user interface. Single-select hierarchy is a common need and this does a great job of it– because it is focused.
I’m also glad to see you pointing to taxonomy as the natural way to do locations. It just seems so… right! I’ve created a module that uses a hierarchical vocabulary to do location (place_taxonomy). Due to the needs of the World Social Forum 2008 it takes user input, rather than drop-down select boxes, but it also uses autocomplete.
http://dev.wsf2008.net/ (I will be breaking this site repeatedly over the next few days!)
With taxonomy_location latitude, longitude and radius – to give an idea of a zoom – can be added to taxonomy terms. None of this stuff is released yet, and interest will determine if it can become something generally useful and supported.
I had hoped to make a CCK version of it, and now thanks to Wim Leers I know it can be done and how it should be done! (And, for pre-defined vocabularies, use this API!)
Now, you are only associating the last term selected with the node, or can you associate all of them? And which do people think makes more sense?
Thoughts welcome (from all sides) on the places as vocabulary idea, and the future of location in Drupal. http://agaricdesign.com/project/wsf_action
content_taxonomy
The content_taxonomy module offers taxonomy in CCK and is already supported by Hierarchical Select ;) That’s because Hierarchical Select operates at a different level: it doesn’t provide a new CCK widget, but
hook_form_alter()s the#typeof the form items.I’m indeed only marking the last term selected (i.e. the deepest term) as the “real selection” that is being passed through. In my opinion, this makes most sense. But I’ve had 2 issues in the issue queue already so far asking why it didn’t work the other way around, so I’ve updated the module description to stress that that is not the way this implementation works. Both have their merits, but I’m not sure how you could clearly make a distinction between the two.
I’m not sure “locations by taxonomy” is the future. Locations have their specific needs (they may be linked to their coordinates, to the language spoken there, to the climate, the country it lies in, etc.), which taxonomy’s vocabularies and terms generally don’t have. Of course, you could build upon taxonomy (which seems to be what you’re doing), but I’m just not sure that’s the right way to go. The reason I used locations as an example, is because it’s a recurring example and in most cases, a simple taxonomy term is sufficient (no coordinates/Google Maps integration required).
And it needs 100KB of JS?
And it needs 100KB of JS? I’d prefer something less gimmicky and lightweight.
jQuery Interface
jQuery Interface is pretty big, yes (almost 80 KB). The JS for Hierarchical Itself is only 3.6K though. But remember that this is cached client-side. If you don’t want anything that’s 100 KB big, then you could as well rule out images…
On a slower connection 100KB
On a slower connection 100KB (including JQuery + Interface) can take a long time to load, and it’s a lot of code for such a simple task. What happens when Interface isn’t loaded? I’d be happy (prefer) to use this module without any animation at all.
That could be offered as an
That could be offered as an option.
But still it doesn’t make much sense why you would not want 100 KB of JS, but could live with hundreds of KBs of images. Several modules take advantage of Interface…
It's important to keep file
It’s important to keep file size down to a minimum where possible whether or not there’s oversized images and other media being loaded. It all adds up in the end.
And sure, if you need the JS for other effects then turn on Interface, there definitely needs to be an option for a light-weight version though.
Opera
looks a little bit strange in Opera, but what is really good is the fact that it still produces meaningful output with Javascript OFF - yes, you ajax believers you must see that it is important to have your site working without javascript! not doing so is insulting handicapped people!
Opera compatibility
I hadn’t tested in Opera yet. You’re right, it’s messed up there. But since it works fine in Firefox, IE6, IE7 and Safari, I don’t think I’m going to spend much time on this. Patches are welcome, of course.
Multiple Select
Heya,
I love love love your automagical Hierarchical Select module.
Quick question for those of you who actually understand making modules et all far better than I.
Is it at all possible to have the Hierarchical Select function support multiple selections? So far, my mind is telling me probably not, but but but…what is it was the deepest term level? Could it then allow for a multiple selection of terms?
I am working on a totally drupaled school portal and numerous school websites that it will feed into - we are having issues displaying taxonomy for users to select from when submitting articles and events etc.
We thought your lovely module was the answer to our dreams (from a usability standpoint as it clears up all the clutter and only shows the user what they want)…but our final selection term on all our major vocabs is Grade Level. This needs to support a multiple selection.
We are as yet unable to solve our taxonomy issues without messing up our breadcrumbs or autopath…having a freaky url I can handle…but nonsensical breadcrumbs is never gunna get me any loving.
Any thoughts on multiple select with your lovely module? If there is any possibility of it being feasible, please let me know…
…if there is no chance then i will go throw something out the window and then get back to trying to sort out our taxonomy display issues..ugh…fun fun
cheers!
Ilsa~
True multiple select
Multiple select is supported, but in the sense of “term lineage” (i.e. save the term and all its ancestors). True multiple select is not yet implemented. Several people have shown interest to sponsor this feature though, so let me know if you’re interested in that as well.
I tested this with the
I tested this with the traditional taxonomy module and it works, but does it work with the Category module?
Probably
I believe the Category module has the ability to synchronize with the Taxonomy module? If so, then it probably works. But you’ll have to keep the Taxonomy module enabled, of course.
Alternatively, you could implement the necessary hooks to add support for the Category module natively.