Rodney Hampton wrote:
Perrin, Danny, et. al.
I looked over the comparison document as well as the perldocs on all
the templating systems I could find on CPAN before embarking on this
journey.
I'll add in how Apache::ASP can be used to solve this problem...
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. Every item in my application's database (templates,
images, and other files) has user and group permissions that need to
Apache::ASP lets you define custom tags like:
<my:link_name type="template_faq" /> instead of <% link_name template_faq %>
<my:img_src val="some_image" /> instead of <% img_src_name some_image %>
These tags get rendered by subroutines you define my::link_name and my::img_src.
You can use global.asa Script_OnStart to do all the database handle setup
work to make this easily accessible to your XMLSubs ( the name of this tagging feature ).
Of course, maybe more like what you have now, in Apache::ASP, its easy to
also do:
<% &link_name("template_faq"); %>
but I personally like the XMLSubs approach because it takes a more
content oriented approach to your pages, than embedding code.
The trick to making easy local subs for all your pages is to define
these subs in your global.asa, which is the package all of your pages
are compiled into.
>>> 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
Apache::ASP does do output caching of includes only when explicitly
asked for, see:
http://www.apache-asp.org/objects.html#%24Response-%3EIa3beea1e
This is only for performance optimization, so you do not have to worry
about caching otherwise.
need to track users so I had to be able to establish and maintain a
session so this was a definate requirement. 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
Like other systems session management has been built into Apache::ASP
from the get go ( one of the reasons I started work on Apache::ASP ).
In that system, its the $Session object.
navigate). This is the underlying architecture for a client I have
but I intend to make it modular enough to use for future projects.
I've done some benchmarking on what I've built already and am
satisfied with the results. I seem to be able to serve up 30
concurrent connections sending dynamic content all day long and have
it sever between 25-35 requests per second at around 300 - 375
Kbytes/sec. I've compiled mod_perl with DSO and it's never shown any
For other benchmarking of the various web app environments you could
use, check out http://chamas.com/bench/
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.
As others have asserted, I believe if you look at the other systems
hard enough, you will find many others that can fill your requirements.
Regards,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
