Rodney Hampton wrote:
Like an eval, or a subroutine call? Either way, this is all covered by most of the other systems. Even Apache::SSI can do this.I really only need 3 tags: one to link the templates together, one to bring in images, and one to call code that can by dynamically inserted.
The only one that has built-in caching of results is Mason, and it won't do it unless you tell it to. All other references to caching mean caching the template parsing. That wouldn't be an issue for this.Every item in my application's database (templates, images, and other files) has user and group permissions that need to be checked on access. Thus, any templating system that did caching is pretty much out of the running because as soon as I revoke a user's privileges or change permissions on the item, I want access to change immediately.
I'm guessing from your previous post that these things are accessed by calling a subroutine from the templates, and the subroutine does the access checking. That should be no problem.
All of them handle that. They check for changes, usually by stat-ing the template files.Also, when an advertiser makes a change to one of his/her templates, it needs to propogate immediately.
Session tracking has nothing to do with templates. Systems like Embperl and Apache::ASP (and now Mason) integrate it, but that's because they are much more than just template systems. With a typical pipeline arhcitecture, you would handle the session in your code and then pass the data (including whatever session data you need) off to the template.Additionally, I need to track users so I had to be able to establish and maintain a session so this was a definate requirement.
Access control also has nothing to do with templates. You can use something like Apache::AuthCookie for this, or you can handle it directly in your perl code.Also, I needed to be able to selectively protect certain areas of the application with login screens (not necessarily the same one depending on where you navigate).
It's easy to write a fast templating system. What's hard is writing a fast templating system that has no bugs, and can adapt to future needs. It doesn't take long before you find you need more features: whitespace control, a more powerful if/else construct, a way to format dates, etc. That's why the modules on CPAN seem big. They have been extended to handle most of the real-world problems that people need to solve with templating systems.I've done some benchmarking on what I've built already and am satisfied with the results.
I'm pretty sure that there are modules on CPAN that do just what you need. If you already have a working system, then go with it. If you find yourself having to revisit the code because you need to add things or are finding bugs or performance problems, consider benefitting from someone else's hard work.Anyway, I'm not trying to say that what I'm doing is better or worse than what has come before. I just happen to have different requirements and I didn't think that the other systems out there were going to be both lightweight and allow me to meet my need for access control.
- Perrin
