Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

URN expressions #145

Merged
merged 7 commits into from
Feb 1, 2018
Merged

URN expressions #145

merged 7 commits into from
Feb 1, 2018

Conversation

rowanseymour
Copy link
Member

See #63

@@ -317,6 +318,10 @@ func EvaluateTemplateAsString(env utils.Environment, resolver utils.VariableReso
buf.WriteString(token)
} else {
strValue, _ := utils.ToString(env, value)
if urlEncode {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as in old engine - need this for when the expressions should be URL encoded, but the template itself shouldn't

nesting string
nestedVars vars
type varMapper struct {
substitutions map[string]string
Copy link
Member Author

@rowanseymour rowanseymour Jan 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these are things which get totally rewritten - e.g. becomes a function call. Also renamed other fields for clarity.

@coveralls
Copy link

coveralls commented Jan 26, 2018

Coverage Status

Coverage increased (+0.07%) to 70.928% when pulling eaf16d1 on urn_expressions into c2b00fa on master.

}

var rootVarMapper = newRootVarMapper()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

avoids re-initializing this for every expression

@@ -247,15 +271,15 @@ func migrateLegacyTemplateAsString(resolver utils.VariableResolver, template str
} else {
strValue, _ := toString(value)

// date context references get rewritten as functions
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so do other things now - hence wrapRawExpression

@rowanseymour
Copy link
Member Author

@nicpottier please re-review - format_urn now accepts a list

sliceLen, _ := utils.SliceLength(urnArg)
if sliceLen >= 1 {
urnArg, _ = utils.LookupIndex(urnArg, 0)
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe 0 case should be explicitly handled here? Either as an error or an empty string? (I lean towards empty string though could be easily swayed to it being an error)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer empty string so that @contact.urns and @(format_urn(contact.urns)) both evaluate to empty (when stringified)

//
// @(format_urn("tel:+250781234567")) -> 0781 234 567
// @(format_urn("twitter:134252511151#billy_bob")) -> billy_bob
// @(format_urn("NOT URN")) -> ERROR
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we add a @(format_urn(contact.urns)) example?

{old: "@contact.telegram", new: "@(format_urn(contact.urns.telegram.0))"},
{old: "@contact.twitter", new: "@(format_urn(contact.urns.twitter.0))"},
{old: "@contact.facebook", new: "@(format_urn(contact.urns.facebook.0))"},
{old: "@contact.mailto", new: "@(format_urn(contact.urns.mailto.0))"},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need the .0s here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No but I think better the users see that these are lists and we treat passing a list to format_urn as a convenience.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hah, funny, feels the opposite to me. Since 99% of users will never have more than one URN, present them with the simplest option that works.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well I guess I'd be ok with making this look simpler. I actually wonder tho how common format_urn usage is going to be since I imagine most of the time people want to reference contact URNs, it's not to display them in a message, but to pass them to a webhook or something like that

@rowanseymour rowanseymour merged commit eee202a into master Feb 1, 2018
@rowanseymour rowanseymour deleted the urn_expressions branch February 1, 2018 16:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants