PS: When do you want me to break out the benchmarks? You know they're coming!
Benchmarkes of H::T vs TT? Yes please!
| [reply] |
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>
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 %]
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?? :-)
- In general, if you think something isn't in Perl, try it out, because it usually is. :-)
- "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
| [reply]
[d/l]
[select] |
<tmpl_if can_foo>foo</tmpl_if>
Then I'd move all that complex AND logic into Perl where it belongs. There's no reason your security policy should be embedded in your templates!
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??
It's not a crime, merely a disservice. The poster sounds like a novice to me and it's not nice to stear him towards a complex solution that he probably doesn't need. Just because he wants sessions doesn't mean he needs an overly complex authority system like you!
-sam
| [reply]
[d/l]
[select] |
| [reply] |
(We might be getting a bit further afield than needs done in this thread, but ...)
Then I'd move all that complex AND logic into Perl where it belongs. There's no reason your security policy should be embedded in your templates!
The security policy shouldn't be; the logic determining what gets displayed where should. That the latter implements a portion of the former is no fault of the templating system - it's a fault of management stupidity, but that's still a reality for too many developers. *cues up "Let My People Go"*
- In general, if you think something isn't in Perl, try it out, because it usually is. :-)
- "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
| [reply] |