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 Sep 10, 2012 · 6 comments

Comments

Projects
None yet
4 participants
Contributor

vybs commented Sep 10, 2012

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

Contributor

jimmyhchan commented Sep 11, 2012

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.

Contributor

rragan commented Dec 13, 2013

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

Contributor

jimmyhchan commented Dec 14, 2013

Is this resolved by the debug statements added?

Contributor

prashn64 commented Dec 19, 2013

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.

Contributor

rragan commented Dec 19, 2013

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.

Contributor

jimmyhchan commented Dec 19, 2013

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