Does dotted attribute notation work when using actual objects instead of JSON? about liqp HOT 9 CLOSED

We are already using it in this way in our custom tags. I did a quick and dirty implementation like this:

// horrible name...
abstract class BeanTag extends Tag {

    protected BeanTag(String name) {
        super(name);
    }

    protected <T> T getFromContext(String key, TemplateContext context, Class<T> clazz) {
        Map<String, Object> map = (Map<String, Object>) context.get(key);
        if (map == null || map.isEmpty()) return null;
        return MAPPER.convertValue(map, clazz);
    }
}

And our tags just extend BeanTag instead of Tag

Adding it to TemplateContext would be just a little extra syntactic sugar, but not necessary.

from liqp.

Yes, that would be good to have. Check the PR and it's unit tests.

from liqp.

Maybe allow the ObjectMapper to be passed in or customized? For example, our looks like this:

new ObjectMapper().
  registerModule(new Jdk8Module()).
  registerModule(new JavaTimeModule()).
  disable(FAIL_ON_UNKNOWN_PROPERTIES).
  setSerializationInclusion(NON_ABSENT).
  disable(WRITE_DATES_AS_TIMESTAMPS).
  enable(ALLOW_COMMENTS).
  setPropertyNamingStrategy(PropertyNamingStrategy.SNAKE_CASE).
  setDateFormat(new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss-Z"));

Not all of that is relevant, but the Jdk8 and JavaTime modules probably are.

from liqp.

Another question. Will the value present in TemplateContext (like in a custom Tag) be the original object, or a Map? If it is a map, then we'll just be converting the map back to an object instead of JSON back to an object in our custom tags.

from liqp.

Maybe allow the ObjectMapper to be passed in or customized?

Ah yes, of course. Moved it to ParseSettings so that you can set your own.

Will the value present in TemplateContext

I've not looked into this lib for a while, but I think it is. Give it a try.

from liqp.

Whoops, I accidentally merged it (and automatically closed this issue). Feel free to re-open if needed.

from liqp.

I'm getting a LinkedHashMap<String, Object> out of the TemplateContext instead of the instance of someComplexObject. That's not ideal, but not horrible.

from liqp.

Maybe just add public T get(String key, Class<T> clazz) to TemplateContext?

But then TemplateContext would also need ParseSettings to access the ObjectMapper

from liqp.

I'm getting a LinkedHashMap<String, Object> out of the TemplateContext instead of the instance of someComplexObject. That's not ideal, but not horrible.

Ah, ok, I misunderstood. Yes, the instance is getting converted into a LinkedHashMap<String, Object>.

Perhaps there is, but I can't imagine a use-case where this would be useful (keeping the instance instead of a LinkedHashMap<String, Object>). Feel free to create a new issue for this, but it wouldn't be high on my list to implement (unless there is a good use-case for it).

from liqp.