taxonomy selector needs work

this would be a big help for the UI, definitely. unfortunately, i don't know of an easy way to accomplish this. these form elements are getting added automagically from the taxonomy layer. since it's all 1 taxonomy, i know of no way to split up some of the terms from the multiselect like you're proposing. seems like we either need to:

1) split up the taxonomy itself and make 1 top-level volcabulary for the kind of project, which is required, and non-multi (the radios for module, theme, translation, etc), and have a child taxonomy for modules that includes the kind of module it is (admin, email, events, etc) which can remain an optional multiselect.

2) do some major UI hackery, form_alter() or otherwise remove/hide the existing taxonomy selector, manually put those into the form ourselves, and then somehow stuff our results back into the actual taxonomy interface somehow.

i don't know how serious the implications of #1 would be, and i don't know how to do #2. ;) so, i'm not the right person (at least not now) to work on this issue. if people who know more about this stuff than i do care to comment and either lay out option #3 i'm not thinking of, enlighten me about how to do #2, or explain the implications of #1 and how that won't require massive re-writing of the project module's use of taxonomy, i'd consider working on this. until then, it's staying unassigned. ;)

i've been trying to get input on this in IRC for days. either no one else cares (since they don't realize the pain it's causing) or they don't have any ideas on how to do what i'm asking. :(

i've yet to do much direct coding with taxonomies, so i suspect it'll take me longer than it should to hack up a solution for #2. i'd really like to get dries and/or nedjo's opinions on #1, since i think that'd be cleaner in the end. having just done a fairly complete pass through the project code regarding how it's using this taxonomy (http://drupal.org/node/60627) i don't think it'd be that terrible to just use 2 taxonomies: a required single-select top-level project type (module, translation or theme), and an optional multi-select project category (all the current children terms of "module"). if neither of them comments here soon, i guess i'll start hacking and see how far i get with either/both approach and see what looks better. ;)

-derek

p.s. i've now got a *full* blown illness, so i'm not going to be doing much of anything for the next day or two except sleeping and drinking tea. :(

ok, after a lengthy discussion in IRC with dries and webchick, we came to some conclusions:

a) using 2 taxonomies for this is bad, since the taxonomies are intimately related. conceptually a 2-tier taxonomy hierarchy is the best way to think of this, it's just that the UI for that sucks.

b) the auto-generated taxonomy that project creates should *not* be a required taxonomy.

c) project should produce a custom taxonomy selector form widget with the following properties:

1. only show up if there are any terms in the project taxonomy
2. any top-level terms in the taxonomy should be displayed as a required, single-select (either a drop-down or radios)
3. any 2nd-level terms are displayed as optional, multi-select
4. the widget should validate such that only subterms of the selected top-level term are considered valid options

i think if we did all of this, it would solve this issue, along with http://drupal.org/node/60627 and http://drupal.org/node/49623...

are all parties happy with this approach? i have no idea how hard it'll be to implement. as dries said in IRC: "Dries_: dww: of course, if the implementation turns out to be a nightmare, we could reconsider it"...

i guess i'll start down this road and see how far i can get. stay tuned.

ok, i've got a rough prototype of the UI stuff done. it deals with the form_alter() stuff to rip-out what taxonomy_form_alter() puts in for the auto-generated project taxonomy (which requires a DB update to change the weight of the project module in the system table), and then conditionally constructs the appropriate form elements to put all the top-level terms in a required single-select drop down. if 2nd-level terms exist, it presents all of them in a multi-select (just like now). if no terms exist at all, the whole fieldset goes away. if no terms exist but the admin defined an unrelated taxonomy that applies to project nodes, those show up in all cases. i'll attach a series of screen-shots to see how this all looks. i haven't yet handled the validation and submit side of things, but i figure that'll be pretty easy. just wanted to post the images now so i can get feedback.

so, here's the first: taxonomy.module enabled, and the autogenerated project taxonomy is there, but there are no terms in it, and no other taxonomies apply to project nodes.

if the project taxonomy is empty, but there's another taxonomy that applies to project nodes...

project taxonomy now has terms, but only top-level terms (and the other taxonomy has been disabled)...

project taxonomy now has 2-levels of terms...

2-tier project taxonomy, plus i re-enabled that other, orthogonal taxonomy...

here's another version, with radios for the top-level term, and separate boxes for the sub-categories...

after much hacking (and learning!), i've here's a patch that not only implements the UI from the previous screenshot, the interface actually works. ;) it validates properly, saves the taxonomy terms, etc, etc. if you edit a project, the existing taxonomy terms are correctly pre-selected in the new custom taxonomy UI. if you define other taxonomies that apply to project nodes, those don't get clobbered by any of this code.

