Spinning this off from the core issue so I can have other people follow and review the code.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dave Reid’s picture

Summary:

  1. Adds a 'jquery.treeTable' library which essentially just contains jquery.treeTable.js and jquery.treeTable.css. There were other images included but see #2.
  2. Adds a arrow-right.png so we can re-use our own internal images for the expand/collapse arrows. If this were accepted into core, we would want to add an arrow-left.png and arrow-right.png into the /misc folder.
  3. Adds a token_tree theme element so that it can be used like the following:
      $build['token_tree'] = array(
        '#theme' => 'token_tree',
        '#token_types' => array('node', 'comment'), // Specific token types to include.
        '#global_types' => FALSE, // Whether or not to include global token types like current-user, date, etc.
        '#click_insert' => TRUE, // Make tokens clickable & insert into last focused textfield
        '#recursion_limit' => 2, // Since tokens like comment and taxonomy terms can recurse infinitely, we have to set some kind of limit.
      );
    

Todos:

  1. Officially get the treeTable plugin MIT/GPLv2 dual licensed.
  2. See if Dries wants this patch for core.
  3. Improve documentation.
  4. treeTable also supports a 'selectable' table and need 'light' versions of the arrows for the selected rows. Not sure what we can do for this.

Improvements, comments, etc are completely welcome.

Dave Reid’s picture

I've also uploaded this latest version to http://www.davereid.net/d7/examples/token

Dave Reid’s picture

I've been in contact with the jQuery treeTable author as noted in the other issue and he's up for dual-licensing. I've made an official issue for the plugin at http://plugins.jquery.com/node/13634.

rfay’s picture

Subscribing.

As far as usability, tokens stink in D7 without something like this. Completely unusable. Heretical as it is, it may be worth adding this feature to D7. Of course, those "in the know" will be able to use this from contrib.

arhak’s picture

sub

eaton’s picture

Dave, one note is that D7 no longer has 'global' tokens. Every single token exists in a specific domain, even things like the current site name and slogan. So if someone wants the equivalent of the existing 'global' tokens, they would need to add 'current-date' and 'current-user' and 'site' to the list of token types to retrieve.

Also, to clarify -- I haven't had a chance to look too closely yet, but does the recursion limit affect all chaining? There are a lot of pretty useful tokens like [node:author:created:short] that would run into a 2-deep nesting limit.

Taking a look at the code now. Thanks!

Dave Reid’s picture

I'd actually say that 'current-user', 'date' and 'site' are global tokens since they do not need data and will always work. The #global_tokens is just a TRUE/FALSE to include all possible global token types. User can easily put a FALSE value for that and manually specify the exact token values to be included in the tree.

The recusion limit is defaulted to 4 levels in the path. 2 was just a bad example, but it's over-ridable.

arhak’s picture

#7 +1 for #global_tokens the way you say (the same I thought when first saw it)

OTOH I would recommend a minimum of 5 level as a reasonable depth [comment:node:author:created:short]

Dave Reid’s picture

@arhak: Technically the first part of the token doesn't count towards the recursion limit since it is only a type, and isn't a token that has chains, so that token is possible with a 4-depth limit. :)

arhak’s picture

@#8 thanks for clarification, then I'm ok with 4 (unless another token chain in core would be longer)

eaton’s picture

Dave, just to clarify -- is the reason for the depth limit because the entire tree gets pre-rendered? I've been kicking around the idea of an XML or JSON chunk describing all the token types and their relationships to each other (via the 'type' property) just being passed to the client side, and building the tree there to avoid the overhead. Would that be brutal, do you think?

Dave Reid’s picture

Yes its because the browser I worked up does it all ahead of time. There were other jQuery table/tree type plugins that supported fetching rows via AJAX and the idea was definitely intriguing. Most of the code I wrote should be able to be re-used for that approach. I'm also working on token auto-completion in Token.module as well.

eaton’s picture

Makes sense. Eventually it would be cool to move to that sort of approach, but what you've posted above is also enough of a black box that the public interface to it wouldn't need to change if that approach were used down the line... I'd actually be thumbs-up on committing it to the D7 token branch as is, and treating it as something experimental. Token module in D7 could also form-alter the helper information into the spots in core that use tokens but don't fully explain them...

cubicphuse’s picture

Hi, I'm Ludo van den Boom, the author of the jQuery treeTable plugin. Wanted to let you know that, as of release 2.3.0, the treeTable plugin is now dual-licensed MIT/GPLv2.

Dave Reid’s picture

@cubicphuse: Woo-hoo! Welcome to the Drupal community and YOU ROCK!

Dave Reid’s picture

I'll commit the current implementation to token D7 now.

greggles’s picture

Note that it must be GPLV2 and later to be included in Drupal's cvs repository.

Dave Reid’s picture

Committed the token UI browser to CVS!

Dave Reid’s picture

Status: Active » Fixed

Marking this issue as fixed since its been committed to 7.x and 6.x.

Status: Fixed » Closed (fixed)

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