[
https://issues.apache.org/jira/browse/FREEMARKER-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15868846#comment-15868846
]
Daniel Dekany edited comment on FREEMARKER-45 at 2/16/17 12:11 AM:
-------------------------------------------------------------------
Currently, the best you can do is using {{?api}}:
{{myinstance?api.myProperty}}. See:
http://freemarker.org/docs/ref_builtins_expert.html#ref_buitin_api_and_has_api
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 {{foo.bar}} 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.)
was (Author: ddekany):
Currently, the best you can do is using `?api`: {{myinstance?api.myProperty}}.
See:
http://freemarker.org/docs/ref_builtins_expert.html#ref_buitin_api_and_has_api
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 {{foo.bar}} 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: https://issues.apache.org/jira/browse/FREEMARKER-45
> 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 template.
> 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
(v6.3.15#6346)
