Does dotted attribute notation work when using actual objects instead of JSON?

[efenderbosch]

We're trying to directly put an object into the render context like this:

template.render("some_top_level_name", someComplexObject);

And in the actual template, we can access the root object via {{ some_top_level_name }} but not any of its attributes, like {{ some_top_level_name.snake_case_attribute }} or {{ some_top_level_name.camelCaseAttribute }}

Does this work? Are we doing it wrong?

[bkiers]

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

[efenderbosch]

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.

[efenderbosch]

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.

[bkiers]

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.

[bkiers]

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

[efenderbosch]

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

[efenderbosch]

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

But then TemplateContext would also need ParseSettings to access the ObjectMapper

[bkiers]

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).

[efenderbosch]

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.