Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Add a filter support to not suppress the undefined and false values in dust references ( may extend it to lists as well ) #138

Open
vybs opened this Issue · 6 comments

4 participants

@vybs
Collaborator

In some cases, we would like not to fail gracefully for missing values in the JSON, mostly for validating certain data exists at all times.

Even though this validation can be done on the "context", it is convenient to have a special filter to "enforce" that this value should always exist in the JSON

The only code to be modified is

 Chunk.prototype.reference = function(elem, context, auto, filters) {
  if (typeof elem === "function") {
    elem = elem(this, context, null, {auto: auto, filters: filters});
    if (elem instanceof Chunk) {
      return elem;
    }
  }
  if (!dust.isEmpty(elem)) {
    return this.write(dust.filter(elem, auto, filters));
  } else {
    return this;
  }
};

Related to : #135

@jimmyhchan
Owner

Similar issue that was closed #45

Should we be able to filter falsy values.
the :else block is sufficient but only if you content with how dust determines truthiness.

@rragan
Owner

This has languished for a year. Is it still important enough to keep around as an open issue or have people found solutions?

@jimmyhchan
Owner
@prashn64
Owner

No, the debug statements would not fix this, even if we added a check for it.

I think this is still a valid issue. The filter should decide if it can use an undefined value.

@rragan
Owner

What exact behavior are you looking for? Do you want a mechanism to fail the template if the data is not present or are you looking for way to default a value when it is not present, for example.

I had a variant of this earlier today where the user wanted to fail the template when a partial did not get passed a parameter (tantmount to it not being in context since right now you can't tell them apart). I tried adding an @abort helper that did a throw "message" but in non-debug mode this does nothing. Our current model of suppressing/console logging all errors does well to soldier on when there are problems but does not provide a way to fail when things are seriously wrong.

@jimmyhchan
Owner

Might be related to #381. A helper instead of a filter sounds better.

@rragan the abort helper that throws is probably being eaten by the try/catch added recently #381.

{?mightExist}{foo}{:else}{@log message="we should fix this it should be working"/}{/mightExist} and {?shouldStop}{foo}{:else}{@abort message="this should be working"/}{/mightExist} sounds like it would be useful

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.