freemarker-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Dekany (JIRA)" <>
Subject [jira] [Commented] (FREEMARKER-45) Support properties of classes that extend collections
Date Thu, 16 Feb 2017 00:11:41 GMT


Daniel Dekany commented on FREEMARKER-45:

Currently, the best you can do is using `?api`: {{myinstance?api.myProperty}}. See:

Note that this kind of issue exists both for {{List}}-s and {{Map}}-s. For a {{Map}}, it would
be impossible to tell if by {{myinstance.myProperty}} you mean Java {{myinstance.getMyProperty()}}
or Java {{myinstance.get("myProperty")}}. It's true that for {{List}}-s we could say that
if the key is not a number, then it must be something else than a {{List}} item index. (Note
that {{}} and {{foo['bar']}} are equivalent in FTL, hence I said "key".) Actually,
a value can be multi-type in FTL, like be both a FTL sequence and an FTL hash, which is kind
of what you ask for, but multi-types using have some confusing consequences too (plus we had
to decide what Java API-s to expose that way). So at least in the existing "type system" of
FreeMarker 2 I don't see a better compromise, than keeping wrapped {{List}}-s as clean (single-typed)
FTL sequences, and in the quite rare cases when someone has a custom {{List}} class that has
some application domain properties that he need to access, one can still use {{?api}}. (We
will see what to do with this in FreeMarker 3 though... perhaps we should allow named members
regardless of type.)

> Support properties of classes that extend collections
> -----------------------------------------------------
>                 Key: FREEMARKER-45
>                 URL:
>             Project: Apache Freemarker
>          Issue Type: Improvement
>            Reporter: Alexander Hars
> Currently Freemarker wraps classes that extend a collection using specialized adapters
(for example if MyClass extends java.util.List then this class is wrapped using the DefaultListAdapter).
This has the effect that all non-list properties of MyClass are inaccessible for use in the
> Assume that MyClass has a method getMyProperty and a MyClass instance is added to the
data model using the hash ''myinstance', then the template
> ${myinstance.MyProperty} leads to the following error message: 
> FreeMarker template error:
> For "." left-hand operand: Expected a hash, but this has evaluated to a sequence (MyClass
wrapped into f.t.DefaultListAdapter):
> Freemarker needs to expose the non collection-related properties in the same way as it
would on a simple object that does not extend a collection. Support for collections should
not come at the expense of features that are already available for plain objects.

This message was sent by Atlassian JIRA

View raw message