(First off, let me say that I'm a long time H::T user, occasional TT dabbler. I love what you've done with the place, samtregar.)
You can associate, but you have two problems, neither of which are solvable with the H::T syntax.
- You are going to litter your templates with a huge number of <TMPL_IF CONFIG_FOO_1> type statements.
- If you associate more than two objects, collisions are a very real possibility, especially if you associate your $cgi and $config objects at the same time.
The alternative that TT provides is a method-like invocation on your objects. Plus, you have run-time includes, which H::T (AFAIK) does not support. This is much easier to work with.
- 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] |
You are going to litter your templates with a huge number of <TMPL_IF CONFIG_FOO_1> type statements.
And? You need conditional behavior, you use a tmpl_if. I don't see a problem here.
If you associate more than two objects, collisions are a very real possibility, especially if you associate your $cgi and $config objects at the same time.
So use one of the other two solutions I presented, or don't associate your query object. I don't do that much anymore personally - it's too hard to police.
The alternative that TT provides is a method-like invocation on your objects.
So you like your syntactic sugar. I get it. What does this have to do with session handling?
Plus, you have run-time includes, which H::T (AFAIK) does not support.
If you can't figure out how to do this with HTML::Template's filter option then you need to try a little harder!
-sam
PS: When do you want me to break out the benchmarks? You know they're coming!
| [reply] |
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] |