Working on the port of taxonomy manager for Drupal 8, I realized that the module has the potential to be an excellent example (case study) to show how an "old" technical problem can be handled better with modern tools of today.

Taxonomy manager is a handy tool to do 2 things at the same time:
1) manage hierarchy between taxonomy terms
2) update taxonomy term items on the fly, in the same page

This is a handy way to manage hierarchy in general, because it's centralized and one can stay on 1 page to do everything necessary regarding a given taxonomy vocabulary. Having the terms on the left and their forms on the right seems to solve hierarchy management well in terms of UI. I base on this discussion.

However, I see also 2 important aspects that need to be improved:

  • Lack of drag and drop.
  • Hard to use with touch devices.

Maybe these are not so bad?

My personal feeling is that the power of taxonomy manager is in its interface as such. It deserves to be better, no?

The world of JavaScript has evolved from what we knew it when the initial version of the module was released. There are hundreds (maybe thousands) of JavaScript libraries, frameworks, etc. today. Also, the way people use the browser has changed: touch with drag and drop interaction is a standard, not just a cool thing.

So I'd like to present the idea of choosing a good library to handle these improvements as a next step in the evolution of the project. Taxonomy manager can be kick-ass with the new architecture of Drupal 8.

There are several important updates in core of Drupal 8, bringing new opportunities:

  • OOP
  • Easy way to implement 3rd party libraries
  • REST API
  • New jQuery and JS libraries in general

Having OOP means that instead of having 2 files with all functions, there are separate files with clear separation of logic, which could be independant from the data being managed. (MVC word could be mentioned)

Easier inclusion of 3rd parties. This can be done either by Libraries API, composer, bower, etc. - sharing and reusing JavaScript should be something normal, not something special today.

REST API in core means that all the methods which apply CRUD over taxonomy terms, could be actually handled on a higher level via services. SOA with REST over HTTP is easier to manage, because it's testable easier compared to simpletest (and it's faster btw). Rewriting older code is safer with TDD. Not to say it's obligatory, but could be super-awesome example of how Drupal is evolving to modern web too and it will be technically solid too in the long run.

So here are some first-off ideas for libraries which look good:

The perfect choice will be one with good documentation and API, active community and examples. And also, Drupal implementations if any. For example, I found this humble beginning of fancytree implementation in a Drupal 7 module: https://github.com/kehh/fancytree

I will be happy to hear opinions - feedback is really welcome!

CommentFileSizeAuthor
#10 tm add modal.png250.78 KBmh86
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kalinchernev created an issue. See original summary.

kalinchernev’s picture

kalinchernev CreditAttribution: kalinchernev as a volunteer commented
Title: [Proposal] Use modern JavaScript » Proposal for improving the UI with a modern JS library
mh86’s picture

mh86 CreditAttribution: mh86 at jobiqo - job board technology commented

I absolutely agree we should replace the custom javascript tree implementation with an external library. The current code originates from Drupal 5 (year 2007!) and hasn't changed that much till Drupal 7....

For choosing the right library I have some requirements in addition to API quality, active community, support and documentation:

  • Lazy loading (AJAX) of child terms
  • Multi-selection of terms via checkboxes
  • Drag & Drop support
  • Ability to display two trees on the same page (double tree)
  • Inline editing of term names (not a must have)
  • Highlighting of a specific term when loading the tree (see current behaviour when searching for a term).

Currently I don't have any favourite, from what I can see all your examples fulfil most requirements.

In the meanwhile I started to play a little bit with fancytree and will let you know about my findings.

mh86’s picture

mh86 CreditAttribution: mh86 at jobiqo - job board technology commented

I just pushed a commit to the 8.x branch that does 2 things:

  • Continued with the taxonomy_manager_tree form element so that we can test different JS libraries
  • Added fancytree as test implementation

When you now open the taxonomy manager for a certain vocabulary, you should get a dynamic tree with nested child terms (they are not loaded via ajax yet).

The form element should allows us to do further testing with the fancytree and other libraries.

mh86’s picture

mh86 CreditAttribution: mh86 as a volunteer and at jobiqo - job board technology commented

I've pushed another commit that test the lazy loading functionality via a JSON callback, works fine so far!

kalinchernev’s picture

kalinchernev CreditAttribution: kalinchernev as a volunteer commented

It's a great progress, @mh86! It's exactly what I meant!
I'll get acquainted with the updates, on first sight it seems to me that you have prepared the most important base!

mh86’s picture

mh86 CreditAttribution: mh86 as a volunteer and at jobiqo - job board technology commented

