[jira] [Commented] (FREEMARKER-45) Support properties of classes that extend collections

["Daniel Dekany (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FREEMARKER-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15868846#comment-15868846 ] 

Daniel Dekany commented on FREEMARKER-45:
-----------------------------------------

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)