Conditional template overriding #101

niki-eng opened this Issue Aug 8, 2012 · 8 comments

4 participants


I'm trying to build a html forms using dust templates with blocks and partials.
The main concept is that (almost) every form input has the same structure (using twitter bootstrap) - base template is called "input_skeleton.dust":

<div class="control-group">
   <label class="control-label">
   <div class="controls">

Using the skeleton above, a simple input text looks like this ("input_text.dust"):

   {<input}DISABLED INPUT {/input}
      <input name="{name}" maxlength="{maxlength}" class="{class}"  value="{value}" type="text"/>

And finally in the actual html form (a dust template as well):


JSON data:


The problem is that, no matter if phone has "disabled" key set or not, input_text template always returns "DISABLED INPUT".
Am I doing this wrong or this is not possible with dust?

P.S. The conditional block


works correct itself.


thats really weird, let me play with this

So it is sure taking the first definition of <input

     <input name="{name}" maxlength="{maxlength}" class="{class}"  value="{value}" type="text"/>
    {<input}DISABLED INPUT {/input}

Inline partials are not evaluated in any context seems very odd. Sounds like a bug,


@rragan have you both encountered this?


The problem is summarized by this sentence from the docs of the original dust page:

"Inline partials never output content themselves, and are always global to the template in which they are defined, so the order of their definition has no significance."

Like JavaScript globals, inline partials go into the global space. I suspect the compiler is storing the first definition of an inline partial name into global space and ignoring the others. You can see the definition for DISABLED statically shifted into globals in the generated code.

The problem is in thinking of inline partials as real variables that can be assigned or re-assigned at runtime. Sadly they are not. I think a more robust mechanism for inheritable base tempates is badly needed. The current one is a bit of hack riding on top of the available bits of the dust framework.


Why cant the above be solved by moving the condtional out to a dynamic partial


so there are 2 partials once with value >display_input_disabled that prints DISABLED INPUT
and another with the display_input_ with

So only one is evaulated into the global context based on the value of the diasbled


@rragan btw

{<input} something {$idx} {/input}


the above works, have you tried this


Perhaps related - I'd like the inline partial to affect child templates, not just parent templates. Example:

this works:

--parent template--

--child template--

this doesn't:

--main page-

--components template--

That's a pitty since the above would allow to create a single "library" of reusable components and then selectively import from it (by declaring blocks that are covered by the child template).

Any strong reasons why an inline-partial couldn't be global to the child page, too?


In the other thread related to this ticket, we had other proposals.


Happy to hear your thoughts and contributions @zzen


This is just how the language was designed for inline partials. There are other approaches that can provide a solution for your needs. See #125.

@rragan rragan closed this Dec 13, 2013
This was referenced May 2, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment