Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.The attached code exposes the 'count' statistics as tokens.
Why should we provide tokens?
- Workflow-ng uses tokens (e.g. you can check whether "[bookmark-spam-count]" is greater than "5" and then carry out some action, say unpublish the node).
- It's one of the building blocks for implemeneting another feature request, show how many users bookmarked [...].
- Make it possible to use this information wherever tokens can be used.
For the filename I use the `views_bookmark . module_name . inc` convention.
We can either include_once() this file from the main file. Or we can turn in into a mini-module.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | views_bookmark.token_.inc_.txt | 1.18 KB | mooffie |
Comments
Comment #1
mooffie commentedHere's the file.
Comment #2
quicksketchLooks good to me Moofie. With the shortness of this code, I'd be tempted to just include it in the module itself. However, since I know your *ultimate* goal is workflow_ng support, I'd say breaking it out is a good thing. For consistency the views support should probably be broken out also, and workflow_ng can be a separate file also.
Crell informed me that Views 2 can do "magic" loading in Drupal 6, so views_bookmark.views.inc would be picked up automatically.
Implementation looks good.
Comment #3
quicksketchOkay I'm coming back to this because I don't want to add token support without thinking it all the way through. Once we've defined our tokens, they'll be nearly impossible to changes without breaking a lot of sites.
So... what I'm concerned about is including both a $vbid and $title tokens that do exactly the same thing. I know why you'd want to use one versus the other (readability versus being able to change the title later). But most of the time when you're setting up a site, you don't know if you're going to want to change a views bookmark title or not.
I propose using just the $title token for the time being. The reason being it's much more readable that the $vbid version (even though that's not likely to change). If we include both tokens, then the site administrator would definitely need to check for $title tokens anyway (assuming there was more than one site administrator that was using the tokens).
What do you think moofie?
Comment #4
mooffie commentedNate, thanks for the in-depth review.
This "$title vs $vbid" dilema is a grand one. Both kinds of tokens have drawbacks. So we're in a danger of never settling this issue ;-)
Since future-compatibility is an important principle for you, let's support only $vbid tokens for the time being. It's easier, psychologically, to obligate ourselves to $vbid tokens, for "the rest of this module's days", than to $title tokens, because the latter --from a software-design perspective-- are somewhat ugly.
$vbid tokens have one major drawback: they aren't portable. On my local development machine I'd have different IDs than on the live site. Ironically, $title token are more portable.
BTW, the Token module has a nice feature: it allows us to support tokens without listing them in the help text. So, in the future, we can "drop" support for $vbid tokens (or $title ones, or whatever) by simply not listing them in the help text, but keep providing them and thus attain backward-compatibility.
Another BTW: this problem demonstrates why having a 'name' attribute for objects, a la View's and CCK's, is a good thing. I've just opened an issue.
So, to sum it up: let's support only $vbid tokens for now. What do you think?
Comment #5
quicksketch$vbid sounds like a good approach then given all the angles you've presented. Perhaps after creating the "name" attribute, we'll deprecate the $vbid in preference of "name", but continue to support them both. After all, even if we do add a name, we'll never really be able to get away from using the vbid (I think Views still keeps a vid despite giving things a name also).
With the option of adding a name later, I agree that the Title is not a good choice. And you nailed one of my other concerns: having 2 tokens to choose from is just confusing. As a site-builder I'd prefer there were just one so that the site was built in a consistent manner.
Comment #6
quicksketchNow that we have a "name" attribute in the Flag module, this task is a much easier thing to accomplish. We'll use the name attribute for all public APIs and the fid (previously vbid) will only be used at the database level.
Comment #7
mooffie commentedI should mention that there's one thing in the Token module that's bad: it isn't very efficient. It asks all modules to prepare all tokens, even if they aren't used.
So perhaps, for the benefit of "performance-aware admins", we shouldn't put the Tokens support directly in the flag module but in a separate mini module, which interested admins would enable separately. Perhaps we should create a 'contrib' sub-folder and put it there.
But perhaps I'm exaggarating here. After all, I don't rememeber seeing anybody complain about this trait of the Token module. What's your opinion on this?
Comment #8
quicksketchI don't think it's something we need to worry about. The flag_get_flags() function only performs one query per page no matter what, which if you have flag module installed, you'll probably have called that function once on the page by the time a token-replace happens.
Comment #9
quicksketchI wrapped in tokens into #270711: Add Actions Support to Flag, because I needed them for sending out e-mail messages.
Since we had basic tokens support, I just wrapped in this change now. I changed it slightly so that we'll be using the 'name' attribute instead of title/vbid (glad we don't need those anymore!). Also, I changed underscores to hyphens in the flag name, for consistency within the token names.
Comment #10
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.