that said, i had to jump through some pretty nasty hoops to get this working. it's entirely possible there are better, more elegent ways to accomplish this. but, i tried to be as reasonable as possible, comment the truly bizzare, and tested pretty carefully as i was going along. other than duplicating the 1-line project_use_taxonomy() function from my patch in http://drupal.org/node/60627#comment-101876, this patch doesn't rely on (or conflict with) that other patch at all. however, obviously both of them should go in to truly resolve the problems of projects and taxonomy.

please review, killes will be very happy if this goes into effect on drupal.org... thanks!
-derek

in IRC, chx reviewed this and pointed out that the manual stuff i was doing with $weight is unnecessary. that was a hold-over from when i was trying to get all this custom taxonomy selector stuff to play nicely inside the existing taxonomy-generated "Categories" fieldset. now that i'm safely in my own little world, i don't need to mess with $weight anymore.

also, while i was at it, i noticed a case where i needed to check for the existance of $node->taxonomy before i started using it, so that creating new projects still works without any errors.

in case you're wondering, here's a screenshot from the latest patch... based on wisdom i just got from m3avrck in IRC, i'm going to try another approach to lay out this custom taxonomy selector... stay tuned.

and lo, here's the alternate version. i think i like this one more, all the way around. it's less cluttered, and it's safer in the event of sites that define a lot more top-level terms in the project volcabulary. and it removes the need for that pesky <br class="clear" /> from the previous patch. ;) i'll attach the screenshot here, and the patch that accomplishes it next.

and here's the patch that makes that last screenshot possible.

drat, i noticed a few tab characters snuck in. i fixed a few other minor formatting things, and added a few theme('placeholder', ...) calls to make things look a little better.

I think I like #14 best.

I wonder if we can group things better. Right now there is some vertical grouping (the theme stuff is more or less below each other), but not quite. I wonder if replacing the multi-select menu with checkboxes would be better. We'd be using a combination of radio-buttons and checkboxes, like this:

 (v) Modules
    [v] administration
    [ ] image handling
    [ ] mail
 ( ) Themes
    [ ] PHPTemplate
 ( ) Translations

in principle, i like the idea of grouping them more closely together like you propose. however, in practice, we've currently got on the order or 20 or 30 module categories on drupal.org. so, it'd require nearly a full screen just to have all those checkboxes, and then you'd probably have to scroll down to even notice there are other top-level radios to choose from. if we really were only talking roughly 5 2nd-level terms, this would be better, but i think it'd be worse on drupal.org. yes, people have to scroll through the multi select to find all the possible ways to categorize their module, but i think that's a much more compact UI, the top-level radios are very clear and the first thing you see, and the scrolling for module categories is a lesser evil than the explosion of checkboxes required if we use the radio/checkbox approach.

The project page is already quite lengthy, so I'm not sure that this is a real problem. It would be in a collapsible fieldset, and we could use CSS to squize it down a little. Or you could always do seomthing like this:

 (v) Modules
    [v] administration        [ ] community                [ ] syndication
    [ ] image handling        [ ] file management          [v] taxonomy
    [ ] mail                  [ ] events                   [ ] import/export
 ( ) Themes
    [ ] PHPTemplate
 ( ) Translations

It's just a suggestion. It might be a lot of work to implement. Any improvement is an improvement so feel free to commit other solutions if they help fix the problem at hand. I do think, however, that my proposed scheme would be the ideal solution. Of course, that's just my personal opinion. Feel free to disagree. Maybe ask for other people to comment on this?

commited the patch from #16 to HEAD and DRUPAL-4-7. killes was anxious to get any solution installed on drupal.org ASAP. i don't have time to see how hard dries' alternate UI would be implement, nor do the level of testing i'd need to do before i felt comfortable having killes install it on d.o. so, i commited a known-working solution that seems to be the best of what we've got so far. if folks have better ideas for the UI, by all means, re-open this.

thanks,
-derek

whoops, if you just have 1 level of taxonomy terms, _project_save_taxonomy() would throw a warning about invalid foreach(). i can't believe i missed this while testing. luckily, heine caught it. this patch fixes the bug. planning to commit ASAP, but i figured i'd post the patch for review, just in case.

patch fixes the issue.

fix from #21 applied to HEAD and 4.7.

weird, heine's edit seems to have triggered another instance of http://drupal.org/node/56454. unfortunately, we can't really figure out what exactly happened. there's nothing interesting in the watchdog logs from that time, and nothing particularly out of the ordinary about what he did. :( and now, he can't reproduce it on other issues, either. :( drat! oh well. for the record:

Heine: I sometimes back button out of a partial reply, then forward into it again (opera)
Heine: Continue editing, then submit
Heine: Could that have anything to do with it?
Derek: maybe.
Heine: dww: I remember that the component field was set to none on submit
Heine: dww: so I put it back on UI
Heine: dww: tried again on another issue, no result
Heine: dww: can't reproduce
...

alas.

subscribing