Closed (fixed)
Project:
Project
Version:
5.x-1.x-dev
Component:
Projects
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
3 Jan 2007 at 18:52 UTC
Updated:
19 Jan 2007 at 07:45 UTC
Jump to comment: Most recent file
thanks to http://drupal.org/node/64221 we've now got a more reasonable UI for the project taxonomy selector, given how the project module treats this particular taxonomy. the top level choices are radio buttons (since there can be only 1), and the 2nd tier choices are each in their own multi-select (since you can have a given module in a few different categories). FAPI validation ensures that we only ever allow 2nd-tier choices that match the selected radio button.
on d.o, this has mostly worked fine, since only one of the project types has any 2nd tier options (modules). however, in http://drupal.org/node/105986 i'm proposing to add "categories" to the translations projects. now, the project node UI is going to be confusing again. see attached screenshot (from scratch.d.o).
what i'd like is to use JS so that depending on the selection for the "Project type" radio buttons, we reveal the appropriate 2nd-tier selector box (if any) and hide all the others. so, if you look at the screen shot, imagine that when you select "Modules", all you see is the "Modules categories:" box, not the "Translations categories:" box, too.
in general, there could be a "foo categories" box for every possible value "foo" in the set of radio buttons. i.e. it's up to the site admin and how they define the taxonomy terms, it's not hard-coded into project.module at all.
hope this makes sense. ;)
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | project.js_2.txt | 1.08 KB | nedjo |
| #4 | project.js_1.txt | 1.09 KB | nedjo |
| #3 | project.js_0.txt | 1.09 KB | nedjo |
| #2 | project.js.txt | 1.03 KB | nedjo |
| #1 | project-hide-taxonomy-select.patch | 637 bytes | nedjo |
Comments
Comment #1
nedjoHere's a quick untested draft. First the one-line patch to add the js file.
Comment #2
nedjoAnd the js file (yes, I know, I should learn how to add this to the patch...)
The logic: We attach a function to the change event of the radio elements where the top-level term is selected. When a radio is clicked (and therefore selected), we iterate through all the taxonomy selects and, if they're not for the selected radio, hide them (or, rather, their containing div elements). Otherwise, we show them (in case they were previously hidden). When the behaviour is first attached, we run the same hiding/showing code to appropriately set the initial state, first determining if any radio is already selected so we can show its select element.
Comment #3
nedjoFixing an error in the previous version.
Comment #4
nedjoAnd fixing another error.
Comment #5
dwwtried it on a local site. the project.js is getting loaded (at least
<script type="text/javascript" src="/drupal-head/modules/project/project.js"></script>is showing up in the HTML source, and that file definitely exists and is readable). however, it doesn't appear to do anything. i toggle the radios, and all the category selectors remain visible.Comment #6
dwwoh, forgot to mention...
THANKS! ;)
i hope it's not to hard to get this working, it'll be really slick if so...
however, when i wrote this up, i was asking hunmonk about it. as we started discussing it, he convinced himself he hates the whole UI, and wants to convert it into a multi-page form, with edit links and other weirdness. ;) he keeps threatening to followup in here with his thoughts. he claimed he'd only work on the JS implementation if all his other schemes didn't pan out...
but, if it's only a few minutes of testing/work, i'd still love to at least get the JS version working and committed, so we can have something to tide us over until hunmonk's major overhaul.
thanks again,
-derek
Comment #7
nedjoThis time I actually tested it (novel concept, I know) and fixed a couple more errors. Seems to be working:
* at node/add/project_project, 2nd level terms are at first hidden
* when term with subterms is selected (e.g., modules), its subterms are shown
* when new term is selected, the previous subterms are first unset (to avoid bad data) and then hidden, and the new terms subterms, if any, shown
* when we edit an existing project, its subterms (if any) are visible on load.
I agree, though, that a multi-part form is probably ultimately the way to go.
Comment #8
dwwi'll take a look at this asap. thanks!
Comment #9
dwwlooks great to me. works fine on my local 5.x project test site.
nedjo, care to commit this one yourself? ;) HEAD please.
(i'll gladly do it myself, i'm not trying to pawn off work, i'm just thinking for cvs-blame purposes, and since you're already a project committer, etc...)
thanks much!
-derek
Comment #10
nedjoApplied to HEAD.
Comment #11
(not verified) commented