[stringtemplate-interest] support for set

[Kay Roepke]

On 11. Dec 2006, at 22:06 , Nate wrote:

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

Having done (and doing) my fair share of big webapps, I thought I  
chime in
late :)
At my current work, we have pretty much the system you describe. Our  
template
solution is much like ST, but has tuned for our specific needs, e.g.  
we have
notation for URL, JavaScript, HTML escaping etc. We do not allow  
method/function
calls in templates, although sometimes I feel limited by that. There  
you have it,
I said it. ;)

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

What we do is to pass in the values for each capability. This  
sometimes gets
ugly when you are reorganizing capabilites, say because the  
requirements change,
but all told the capabilities system is a pretty stable, I'd say.
For mutual permissions (think of privacy control, who gets to see  
what info), we
have programmatically defined groups (like private data, business data,
message permissions, etc.) which allow much easier handling in the  
templates.
If you structure your templates well enough, you can hide those  
checks for "user.delete"
in subtemplates (or templates included or applied or whatever the  
parlance is).
Instead of doing the check for "user.delete" where the button appears  
just do the check in
the deleteButton() template.
This of course leads to bigger controllers in the MVC pattern and  
that can make for
immensely annoying coding, but is very clean and obvious.
I've once gone the other route, too, where you can call back from the  
templates into
controller code (or effectively even into model code, if the  
formatter didn't mask those
methods - shudder). While you can write immensely powerful  
applications in a very small
amount of code and time, it's hard to maintain. It also places a  
considerable burden of
responsibility on the programmers not introduce side-effects (on  
purpose, or inadvertently).

I'm still torn between both approaches, both have their pros and  
cons. For the current
system we had to write some tools that check for "orphaned" template  
attributes after
a phase of heavy refactoring, which wasn't fun to debug.
If you pass in the attributes manually, that sometimes leads to  
entangled code, especially
if you collect the attributes in one place, as we do right now. I'd  
much rather pass around
the template, but unfortunately this isn't Java and ST, but rather  
Perl and something homegrown...
The other approach, call it the E.T. approach (homephoning  
templates), can get really nasty
if there are side-effects. In most template systems the order of  
evaluation isn't defined, so
side-effects can do their nasty thing to you.

My advice: Think hard about you organize your templates and also try  
to group capabilities in
sensible "functional" groups. You can get very far that way.

cheers,

-k
-- 
Kay Röpke
http://classdump.org/