Mailing-List: contact notifications-help@freemarker.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@freemarker.incubator.apache.org
Date: Wed, 12 Jul 2017 07:27:00 +0000 (UTC)
From: "Daniel Dekany (JIRA)" <jira@apache.org>
To: notifications@freemarker.incubator.apache.org
Message-ID: <JIRA.13086263.1499781252000.225763.1499844420138@Atlassian.JIRA>
In-Reply-To: <JIRA.13086263.1499781252000@Atlassian.JIRA>
References: <JIRA.13086263.1499781252000@Atlassian.JIRA> <JIRA.13086263.1499781252204@jira-lw-us.apache.org>
Subject: [jira] [Comment Edited] (FREEMARKER-61) ?sort_using with a
 Comparator parameter
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Wed, 12 Jul 2017 07:27:15 -0000


    [ https://issues.apache.org/jira/browse/FREEMARKER-61?page=3Dcom.atlass=
ian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1=
6083565#comment-16083565 ]=20

Daniel Dekany edited comment on FREEMARKER-61 at 7/12/17 7:26 AM:
------------------------------------------------------------------

{{sort}} is currently parameterless, so adding parameters would mean that t=
he return value of {{foo?sort}} will have to change from purely sequence to=
 sequence plus method, which is not 100% backward compatible. But I think {=
{sort_using}} (or rather, {{sort_with}}?) is not worse than {{sort}} anyway=
, because it expresses clearly what the argument does. (Adding one more bui=
lt-in name is not really new syntax, I'm not afraid of it... there are hund=
reds of it already.)

Using {{ObjectConstructor}} is highly discouraged because of security conce=
rns. It can't be removed due to backward compatibility unfortunately, but s=
ome use {{freemarker.core.TemplateClassResolver.SAFER_RESOLVER}} to fix thi=
s issue. We can't build a core feature on its existence. But, if {{MyCompar=
ator}} implements {{TemplateModel}} (which is an empty interface), then you=
 can use {{?new}}.

Why do you want unwrapping per item to be the default? Also, why do you wan=
t it to a be an option exposed to the caller? When would you use {{true}} o=
r {{false}}, as a template author? (Most users have no idea what object wra=
pping is, so the parameter doesn't make sense for them. Also, as FM2 doesn'=
t support named parameters in function calls, it can't be guessed what that=
 {{true}}/{{false}} means there. My first bet would be that its increasing =
vs descending order, but I would be wrong.)

Edit: OK, I just realize you don't want unwrapping per item, you want the m=
odels to be passed to the {{Comparator}}. Makes sense, though yet again it'=
s not very performant. Instead of {{String stringToCompare =3D user.getName=
()}} you would have {{if (\!(user instanceof TemplateHashModel)) die(); Tem=
plateModel value =3D ((TemplateHashModel) user).get("name"); if (\!(value i=
nstanceof TemplateScalarModel)) die(); String stringToCompare =3D ((Templat=
eScalarModel) value).getAsString()}}. Models just aren't for data grinding.

Another thing... as you subclass {{Comparator}}, we can actually check with=
 reflection if it expect {{TemplateModel}}-s or not (as the generic type pa=
rameters are accessible due to subclassing). If it expect two {{TemplateMod=
el}}-s, we don't unwrap as you have suggested, otherwise we unwrap (the whi=
le {{List}}, I guess).


was (Author: ddekany):
{{sort}} is currently parameterless, so adding parameters would mean that t=
he return value of {{foo?sort}} will have to change from purely sequence to=
 sequence plus method, which is not 100% backward compatible. But I think {=
{sort_using}} (or rather, {{sort_with}}?) is not worse than {{sort}} anyway=
, because it expresses clearly what the argument does. (Adding one more bui=
lt-in name is not really new syntax, I'm not afraid of it... there are hund=
reds of it already.)

Using {{ObjectConstructor}} is highly discouraged because of security conce=
rns. It can't be removed due to backward compatibility unfortunately, but s=
ome use {{freemarker.core.TemplateClassResolver.SAFER_RESOLVER}} to fix thi=
s issue. We can't build a core feature on its existence. But, if {{MyCompar=
ator}} implements {{TemplateModel}} (which is an empty interface), then you=
 can use {{?new}}.

Why do you want unwrapping per item to be the default? Also, why do you wan=
t it to a be an option exposed to the caller? When would you use {{true}} o=
r {{false}}, as a template author? (Most users have no idea what object wra=
pping is, so the parameter doesn't make sense for them. Also, as FM2 doesn'=
t support named parameters in function calls, it can't be guessed what that=
 {{true}}/{{false}} means there. My first bet would be that its increasing =
vs descending order, but I would be wrong.)

Edit: OK, I just realize you don't want unwrapping per item, you want the m=
odels to be passed to the {{Comparator}}. Makes sense, though yet again it'=
s not very performant. Instead of {{String compareThis =3D user.getName()}}=
 you would have {{if (\!(user instanceof TemplateHashModel)) die(); Templat=
eModel value =3D ((TemplateHashModel) user).get("name"); if (\!(value insta=
nceof TemplateScalarModel)) die(); String stringToCompare =3D ((TemplateSca=
larModel) value).getAsString()}}. Models just aren't for data grinding.

> ?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 =C5=BDi=C5=BEka
>
> 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 w=
hich 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 th=
e 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 i=
n my opinion, solution:
> First you'd have a Comparator in Java, and perhaps register it like you d=
o 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 t=
he template syntax or cluttering {{?sort_by}}.
> Thanks for considering.


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