Skip to content

Allow results of helpers as parameter values #170

Closed
rragan opened this Issue Oct 10, 2012 · 2 comments

1 participant

@rragan
rragan commented Oct 10, 2012

The dust compiler does not allow helpers to be used in params of references to other helpers. For example, one of our users just ran into the issue with this shared partial of his. He is trying to use our content helper to pass the label for the input field to the partial.
{>"common/inputs/textInput" type="email" name="email" value="sandbox@paypal.com" confidential="confidential" placeholder="{@content $key="templateContent:EmailFieldLabel"/}"/}

The only workaround I could suggest to him is not a great choice (pass the content key value as a string and call our content helper in the partial, e.g.
{>"common/inputs/textInput" type="email" name="email" value="sandbox@paypal.com" confidential="confidential" placeholder="sandboxspartaweb.loginform.EmailFieldLabel"/}"/}

And then resolve the placeholder in the partial with
{@content $key=placeholder /}

This limits the generality of the partial since it can only take inputs from the content system and not arbitrary strings.

This same problem will crop up with the {@access} helper I’ve filed a push request for; in fact for any helper that might be used to create a param value for another partial. For example, {@math key="16" method="add" operand="4"/} to pass the result of a simple math operation.

Any thoughts on remedies? JSPs had a similar problem since you could not put a as an attribute value. This was “fixable” by writing an EL function which could appear there or by assigning the tag value to a JSP variable and then passing ${variable}.

Some options I can think of:

  • Have the compiler allow a partial in an attribute value of another partial? This is the most natural for the user I would guess but suffers from the quotes within quotes parsing problems ( I guess single quotes were not adopted as an alternate.)
  • Allow some form of variable assignment and then pass the value. Tends to ruin functional nature of the templating language.
  • Create some way to invoke a helper as a function with fixed ordered arguments ... seems messy.
  • Other ideas?
@rragan
rragan commented Oct 16, 2012

I've been playing with an approach for the second bullet (some form of variable assignment).

What I have is two helpers. An example should clarify.

{@scope}
  {@local key="abc"}
    {@math key="16" method="add" operand="4"/} 
  {/local}
  {>somePartial mathVal=_var.abc /}
{/scope}

What is going on behind the scenes is that the scope helper creates an _var object in the current context. Every @local tag puts the result of evaluating its body into _var."key". Since the @local tag is evaluated in the current context, any helpers you need to pass values from can be evaluated and locked down before calling the partial.

The sole purpose of the @scope wrapper tag is to create and destroy the _var object. I don't want these "variables" to live for long. Nor, are they easily accessed from lower levels since it would require a path reference upwards (not that you couldn't get to them, just not easy).

It actually lets you pass fairly complex chunks of content since the @local body evaluation can be multi-line, call other partials, etc resulting in a finalized string value that becomes "key". This has echoes of populating blocks of content for template inheritance but wasn't what I had in mind.

@rragan
rragan commented Oct 26, 2013

I'm OK with a helper-based solution I have.

@rragan rragan closed this Oct 26, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.