add token support for non-entities

Any update on this?

This would be extremely useful. I was trying to load a taxonomy term with a tid supplied by a non-entity Token, but I suppose this is currently not possible(?)

Any tips whereabouts to make a start with this?

+1

Here is my first attempt on building token-support for non-entities. It successfully replaces variables of type "text".

Updated component.

Patch works well....although it's not committed to latest version of rules....will it be?

I like the approach :)
Fixed some coding standard issues and created new patch.
I'm just about to test this - thus needs further review.

I've just added the function _rules_system_valid_text_type() from the other issue to enhance the patch here.

Although it's a bit inconsistent to have e.g. a node variable as "node" replacement whereas a string would appear as rule:string ?

Well, that really could be, but I don't think it's a huge UX issue. E.g. we could change the description from:
Replacement patterns for This rule
to
Text replacement patterns for this rule

This looks nice. I cleaned up and moved the code from _rules_system_valid_text_type() since it probably doesn't need to be a separate function.

Also changed Replacement patterns for This rule to Replacement patterns for variables within this rule. How does that sound?

Just to clarify, the list of variables available for replacement only includes text variables, but nothing prevents you from shoving other variables in there as tokens.

Replacement patterns for variables within this

Is not fully correct because if there's a variable of type node the tokens for this variable are listed as Replacement patterns for Node.
That's also the reason fago mentioned the inconsistency.
A variable of type node will have replacement patterns like [node:title].
A variable of type text will have replacement patterns like [rule:variable].
Now you could argue the replacement pattern for the variable with the type node should be [rule:node:title] or the text variable pattern should look like [variable].

Ah, I see what you mean, that's confusing. Maybe just Replacement patterns for text variables ?

I think there is at least some consensus that the patch in the current version is useful and the solution is a good one (within the constraints of token). So I'd vote for committing even if the discussion about the label is still ongoing.

Indeed the functionality could and should be extended to all (non-entity) variables in the future. But ftw I think "Replacement patterns for text variables" is just fine.

I found this issue because moderation_workflow provides [previous-state] and [new-state] variables which work everywhere except when trying to send an email.

The patch in #14 fixes that by providing [rule:new-state]. It is weird that [new-state] works in some actions and [rule:new-state] must be used for others. It's not a huge deal because a new section of replacement patterns is shown to list these. What about "Replacement patterns for extra variables" as a label?

I do agree with @torotil that labeling shouldn't hold this up though.

FWIW, here are my observations and questions:

I think the variable prefix and description texts can still be improved. "All variables that are available in this rule and cannot be accessed otherwise." isn't very specific. ;)

I'm not sure if the 'rule' prefix is correct, since all configured things aren't necessarily 'rules', such as action sets and condition sets. What about type-name-specific prefixes instead?

In that case, I think something like "Variables provided by this $configuration_type" might work better. But if I had to choose one prefix, I would favor 'configuration' over 'rule'.

Then, another possible change:
- "Replacement patterns for Rules variables"
+ "Replacement patterns for . [$config->name]'s . variables"

More questions:
* How well do you think it would work to put a connective between the prefix and the variable name, ie parameter, or some other triple chain?
* Could 'provided variable' ever be an option, or only parameters?
* What other token sources does this patch provide?

Export of a test rules component:

{ "rules_set_message_using_component_variable_parameter" : {
    "LABEL" : "Set message using component variable \/ parameter",
    "PLUGIN" : "rule",
    "REQUIRES" : [ "rules" ],
    "USES VARIABLES" : { "message" : { "label" : "Message Variable", "type" : "text" } },
    "DO" : [ { "drupal_message" : { "message" : "[rule:message]" } } ]
  }
}

@#21: That is a very thoughtful approach. I really like that.

[variable:value] makes total sense to me and is in line with what people are used from field API.

+1 to that idea

Best,

Fabian

I hope I got the idea of #812058-21: add token support for non-entities
Here's a new patch.
Attention: The function rules_tokens() handles all tokens that have a type which's prefixed with rules_. I'm not sure if this is viable, it's very generic but maybe it's better to have a fixed list of types to handle as this would be easier to understand.

I've changed the title for the patterns to Replacement patterns for this rule's simple variables - I think this really covers the idea of those patterns and should be understandable.

I've been watching this post. I'm still using original patch for variables. Will applying the latest patch cause me headaches and needed adjustments to all of my rules currently using variables as tokens?

Thanks

Will applying the latest patch cause me headaches and needed adjustments to all of my rules currently using variables as tokens?

Yes - token names for simple variables will change.

You emphasized "simple". Does this mean some token variables won't change? Should I go ahead and apply patch now assuming whatever variables I currently have [or new ones] will, at some point, have to be changed to this new method?

Thanks

Does this mean some token variables won't change?

Variables not touched by any of this patches won't change.

... have to be changed to this new method?

Yes, it's likely that you'll have to change them some-when.
The patches aren't compatible between the different approaches.
And there's not yet a final decision about how the token should look like. However since we've discussed this and fago proposed to use [variablename:value] it's likely this pattern will be used since fago is the one that has the power to make the necessary commit. :)

So, [variablename:value] will replace my current tokens of [rule:variablename] ?

So, [variablename:value] will replace my current tokens of [rule:variablename] ?

Yes, that will most probably be the case.

Sorry for continuing to ask questions. So, I need to go ahead and apply patch and go in and change variable names?

I want to do whatever I need to do before i continue creating more rules which will also have to be changed more, later. I wonder if I could apply patch and then go in sql and replace all of rules:myvaraiablname to variablename:value?

Yes, I think that would be the cause of action.

* Revert your patch
* Apply this patch
* Rename rules (I personally would export them to a feature and do a manual search and replace)

While you are on that:

Could you test that patch - if it works for you and mark RTBC then again?

Thanks,

Fabian

I will try to get to this over weekend. cant rename rules, i have too many and too many components interchanged with each other. I'll just revert my patch, apply yours and change variable names per rule. Is reverting patch self-explanatory in net beans? I suspect I could replace old-applied-patch files with rules latest files also, as a way to revert?

Did I get this right? After patching the dev version of the rules module I should be able to use [variablename:value] as a replacement token for content in a direct input field. So this should work?

1. add a variable of type text called logmessage
2. add another action to that rule that should 'Set a data value'
3. type [logmessage:value] to the direct input field

I'm asking because I am not quite sure whether I understood this right and this example is not working for me.

Any help would be appreciated. :)

--- edit ---
Okay, my bad. It works as expected. My mistake was that I didn't pick the right data selector to begin with.

@fago: Time to commit this then ;-).

Should this work with out of the box with rules data passed in via hook_rules_data_info() ? I cant seem to get any of my non-entity tokens :(

I've run into this as well... Given that this is closed probably good to open another ticket?...

Another note anyway: Conflicting docs?:

• http://drupal.org/node/1300042#direct-input "You can use all chains of data found with the data selector as tokens in direct input mode."
• http://drupal.org/node/905632 "[...] these data types are not available in Direct Input mode."

Just noting I tried the patches from both #23 and #37 but only the patch from #23 worked for me.

Based on changes I already made, see comment #28 above - if I install the latest rules, will I need to redo these variables again? It seems like you're using different names again?

Thanks