That´s a summary of http://drupal.org/node/388486
The new module will be accessible under admin/build/taxonomy_menu or admin/content/taxonomy_menu.
| List menu groups | Add menu group | Settings | Help
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
| "menu group name" - preview - edit - delete -
|
| - build menu link - update menu link - remove menu link -
|
| status: published / unpublished / needs to be updated
|
| requires view: path="path name"/%" argument: Term ID
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|"vocabulary name" - edit - delete -
|
|- add vocabulary/term
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Functions:
List menu group: Lists all excisting menu groups
Add menu group: Adds a new menu group (There can be many which allows users to have same vocabulary in different menus with different options enabled.)
Settings
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select maximal number of terms of a section showed within vocabulary/term edit screen.
(vocabularies with some hundred items would make editing very difficult)
Pull down select
..10
..20
..50
.....
..unlimited
(If a taxonomy section has more than the given number of terms, only the given number
will be displayed and a ..more.. item - the rest can´t be selected term by term.
See add/edit of vocabulary)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Help
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| (Help text with examples. VERY IMPORTANT)
|
|
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Edit/add Menu Group
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Menu group name: ...
Menu: (drop down window)
(should be possible, to chose an excisting menu item as parent)
Path type:(drop down window)
..Default: taxonomy/term/tid
..Custom 1: "path name"/tid arguments: tid
..Custom 2: "path name"/vid/tid arguments: vid tid
..Hierarchical 1: "path name"/vid/tid/tid... arguments: vid tid tid tid ..
..Hierarchical 2: "path name"/tid/tid... arguments: tid tid tid ..
..other ?
Argument type: term id / term name
Custom path name: ....
Display Depth on lowest level for custom and hierarchy: ... (Views argument Depth Modifier)
Display Descendants: yes/no
Display Number of Nodes: yes/no
Hide Empty Terms: yes/no
Auto Expand Menu Item: yes/no
Display Descendants: yes/no
(The former "synchronise changes function" will be part of the selection of terms)
Save/Delete
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Add/edit vocabulary
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(In 3.0 only one vocabulary per menu group! Later we can extend that.)
Select vocabulary: (Drop down select)
--Apply
[For edit screen see the enclosed zip/rtf-file.]
Save/Delete
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Open questions:
- Will the numbers of hierarchy levels be limited within the vocab/terms edit screen? Depends on programming.
- What happens, if users change hierarchy within a used vocabulary? This could interfere with the concept of branches and sections.
- Could multiple languages be supported by using a selection "language" for each Menu Group?
:-) So much so far. Hope it all makes sense.
KSC
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | Term Set Form | 43.59 KB | indytechcook |
| #18 | Term Set List | 38.01 KB | indytechcook |
| #18 | Path Options change based upon path selection | 28.72 KB | indytechcook |
| #18 | Bottom of Menu Group Form | 44.01 KB | indytechcook |
| #18 | Top of The Menu Group Add Form | 50.91 KB | indytechcook |
Comments
Comment #1
indytechcook commentedOK. I finished the interface for managing the menu groups and menu group items. Since when I started, we talked about selecting a parent term for the menu item I stayed with that concept.
I had to rewrite how the options were pulled and saved since they were moved from a variable to the database. Now the options are per group, item or path.
I'll post screenshot tonight.
Comment #2
indytechcook commentedI thought it was complete, until I went back and reread the old thread. I forgot the concept of "Were to put the terms?"
Comment #3
indytechcook commentedTo make sure I understand the Menu Group/Branch/Section concepts...
Menu Group is the item as a whole. Most of the time there will probably be only one menu group.
Sections: Group of terms. Sections have can have a heirarchy structure.
Branches are the branch of the menu. These are created based upon how you build the sections.
Using the example from before:
Clothes&Accessories (vocabulary)
- Clothes
- - Men
- - - T-Shirts
- - - Trowsers
- - - Pullovers
- - Women
- - - T-Shirts
- - - Trowsers
- - - Pullovers
- - Children
- - - T-Shirts
- Accessories
- - Bags
- - Various
Properties (vocabulary)
- size
- - woman
- - - xs
- - - s
- - - m
- - men
- - - m
- - - l
- - - xl
- color
- - blue
- - green
- - white
- style
- - sleeves
- - - Long sleeves
- - - Short sleeves
To create this Menu:
The menu should look like this:
Latest Fashion T-Shirts
- T-Shirts Men
- - Long sleeves
- - - blue
- - - green
- - - white
- - Short sleeves
- - - blue
- - - green
- - - white
- T-Shirts Women
- - blue
- - green
- - white
Build:
Menu Group: Latest Fashion T-Shirts
-Section: T-Shirts Men (use section name/Display parent Item options selected)
--Vocab: Clothes&Accessories
--Parent Term: Clothes->Men->T-Shirts
--Where to Place Section: Menu Group: Latest Fashion T-Shirts
-Section: T-Shirts Women (use section name/Display parent Item options selected)
--Vocab: Clothes&Accessories
--Parent Term: Clothes->Women ->T-Shirts
--Where to Place Section: Menu Group: Latest Fashion T-Shirts
-Section: Sleeve Style (option to display section name/parent item disabled)
--Vocab: Properties
--Parent Term: style->sleeves
--Where to place Section: Section: T-Shirts Men
-Section: Colors (option to display section name/parent item disabled)
-Vocab: Properties
--Parent Term: color
--Where to place Section: Sections Sleeve Style AND T-Shirts Women
This makes sense to me, but is it to complicated?
Comment #4
ksc commented1) At the beginning we should set the limit to one Vocabulary per Menu Group .
More than one V has a lot of complicate implications to it:
p.e. http://drupal.org/node/388486#comment-1365538 and others.
The use of more than one Vocabulary within one Menu Group could come in a second or third step.
Till then users could do the same thing using exposed filters in VIEWS for most cases.
2) So what are the advantages using just one vocabulary? The most important are:
a) One can have more than one menu per vocabulary - many times requested
b) One can built a menu group from a part of a vocabulary - many times requested.
c) Some others
3) Your questions
Yes. And its name can be the top level item of the menu.
No. There´ll be many. Like people have many views.
In your example above, there could be one Menu Group for "Clothes Woman" (that might show up in a different block which is pink and shows number of nodes) and one "Clothes Man" (block is blue :-) which doesn´t show number of nodes)
Or in my case I have "Downloads", "Interesting Stuff", "Blackboard: Sell and By", "Events", ...
So the options like "Number of nodes", "Display Descendants" and excist per Menu Group!
Noyes. ... how to explane?
I thought quite a while about how users could select which terms of a vocabulary should be used within or be part of a Menu Group. So I came up with the idea of sections and branches (there is a third thing called "Lineage" which is not relevant now. It means: all parantal terms to a given term).
A section contains all terms of a hierarchy level with the same parental item.
If one has only a few terms in a level one could select item by item. Sections make sense if users have twenty, fifty or more of terms in one level. That makes it easier to select all terms.
And: If one adds a new term to a section by TAXONOMY, TAXONOMY MENU has to decide wether the new term should be part of the Menu Group or not. For that we need to have the function: "Syncronise changes within this section to this Menu Group".
Naturally items from one section can have subordinated terms that also can get selected - by single item or by branch (but not by selection of the section) OR we have another option: Select a section with all branches.
If one selects a branch all subordinated items get selected (all lower sections).
Basically there are two ways to use levels, sections and branches for selecting and building up a Menu Group.
THE NON RECURSIVE WAY
Everything happens within one selection frame - items/sections/branches can be selected or unchecked, the result can be shown in the preview.
Expamples:
Clothes&Accessories (vocabulary)
- Clothes
- - Men
- - - T-Shirts
- - - Trowsers
- - - Pullovers
- - Women
- - - T-Shirts
- - - Trowsers
- - - Pullovers
- - Children
- - - T-Shirts
- Accessories
- - Bags
- - Various
I) Selecting Clothes&Accessories - Branch: everything get selected. Finished.
II) Selecting Woman - Branch
- - Women
- - - T-Shirts
- - - Trowsers
- - - Pullovers
III) Selecting Woman (or Men or Children) - Section
- - Men
- - Women
- - Children
IV) To get a Menu Group like
- Clothes
- - Women
- - - T-Shirts
- - - Trowsers
- - - Pullovers
Select Clothes - Single select
Select Woman - Branch
or
Select Clothes - branch
Uncheck Men - Branch
Uncheck Children - Branch
V)
Clothes&Accessories (vocabulary)
- Clothes
- - Men
- - - T-Shirts
- - - Trowsers
- - - Pullovers
- - Women
- - Children
Select Clothes - single
Select Men - section
Select Men - branch
VI) Maybe that we need to add the choice to select a whole hierarchy level.
THE RECURSIVE WAY -OR- THE WHERE TO GO CONCEPT>/u>
That was the first idea I came up in Basic Considerations....
The Menu Group gets built up step by step in a recursive process. Like your example above.
One could select a term, a section or a branch and chose where it goes to within the Menu Group.
The program needs to make sure, that the hierarchy and order of the Vocabulary can´t be changed. (Very important!)
So one has to start with the highest level term that should be in the Menu Group and then work down level by level / section by section. To leave out terms within one lineage would be ok.
Example:
Clothes&Accessories (vocabulary)
- - Men
- - - T-Shirts
- - - Trowsers
- - - Pullovers
(Clothes is missing)
To have options (like Number of nodes) for each step makes it too compicate and is not needed.
We also don´t need to have names for each section.
But we need to define if new terms within a section or new terms under a lowest level section should be updated automatically.
Buts:
You need to have a procedure to delete terms, sections, branches that are already attached to the Menu Group.
With the non-recursive version the enabling and disabling of terms would be in one "frame".
-------------------
Basically both ways are ok - I think.
------------------
When you have setup this part of UI - we need to play around a bit to find out, what exactly should happen when unchecking single, section or branch to the upper and lower levels. I´m not sure if everything makes sense that I wrote in the attached rtf-file.
--------
What do you think about the concept?
Which way do you prefer?
(uuf - this was a long one. I´m still struggling with ddblocks - already got some nice results. It has a lot of documentation but some of it confuses me. I want to have a slide show of site members with picture and name within a block which shows randomly every some seconds another member with fading effect. )
Comment #5
indytechcook commentedI know see what your concept is for the branches/sections. Your examples cleared up a lot.
***********************
- THE NON RECURSIVE WAY -
***********************
I like this concept. It seems very simple to use but I worry about how customizable it could be. Especially if we get into cross vocabularies in the future. The UI would need to be a bit simpler. I think the interface would become cluttered if all of the terms and all of the available options were available.
An "Add Group Item" with a select for the ("Branch/section") and one for the term. Then below it a table will appear with the terms. What displays depends on what type is selected. Then you can uncheck an term if you don't want it as you mentioned above.
Add Group Item
Type: - Parent Term: - Select (button)
Table appears (similar to your RTF)
Most options would be per menu group.
- path type
- display number
- hide empty
- etc
Would we want options per branch or section? I already have it built into the API. They would display as columns in the table. These would really be checkboxes only.
- display descendants
- auto expand
******************
- THE RECURSIVE WAY -
******************
This is more complicated to build the menu
.
There isn't a way to stop this. They can manually change the order in the taxonomy module or the menu module. But the menu it built upon the relationship to the parent term. So if a term is moved from the parent it is then removed from that part of the menu (and possible moved to another part of the men). This is already done in the current version.
I can see this being an "advanced settings" rather the core build.
*************************
- NON RECURSIVE with HIERARCHY MENU GROUPS-
*************************
Use the recursive method the build the menu group. Then have an "advanced settings" area where you can relate menu groups to each other. This would satisfy your example form this comment: http://drupal.org/node/388486#comment-1361286
This functionality could come later. I saw let's use the non-recursive method first, then add the we can add the hierarchy later.
Comment #6
ksc commentedI agree.
My basic idea was, that most options are per Menu Group. Only "Synchronise changes" per branch or per section. (But I bet a 100 Rupies that after sometime somebody writes a feature request to have all options for each single term.)
Why not go with the following idea:
(Before I explain that, I need to change a term I suggested in the original issue otherwise it gets confusing. We have the function "add vocabulary/term". A better name is "Add Term Set" because we actually don´t add a vocabulary but a set of terms out of one vocabulary - I´m going to write a glossary to have all definitions in one file).
So my idea is:
The common options like "Display Descendant"/"Number of Nodes" are per "Term Set"
Also a refined version of "Synchronize changes" can be per Term Set, so we don´t need to have column 2 and 4 of my UI in the attached file (I´ll explain that in a later comment).
Maybe that the path options have to be defined per Menu Group.
After a user has created the Menu Group, he starts adding a Term Set.
The UI will be similar to the table of the attached file.
After the Term Set is complete, one gets to the editing window "Edit Options".
The suggested display:
|"vocabulary name" - edit - delete -
becomes:
|"Term Set Number" - "Vocabulary" - edit structure - edit options - delete term set -
In the next version than (or even within this version) a Menu Group can have multiple Term Sets.
Like
| "Term Set 1" - "Clothes&Accessories" - edit structure - edit options - delete term set -
|
| "Term Set 2" - "Clothes&Accessories" - edit structure - edit options - delete term set -
|
| "Term Set 3" - "Properties" - edit structure - edit options - delete term set -
|
| "Term Set 3" - "Properties" - edit structure - edit options - delete term set -
|
A kind of hierarchical connection between Menu Groups already exists within our new concept.
The choice to put the Menu Group under an excisting menu item will allow connections between Menu Groups. After the first Menu Group is setup, the second could be linked to a menu item the first group has created.
When we have multiple Term Sets per Menu Group it might not be needed to include a HIERARCHY MENU GROUPS function.
After the first Set is complete users can add another set (with terms from the same or from other vocabularies). They can have options for each Term Set - and decide how the new Term Set should be linked to the excisting one and what logical relationship it has to it parental items from the other set.
Logical AND / OR Relationship
Or means: path will be taxonomy/term/%1+%2+%3
AND means: path will be (partly?) taxonomy/term/%1,%2,%3
(VIEWS/argument: Allow multiple terms per argument. If selected, users can enter multiple arguments in the form of 1+2+3 (for OR) or 1,2,3 (for AND).)
The UI for the second, third a.s.o. Term Set can be the same as for the first.
Just the part where it should linked to will be different and will have some options.
---------
I think this version gives a lot of freedom to create various menu structures and it is not more complicated than the TM2 version if people just want to have on Term Set. Which is enough for 90% of all cases I guess.
---------
Neil, what do you think?
Comment #7
ksc commentedRead last comment first, please
Changes according to my last suggestions: (so everything is in one comment)
| List menu groups | Add menu group | Settings | Help
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
| "menu group name" - preview - edit - delete -
|
| - build menu link - update menu link - remove menu link -
|
| status: published / unpublished / needs to be updated
|
| requires view: path="path name"/%" argument: Term ID
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|"Term Set 1" - "Vocabulary" - edit structure - edit options - delete term set -
|
|"Term Set 2" - "Vocabulary" - edit structure - edit options - delete term set -
|
|- add Term Set
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Functions:
LIST MENU GROUP: Lists all excisting menu groups
ADD MENU GROUP: Adds a new menu group (There can be many which allows users to have same vocabulary in different menus with different options enabled.)
SETTINGS
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select maximal number of terms of a section showed within vocabulary/term edit screen.
(vocabularies with some hundred items would make editing very difficult)
Pull down select
..10
..20
..50
.....
..unlimited
(If a taxonomy section has more than the given number of terms, only the given number
will be displayed and a ..more.. item - the rest can´t be selected term by term.
See add/edit of vocabulary)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HELP
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| (Help texts with examples and glossary. VERY IMPORTANT)
|
|
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
EDIT/ADD MENU GROUP
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Menu group name: ...
Menu: (drop down window) (Should be possible, to chose an excisting menu item as parent)
Path type:(drop down window)
..Default: taxonomy/term/tid
..Custom 1: "path name"/tid arguments: tid
..Custom 2: "path name"/vid/tid arguments: vid tid
..Hierarchical 1: "path name"/vid/tid/tid... arguments: vid tid tid tid ..
..Hierarchical 2: "path name"/tid/tid... arguments: tid tid tid ..
..other ?
Argument type: term id / term name
Custom or hierarchy path name: ....
Display Depth: ... (Views argument Depth Modifier)
Save / Delete
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TERM SET: ADD/EDIT STRUCTURE
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select vocabulary: (Drop down select)
--Apply
[For edit screen see the enclosed zip/rtf-file.]
Save/Delete
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TERM SET: EDIT OPTIONS
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Display Descendants: yes/no
Display Number of Nodes: yes/no
Hide Empty Terms: yes/no
Auto Expand Menu Item: yes/no
Automatically synchronisation: select new terms within all sections
Automatically synchronisation: select new terms under lowest level
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Neil, when you chose to use UI Term Set selection version A or B (attached filed) you could set it up in way, that it could be used later as a widget for assigning Taxonomy terms to nodes.
I prefer Version B.
I´m curious how you like the new Term Set UI.
:-) Klaus
Comment #8
ksc commentedanother version of Term Set UI
update-3 29th of april: another version of Term Set UI
Comment #9
indytechcook commentedI like the idea of term sets. I think this will satisfy simplicity with customization. I'll continue the coding!
The tree interface will take a while to code. Also to get the correct checkboxes selected when you choose certain options will require javascript (which I am still learning) but I think it's worth it to have a good UI.
Comment #10
ksc commentedSo why not start with the simplest way - just the tree structure and checkboxes for single items - means everything that can be done without javascript. Maybe with an option to select all terms underneath vocabulary. And let´s setup the whole thing like this to see how it works.
You don´t have to invent everything from the scratch, CONTENT TAXONOMY has a tree widget that would work - I mean maybe you could make use of the code. It comes as an own module with CT. See attached jpg.
All functions according to comment #7.
Then, in a 2nd step, add the javascipt option (module extension) for selecting branches, sections and so on.
Comment #11
ksc commentedI forgot to attach the file
Comment #12
webel commentedAm very interested in ability to handle terms with multiple parents, whereby the term should appear under all of its parents.
Comment #13
indytechcook commentedHello again. Believe it or not, I'm almost complete with this part of the code that builds the structure of the menu. :)
I would like a little discussion around how the URL should be formatted. I really want to keep the API to add paths programmaticly. I think if we give more options how which type of path is used in different place it would solve most peoples needs.
I think the path type should be a the term set level.
Comment #14
webel commented@indytechcook
Have been busy with other things, not ignoring your efforts.
Long term will be able to help with testing on real system. But not in next days.
Comment #15
arlinsandbulte commented@indytechcook
@ksc
Wow, looks like 3.0 is EXACTLY what I am wishing for! (namely, the ability to use a taxonomy vocab in more than one menu)
What is the status?
I might be interested in funding this work...
Comment #16
indytechcook commented@arlinsandbulte. I have the UI close. still a few bugs before I commited anything.
The real hold up is my time. I really want to get a very first (and probably buggy) release so others can start patching.
If your funding interest is real, please drop me a line on the contact form. I can make it a priority :)
Comment #17
arlinsandbulte commented- deleted -
Comment #18
indytechcook commentedScreentshots for new UI. A few things to finish and I will release the UI.
Comment #19
arlinsandbulte commentedWay COOL!!!! :-) really looking forward to a UI release to play with.
A few questions/suggestions:
At the bottom of the Menu Group List, there is a link "Add a Term Set". Does this 'associate' a term set to the above menu group? Does it create a new term set? Either way, it seems reduntant to me. This can be done either in the Menu Group add/edit form OR the Term Set add/edit form.
On the Menu Group add/edit form, should the associated Term Sets list have some sort of weight so they can be re-ordered? For instance, maybe we want 'Term Set 2' before 'Term Set 1' in the "Bottom of Menu Group Form" screenshot above. Alternatively, you might just delete the Associated Term Sets and then add them back in the preferred order for now.
So 'Select Terms' section in the Term Set add/edit form is to exclude or include only certain terms from the vocabulary, right?
Is the default to INCLUDE each term? Are new terms included by default? (if a term is added to a vocab after the Term Set has been created).
I have some other ideas on how this might work, but first I should make sure I understand what exactly the checks are doing....
Comment #20
indytechcook commentedYou are pointing out some of the reasons why this has taken so long. I went back and forth several times, reading and rereading this an the previous post about the design before settling on the term set/menu group concept.
I'm not sure what it's going to do yet :) Currently it adds a new term setup but I don't think it should be there at all. Doesn't really make sense from a workflow prospective. That screen was made a long time ago ;)
The order of the term sets is EXTREMELY important. When you associate the the term set to the menu group you select the parent term. So "where do you want to put this term at." The drop down is dependent of what term sets are currently assigned. The drop down is the current menu structure built by the terms in the current term sets. Reordering or removing the term sets could cause unexpected results (all hell would break loose). There needs to be a remove button, but it needs to have some validation against it. Like if one if it's terms is the parent of another term set, it would tell you that and not let you remove the term set.
Here is the intended work flow (from comment 3 above). Ksc and I struggle with having multiple vocabs per menu group but I think it vitial, especially for ubercart. :
Clothes&Accessories (vocabulary)
- Clothes
- - Men
- - - T-Shirts
- - - Trowsers
- - - Pullovers
- - Women
- - - T-Shirts
- - - Trowsers
- - - Pullovers
- - Children
- - - T-Shirts
- Accessories
- - Bags
- - Various
Properties (vocabulary)
- size
- - woman
- - - xs
- - - s
- - - m
- - men
- - - m
- - - l
- - - xl
- color
- - blue
- - green
- - white
- style
- - sleeves
- - - Long sleeves
- - - Short sleeves
To create this Menu:
The menu should look like this:
Latest Fashion T-Shirts
- T-Shirts Men
- - Long sleeves
- - - blue
- - - green
- - - white
- - Short sleeves
- - - blue
- - - green
- - - white
- T-Shirts Women
- - blue
- - green
- - white
Build:
Menu Group: Latest Fashion T-Shirts
-Term Set: T-Shirts Men (use section name/Display parent Item options selected)
--Vocab: Clothes&Accessories
--Parent Term: Clothes->Men->T-Shirts
--Where to Place Section: Menu Group: Latest Fashion T-Shirts
-Term Set: T-Shirts Women (use section name/Display parent Item options selected)
--Vocab: Clothes&Accessories
--Parent Term: Clothes->Women ->T-Shirts
--Where to Place Section: Menu Group: Latest Fashion T-Shirts
-Term Set: Sleeve Style (option to display section name/parent item disabled)
--Vocab: Properties
--Parent Term: style->sleeves
--Where to place Section: Section: T-Shirts Men
-Term Set: Colors (option to display section name/parent item disabled)
-Vocab: Properties
--Parent Term: color
--Where to place Section: Sections Sleeve Style AND T-Shirts Women
As far as UI changes, I can see have the term set build on the menu group build page. Maybe.
Include
The update is very complicated. I think we should use ksc's ideas about branch/section/Lineage to keep the menu updated. I was planning on making changes to the API to allow custom syncing functions. Similar to the path API. There would need to be validation to allow certain syncing functions for term settings. The syncing function would be per term set.
Comment #21
indytechcook commentedAlso. The absolute bleeding edge can be found here: http://bitbucket.org/indytechcook/taxonomy-menu/
The UI is mostly working. There are a few bugs you can see in the issues queue. http://bitbucket.org/indytechcook/taxonomy-menu/issues/?status=new&statu.... If you have a suggestion or comment please post an issue there :)
Cheers,
Neil
Comment #22
indytechcook commentedScreencast of new UI: http://code-dreamers.com/taxonomy_menu_ui.mov
First Release: http://drupal.org/node/671132
This release has a fully working UI. It just doesn't create a menu yet :)
I soon will be created a wiki page in the taxonomy group that give instructions and the plan.
Comment #23
indytechcook commentedSetting to closed with the new release.