Thanks :)

I've pushed some more updates:

  • Use Javascript settings instead of hard-coded IDs in Javascript code
  • Implemented valueCallback() so that the element properly works with the Form API
  • Implemented a pager for the first hierarchical level

The current implementation is mostly independent of the fancy tree library. I think it would be easy to test other libraries as well, most of them just differ in the JSON structure (also I was thinking about to just use JSON for generating the tree, instead of HTML lists at the beginning, and then the JSON callback for child terms - would make some code obsolete)

So far the fancy tree library has worked well, but this doesn't mean I made any decision on a library yet. Happy to hear your input on this topic.

kalinchernev’s picture

kalinchernev CreditAttribution: kalinchernev as a volunteer commented

Nice! :)

What do you think could be good next steps into testing this particular implementation? I.e. term operations, specific methods in the library, or something else?

mh86’s picture

mh86 CreditAttribution: mh86 as a volunteer and at jobiqo - job board technology commented

Hi Kalin,

I've pushed another feature for the tree element that allows to expand the tree to a certain child term ('#terms_to_expand' property).
I think the tree element now has all features we need. Regarding the fancytree library, I suggest to stick to it as long as we find a good reason to not use it.

Regarding the next possible steps, in my opinion:

  • Find a way to add operations (add, delete, move, ...), without a lot of custom code. Maybe there is something new in core that we could reuse
  • Term edit form (that one that opens on the right side when clicking on a term). Here as well, maybe we can reuse some existing code from core.
  • Add + Add Child terms operation (that seems to be already there)
  • Delete terms operation
  • Move terms operations (I would keep it, even though we are planing to have DND)
  • Export terms
  • Search terms (using the #terms_to_expand property)
  • Select All / Select Child Terms
  • DND

What do you think?

mh86’s picture

mh86 CreditAttribution: mh86 as a volunteer and at jobiqo - job board technology commented
FileSize
tm add modal.png250.78 KB

Hi Kalin,

I continued working on the add / delete operation. I used the new modal dialog AJAX API and I think it fits well for the operations.
Attached a screenshot on how it looks like.

kalinchernev’s picture

kalinchernev CreditAttribution: kalinchernev as a volunteer commented

Hi Matthias,

Sorry for not being able to follow up more frequently recently.

Find a way to add operations (add, delete, move, ...), without a lot of custom code. Maybe there is something new in core that we could reuse

Yes, I briefly looked at the fancytree and seemed there a enough amount of methods to handle the CRUD. I think the way you have organized the communication via JSON-s will mean that the JS events from fancytree will be mapped to controller methods in Drupal with CRUD on a given term as you have already started a controller for the main tree. Maybe the move will be more specific, but the existing implementation of helpers in the module with the recursives in the weight and depth could be reused to make it simple.

Term edit form (that one that opens on the right side when clicking on a term). Here as well, maybe we can reuse some existing code from core.

Indeed, this seems to be "collapsible" element known today in many frameworks. Maybe the core will have some helper classes, I can check the back-end of the core to see some examples.

Add + Add Child terms operation (that seems to be already there)

The modal looks great! :)
However, I've mis-migrated the function which takes care of second and deeper level terms. Only 1st level terms get correctly inserted. So there's need to improve this a bit.

Move terms operations (I would keep it, even though we are planing to have DND)

Agree, the DND is nice to have, yet the update functionality is with priority.

Export terms

This is another feature I'd research in core or symfony libraries. I wouldn't be surprised if we can reuse something new for this too. But it's also that composer is there, so theoretically 3-rd party helpers should be possible maybe.
I created a ticket for myself here https://www.drupal.org/node/2621210 so I will branch out from latest and try to help you with that.

Search terms (using the #terms_to_expand property)

Definitely.

Thanks so much for adopting the idea and progressing so well!

mh86’s picture

mh86 CreditAttribution: mh86 as a volunteer and at jobiqo - job board technology commented

Hi Kalin,

thanks for the response :)
Would be great if we find some time on the DrupalCamp Vienna on Friday or Saturday to discuss/coordinate further tasks.

In the meanwhile I did some further cleanup and fixed the add operation (to assign the right parents). Maybe I also find some time to port the move operation and put it into a modal.

mh86’s picture

mh86 CreditAttribution: mh86 as a volunteer and at jobiqo - job board technology commented
Status: Active » Fixed

Marking this issue as fixed, the fancytree library has been integrated. With the rest we'll continue at #2624396: [Meta] Drupal 8.0+ Roadmap and #2220299: Port to Drupal 8

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.