Ok. I need to step back and explain a few things. When I design security models, I use authorities. They're similar to roles, but finer-grained. A reasonable system could have hundreds of these things, each permitting or denying the right to do XYZ. I then provide for groups that would correspond more closely to roles. So, you'd have an "Admin", "Supervisor", "User", "Manager", etc. Then, because my management always tends to be stupid, the Supervisor from XYZ region needs just one more authority than the Supervisor from ABC region. So, I build "XYZ Supervisor" based on "ABC Supervisor" + the one extra authoritiy.

Now, all of this is encapsulated in the $user object. $user provides a very rich interface, allowing me to ask it pretty much anything and it will respond correctly. Hundreds and hundreds of different method calls, most of which will never be used any template.

What this has to do with templating is simple. The $user object will be used serverside to prevent a user from doing something they're not allowed to do. But, you never want to present a user with an option they can't do, so you need to only display things they're allowed to do. Conversely, you have to present everything they can do, otherwise they can't do it.

Furthermore, because my management is stupid, they say "A user can do Foo if they have A, B, and C authorities." So, I can either create an intermediate role or I can do the conjunction wthin the template.

<TMPL_IF AUTH_A>
    <TMPL_IF AUTH_B>
        <TMPL_IF AUTH_C>
            <TMPL_INCLUDE FOO>
        </TMPL_IF>
    </TMPL_IF>
</TMPL_IF>
[download]

Oh, crap. That not only doesn't work, but it's really hard to read.

[% IF $user->auth(A) && $user->auth(B) && $user->auth(C) %]
    [% INCLUDE foo user = $user %]
[% END %]
[download]

As for filters ... I don't want to write Perl code to parse H::T directives in order to dynamically do includes. I've done that before and it's unmaintainable in the larger cases.

Sam - I reach for H::T before reaching for anything else. I maintain PDF::Template and Excel::Template which I consider to be the "friends of H::T." They take the same data structures and provide identical interfaces. I use H::T for more than just HTML, too, such as defining developer environments.

But, when you developed H::T as a reaction to TT1, you chose to make some design tradeoffs. TT has a richer syntax and is slower. H::T is much much faster, but it's more spartan. Because of this, it's easier to manage large complex applications in TT than it is to do so in H::T, and that is a good thing. Sometimes you need a Honda Insight and sometimes you need a F-150 Supercab. One isn't better than the other - they are both the best at what they do, and that's good.

I may have jumped the gun a little when I suggested TT as my first reply, but sessions and session management imply, to me, a security model with authorities and roles and ... So, I overthink things a little ... is that a crime?? :-)