freemarker-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ondra Žižka (JIRA) <j...@apache.org>
Subject [jira] [Comment Edited] (FREEMARKER-61) ?sort_using with a Comparator parameter
Date Wed, 12 Jul 2017 03:47:00 GMT

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

Ondra Žižka edited comment on FREEMARKER-61 at 7/12/17 3:46 AM:
----------------------------------------------------------------

The Java method as you suggest is a good idea. I didn't think of putting the comparator to
the model. Although it's a bit more overhead of adding it to the model (versus instantiating
it).

Edit: Now I realized Freemarker can instantiate.
{code}
<#assign comparer = objectConstructor("cz.oz.myproject.MyComparer", "foo")>
{code}

I agree that for non-java users, {{?sort_using(Comparator)}} would not be too useful.
And as you say, it could accept a function, but that would be really crazy :) I mean, it would
do the job, but unless users desperately cry for it, I wouldn't do that.

Originally I wanted to suggest {{?sort_by(Comparator)}} - would that be less obtrusive? Basically
no new syntax/built-in, just a support for a new parameter type. But then I changed to {{sort_using}}
because the name wouldn't match.

Now thinking about it, couldn't it be {{?sort(Comparator)}} - an optional argument? Maybe
that would be the best. Also it would be natural thing to have - following the Java API, like,
{{Collections.sort(Comparator)}}.

Also note that I would expect the comparator arguments to be template models. Unwrapping the
items beforehand, for the sake of optimization, could be optional, false by default (less
surprise rule of thumb).

Together with the instantiation above, that would be exactly what I long for:

{code}
<#assign comparator = objectConstructor("cz.oz.myproject.MyComparator", "foo")>
<#list reportModel.relatedResources.applications.list)?sort(comparator, true) as applicationReport>
{code}

That would be wonderful!






was (Author: pekarna):
The Java method as you suggest is a good idea. I didn't think of putting the comparator to
the model. Although it's a bit more overhead of adding it to the model (versus instantiating
it).

Edit: Now I realized Freemarker can instantiate.
{code}
<#assign comparer = objectConstructor("cz.oz.myproject.MyComparer", "foo")>
{code}

I agree that for non-java users, {{?sort_using(Comparator)}} would not be too useful.
And as you say, it could accept a function, but that would be really crazy :) I mean, it would
do the job, but unless users desperately cry for it, I wouldn't do that.

Originally I wanted to suggest {{?sort_by(Comparator)}} - would that be less obtrusive? Basically
no new syntax/built-in, just a support for a new parameter type. But then I changed to {{sort_using}}
because the name wouldn't match.

Now thinking about it, couldn't it be {{?sort(Comparator)}} - an optional argument? Maybe
that would be the best. Also it would be natural thing to have - following the Java API, like,
{{Collections.sort(Comparator)}}.

Also note that I would expect the arguments to be template models. Unwrapping the items beforehand
could be optional, default false.

Together with the instantiation above, that would be exactly what I long for:

{code}
<#assign comparator = objectConstructor("cz.oz.myproject.MyComparator", "foo")>
<#list reportModel.relatedResources.applications.list)?sort(comparator, true) as applicationReport>
{code}

That would be wonderful!





> ?sort_using with a Comparator parameter
> ---------------------------------------
>
>                 Key: FREEMARKER-61
>                 URL: https://issues.apache.org/jira/browse/FREEMARKER-61
>             Project: Apache Freemarker
>          Issue Type: New Feature
>          Components: engine
>    Affects Versions: 2.3.26-incubating
>            Reporter: Ondra Žižka
>
> Hi Daniel :)
> I know that lists should be sorted before passing them to the template in general.
> In our case, the template is backed by a generic API for graph database which gives an
{{Iterable}} for any 1:N relation. So sorting needs to happen in the template.
> Now I'd like to sort that, for which the {{?sort_by(["...", "..."])}} is good enough,
except when it gets a bit more complicated - e.g. sometimes the values are missing in which
case it should sort by something else...
> Doing that in a template is not a good idea, so I suggest this, elegant in my opinion,
solution:
> First you'd have a Comparator in Java, and perhaps register it like you do with {{FreemarkerMethod}}.
> Then you could pass this as a parameter to {{?sort_using.}}
> {code}
> public class SortByName implements Comparator { ... }
> myData.persons?sort_using("SortByName")
> {code}
> This would be even better if it could pass parameters to the constructor:
> {code}
> public class SortByName implements Comparator {
>     public SortByName(boolean ladiesFirst) { ... }
> }
> myData.persons?sort_using("SortByName", [true])
> {code}
> This would greatly leverage sorting in templates while not complicating the template
syntax or cluttering {{?sort_by}}.
> Thanks for considering.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message