[stringtemplate-interest] support for set

[Terence Parr]

On Dec 9, 2006, at 11:42 PM, John Snyders wrote:
>>> 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.

John,

I cannot agree that allowing expressions in IF statements is  
allowed.  No logic in the templates, right?  Allowing IF-conditionals  
does not follow from this statement you just made.  Display has  
nothing to do with conditionals.

>> 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.

But the crucial difference is that they can only test the RESULT of  
the model's computation.  They cannot do computation.  That is the  
difference, right?

> Supporting set doesn't change
> that.

It adds another hole.

> 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.

I'm trying to make logic hard ;)

>> 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.

No diff between "a==b" and "a in b" if b has |b|<=1 and b is a set.

>> 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.

Crap.  Oh well, i'm consistent, but it opens a hole.

> ... I think I get it now...
> Is the issue you are concerned about?
>
> $if($myset.("state=='MA'")$

I'm concerned with $if(foo==bar)$ and $if(user in superUser)$.  I  
mean that is the example i use in my model-view separation  
paper...straight from it (no testing if I'm super user in the  
template or you must have that in every template).  bad!

> 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.

Often they are the same person ;)

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

I'm contemplating taking out the map check in IF. ;)

> 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 :)

Yup.  Just don't test set or map containment in IF ;)

Ter