[stringtemplate-interest] support for set

[John Snyders]

> -----Original Message-----
> From: stringtemplate-interest-bounces at antlr.org
> [mailto:stringtemplate-interest-bounces at antlr.org]On Behalf Of Terence
> Parr
> Sent: Saturday, December 09, 2006 4:19 PM
> To: stringtemplate-interest
> Subject: Re: [stringtemplate-interest] support for set
>
>
> On Dec 7, 2006, at 7:27 AM, John Snyders wrote:
> > In a previous thread (http://www.antlr.org:8080/pipermail/
> > stringtemplate-interest/2006-December/000836.html) Nate
> > had asked for support for the Java Set
> > "$if (someSet.moo)$ would be >> equivalent to the Java: if
> > (someSet.contains("moo"))"
> >
> > I see no reason why Set should not be more fully supported. I agree
> > that the syntax get(string) should not be supported because it acts
> > as a method call.
>
> Nate suggested, though, following:
>
> > I would like to check in my templates if the user has
> > a given capability. Eg, the template should show an "admin tools" link
> > if the user has the capability "can view admin tools".

This seems like a legitimate use to me. The model/controller decides what
the available application capabilities are and the view figures out how to
show them.

> This is a serious model-view separation violations.  I am
> specifically trying to prevent people from doing logic in the
> template.

But templates support $if()$ logic already. Supporting set doesn't change
that.
I can create scalar attributes (either boolean true/false or String null/non
null) to represent capabilities. It is just easier if you have a bunch of
scalars to collect them together as a set.

> This example provides a prime case of we should not do,
> therefore, I don't think allowing set testing is reasonable.  This is
> the same logic I used to avoid the equivalent for single element sets
> (i.e., single values): the == operator.

This I don't understand how does a set with one element in it relate to the
== operator. I agree that $if expressions should now allow any comparison
operators.

> >  Because set is a collection it is already supported in that you
> > can do this $myset$ and it will enumerate all the keys.
>
>   yes, but you cannot have logic, which is the key separation principle.
>
> > $myset.key1$ should be replaced with "key1" if key1 is in the set
> > and "" otherwise.
> > Or should $myset.key1$ be replaced with "true" if it is present?
>
> I think you get an empty string for $mymap.key$; I don't think I want
> to open this whole a bigger, because I think you can test $if
> (mymap.key)$ I just realized.  Perhaps we should not advertise these
> edge cases ;) Certainly I don't think we should create more of them ;)
>

Yes $if(mymap.key)$ works as you would expect.

... I think I get it now...
Is the issue you are concerned about?

$if($myset.("state=='MA'")$

The potential for abuse, as you say, already exists with Map. I don't see
this as a problem because the power is in the hands of the model/controller
author not the template author.

If Set is more convenient for the model I see no reason to bar it from the
template.

These cases should not be advertised but they should be held up as examples
to educate people on the proper use of ST. Your properties must not have
side effects. Your maps should work like maps. Your sets should work like
sets. Your renderers should just do rendering. Otherwise go back to JSP or
Velocity :)

Thanks,
-John

> Ter
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org:8080/mailman/listinfo/stringtemplate-interest