[stringtemplate-interest] support for set

[Nate]

Let me step back and explain my situation and maybe you can help to find 
the correct solution.

I am building a web application. Users have a list of "capabilities", 
each of which is just a String. URIs can be tagged with a "capability". 
When a user tries to view a URI that is tagged, they are asked to login. 
If they are logged in and don't have the capability, they are shown an 
error page.

Besides what parts of the site users can access, capabilities are also 
used to fine tune what actions users can take. Eg, a user must have the 
capability "users.edit" to edit users and "users.delete" to delete 
users. If a user has "users.edit" and does not have "users.delete" then 
the delete button should not appear on the edit user page.

The reason we use capabilities in this way is because our customers want 
to customize the user roles. So the customer creates a number of user 
roles which are each a list of capabilities, then users get assigned 
user roles. When a user logs in they get assigned all the capabilities 
for all the roles they belong to. All the code cares about is if you 
have specific capabilities, not what role you are.

There are many capabilities and the control is so fine that I imagine 
the templates are going to have to check if they should show a link to 
this part of the site or not. If this violates seperation, how can I get 
around that? Assuming I will have to do these checks in the templates, I 
could stuff each capability into the template so I could check for it. 
If ST supported sets I could stuff the set into the template and check 
that way.

-Nate


Terence Parr wrote:
> 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
>
> _______________________________________________
> stringtemplate-interest mailing list
> stringtemplate-interest at antlr.org
> http://www.antlr.org:8080/mailman/listinfo/stringtemplate-interest
>