Another token enhancement proposal
Token should probably provide an easy way for modules to create tokens based on already existing tokens. Let me explain what I mean. For a node, I should be able to pass in 'author-' as a prefix, 'user' as the type, and the node's author as the object. Token would then get all the values for 'user' with the object $user, and would return them as the tokens [author-usertokenpropertyhere]. This could be used by many modules: nodes could create tokens for their organic groups as [og-nodeproperty], buddylist could create tokens for the user's buddies as [buddylist-userproperty], and nodes could create tokens for their terms as [tax-taxonomyproperty].
Token would have to check to make sure that we are not caught in an infinite loop (node calls its organic group, which calls its organic group, which calls its organic group, etc., or node calls its author, which calls its most recent post, which calls its author, etc). In some case recursiveness could be useful (node calls organic group which calls author), but it would have to make sure that the same property isn't being called twice.
Admittedly, this would cause performance declines- however, if it becomes possible to disable certain tokens that are not used, it would stop being a performance problem and start being an optional feature that would increase the power of token and the modules that use it.
This would be a highly useful feature, and many modules would be able to take advantage of this. There are countless ways where nodes, users, taxonomy items, comments, etc. interact, and this property would allow the token module to make use of these interactions.
great idea
This seems like a great idea to me. I think that before this goes in we would need a feature like the formatter callbacks that Eaton and Fago have been discussing i.e. in the other proposal: http://groups.drupal.org/node/5744
--
Knaddisons Denver Life | mmm Chipotle Log | The Big Spanish Tour
Technically...
....this is already being done. It's how the CCK token implementation works. It uses a 'field' namespace instead of a 'node' one, and when the time comes to expose the CCK related tokens for a node, it checks to see what fields are used by the node and calls the token hooks for them.
It can definitely be clarified, though... perhaps this could be some sort of mechanism to make it official....
indeed
Yes, good point. I hadn't considered that aspect of it.
The reason I'm hesitant to do this prior to the callback system is that we already have a performance penalty in token, if we implement something like this then, for example, every node posted into an OG would incur double the penalty. Yikes.
Greg
--
Knaddisons Denver Life | mmm Chipotle Log | The Big Spanish Tour
However, so one needs to
However, so one needs to redefine each token. It works, but one has to do it manually.
I think a way to let token handle this would be useful. So we could easily expose all the tokens of related entities like author, user reference, node reference and others.
really?
The cck code does it automatically declaring new tokens as new fields are added to they system. I use it with no "manual" intervention necessary.
The hook_token_list/hook_token_values for vocabs could work the same way, right? getting a list of all vocabs and declaring tokens by looping over that list.
--
Knaddisons Denver Life | mmm Chipotle Log | The Big Spanish Tour