Since 2.3.22 you can use someObject?api to get a "beanish" view of an object, if you are configuring FreeMarker to support that. (But of course you should upgrade to 2.3.24-incubating nowadays.)
See: http://freemarker.org/docs/ref_builtins_expert.html#ref_buitin_api_and_has_api Note that you can use the bean property shorthands with this too, like: solrDocumentList?api.numFound (Also, I assume solrDocumentList only contains one page of the hits, and numFound is the total number of hits, because otherwise you could simply use solrDocumentList?size.) -- Thanks, Daniel Dekany Wednesday, June 1, 2016, 2:35:36 PM, Jon Harper wrote: > Hi list, > > I've got a question on how to handle "beans" (ie java object with > getters) that implement the List interface. Apologies if this has > already been asked, or improved in future versions. Details follow: > > I'm using freemarker freemarker-2.3.21.jar and the default object > wrapper to display results from Solr using their java API (Solrj). > They use a Java Object extending ArrayList: > https://lucene.apache.org/solr/6_0_0/solr-solrj/org/apache/solr/common/SolrDocumentList.html > So this object is a list of results with additional methods like getNumFound() > > This doesn't play nice with freemarker because the object can't be > used as a hash and as a sequence at the same time in the following > manner: > ``` > Found ${solrDocumentList.numFound} results > <#list solrDocumentList as solrDocument} > ${solrDocument.title} > </#list> > ``` > > I also tried solrDocumentList.getNumFound() but this (logically) > doesn't work because the sequencewrapper doesn't expose the methods of > the underlying sequence. > > Is there a standard way to nicely deal with this kind of objects ? Are > there plans to add ways to do this ? > > Thanks in advance, > Jon > > ps: I ended up writing boilerplate code that wraps their object, and > it's really clumsy. > ps2: I think that inheriting from ArrayList like this is a very bad > practice and that composition would allow far greater flexibiliy, but > that's just how the Solrj folks designed their API. > > Jon >
