Re: Apache::SimpleTemplate (don't do it!)
At 20:19 09.07.01 +0200, you wrote: >It's your decision, but I think you waste your time while you make all the >experiences the other had made during the last 3-5 years. I think it would >more helpfull if you help to improve the other modules (for example makeing >them easier to install etc.) >...but I know that's useless to say, mostly everybody has to write his own >templating solution... > >Gerald > >P.S. I guess we would have much better ones, if we don't have hundreds of >them all doing nearly the same ! The reason is IMHO that it is easy to write a simple template engine. It is nearly as easy as understanding one by reading docs and sources. And it is easier than understandig 3 or 4 of them to find one that matches several needs. And contributing to an existing one is the hardest. Joachim -- "... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden koennen."- Bertolt Brecht - Leben des Galilei
Re: Apache::SimpleTemplate (don't do it!)
On Mon, Jul 09, 2001 at 02:07:21PM -0400, Perrin Harkins took time to write: > > I think that CGI::FastTemplate does all of that. > > Please have a look at it, and see if everything you need is not > > already in it. > > It's a good module for CGI, since it doesn't rely on caching/compiling > techniques, just simple regex stuff. It will use a lot less RAM than tools > that compile in-line perl, because it doesn't eval anything or cache > anything. The only real downside of this module is that coding repeated > sections (loops) can't be done in-line, i.e. you have to use multiple files. > That's a bit of a pain. Yes and no. It is a simple template thing. The original poster wanted : it's either code or it's not. no added tags, etc. In CGI::FastTemplate there is no embedded code, no added tags, so it suits that need perfectly. If you want more advanced stuff (loops, code, etc...) then probably Mason, AxKit or things like that will be more of your taste. Personnally, since 2 years, CGI::FastTemplate was always enough for me. Needs are different. CGI::FastTemplate is very good for very basic needs (that is no HTML code in mod_perl handlers, but in separate files). For more advanced needs there are other solutions. -- Patrick. ``C'est un monde qui n'a pas les moyens de ne plus avoir mal.'' PGP signature
Re: Apache::SimpleTemplate (don't do it!)
On Monday 09 July 2001 20:19, Gerald Richter wrote: > > to clarify what i mean by 'simple': > > - trivial to install and to use > > That's important Tough some are easy to use and hard to install :) The latter is less important imho, when a module is hard to install it's usually justified somehow, and most of the time the community revolving around it will be prepared to help. > > - small disk footprint > > < 10 modules total. preferably 1 > > disks are cheap, so it doesn't matter if you take one or two MB To go further, I certainly wouldn't mind an app taking 500mb if it does everything I want it to do fast and well. > > - small memory footprint > > this is usually the first bottleneck i see with > > mod_perl. i don't know how big these others > > systems get, but with the high numbers of modules... > > As soon as you start to precompile the Perl code inside your template, your > memory footprint will increase and will be much more than what your module > takes. If you don't precompile the Perl code you will never get a good > performance for bigger pages. Which is why imho for anything non-trivial things must be pre-compiled, and after that one can start discussing the ways in which different modules can unload some templates to save some memory, or do various things to increase their caching. It would be great if this was handled consistently accross all templating systems so that improvements there would benefit everyone. It doesn't seem impossible given that all that's stored is some Perl code and perhaps some metadata. > > - extensibility via sub-classing. > > This makes sense, but Perl methods are not the fasted solution, so you may > decide, do you want a good design are a fast one... extensibility yes, but sub-classing is only one way to do that, and not always the best. > ...but I know that's useless to say, mostly everybody has to write his own > templating solution... Until you've written your own you can't understand just how hard it is. I'm slow so I had to write three half-baked ones before I got it, and I'm very glad I didn't release them... There are times when "release often" doesn't apply all that well :) > P.S. I guess we would have much better ones, if we don't have hundreds of > them all doing nearly the same ! Agreed, but that probably won't happen... -- ___ Robin Berjon <[EMAIL PROTECTED]> -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Change is inevitable except from a vending machine.
Re: Apache::SimpleTemplate (don't do it!)
> > to clarify what i mean by 'simple': > - trivial to install and to use That's important > - small disk footprint > < 10 modules total. preferably 1 disks are cheap, so it doesn't matter if you take one or two MB > - small memory footprint > this is usually the first bottleneck i see with > mod_perl. i don't know how big these others > systems get, but with the high numbers of modules... As soon as you start to precompile the Perl code inside your template, your memory footprint will increase and will be much more than what your module takes. If you don't precompile the Perl code you will never get a good performance for bigger pages. > - fast, with little overhead to begin with. > just because they're mod_perl, does not mean they're > fast enough. see above. > - very basic non-syntax > it's either code or it's not. no added tags, etc. That's a matter of taste > - extensibility via sub-classing. > This makes sense, but Perl methods are not the fasted solution, so you may decide, do you want a good design are a fast one... > i really think these criteria are reasonable, and that > there should be such a minimal approach available. > (i just did some quick tests against Embperl, and my > memory and speed concerns are justified.) > Before you don't have a real application that does more the "Hello World" , nothing is justified. (and I can't imagine how you have tested it with a real application, when it is a "quick test") (If you want to test against Embperl you should use 2.0b3 which is much faster then 1.3.x!) Of course I can be fast, when I do nearly nothing, but if you want to create applications, that do more then just mailing a form, you have to do a lot of things more and all those things will take time and memory, regardless if your template system does them for you, or if you reinvent them again for every web application you write. > most projects may still be better off using Embperl, > Mason, ASP, TT from the beginning. But all should not > be forced to just because others had bad experiences > when they started out with a basic templating scheme. > > i am still waiting for some direct positive feedback, > though. :) > It's your decision, but I think you waste your time while you make all the experiences the other had made during the last 3-5 years. I think it would more helpfull if you help to improve the other modules (for example makeing them easier to install etc.) ...but I know that's useless to say, mostly everybody has to write his own templating solution... Gerald P.S. I guess we would have much better ones, if we don't have hundreds of them all doing nearly the same ! - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: Apache::SimpleTemplate (don't do it!)
> I think that CGI::FastTemplate does all of that. > Please have a look at it, and see if everything you need is not > already in it. It's a good module for CGI, since it doesn't rely on caching/compiling techniques, just simple regex stuff. It will use a lot less RAM than tools that compile in-line perl, because it doesn't eval anything or cache anything. The only real downside of this module is that coding repeated sections (loops) can't be done in-line, i.e. you have to use multiple files. That's a bit of a pain. - Perrin
Re: Apache::SimpleTemplate (don't do it!)
On Mon, Jul 09, 2001 at 12:00:58PM -0400, [EMAIL PROTECTED] took time to write: > to clarify what i mean by 'simple': > - trivial to install and to use > - small disk footprint > < 10 modules total. preferably 1 > - small memory footprint > this is usually the first bottleneck i see with > mod_perl. i don't know how big these others > systems get, but with the high numbers of modules... > - fast, with little overhead to begin with. > just because they're mod_perl, does not mean they're > fast enough. > - very basic non-syntax > it's either code or it's not. no added tags, etc. > - extensibility via sub-classing. I think that CGI::FastTemplate does all of that. Please have a look at it, and see if everything you need is not already in it. CGI::FastTemplate 1 module, very fast, no syntax (no loop, etc...), should be subclassable but what for ? I am just using it for years with CGI first and now with mod_perl without any problems whatsoever. My two euro cents. -- Patrick. ``C'est un monde qui n'a pas les moyens de ne plus avoir mal.''
Re: Apache::SimpleTemplate (don't do it!)
>hi, i'm sure many of us have had situations like this, >but that doesn't mean that everyone who wants to do >some templating is going to fall into the same trap >every time. The problem is that not every feature comes off looking like a trap. >- trivial to install and to use It's rare that I need to do anything more than 'perl Makefile.PL && make && make install' when I install modules. If I use CPAN.pm, it's even easier. Installation of any perl module trivial (under Un*x, at least). >- small disk footprint I can't remember the last time I had a "disk space" problem because of a perl module. It's not like we're talking about Megs of disk space (TT might come close). 2 gigs will hold all of RH 7.0 (including X) and any perl modules you could possibly want. >- small memory footprint At current memory prices (128 MB for $25), I consider this point very weak. I use about 300 modules within my system, and the total size of the httpd is 30 MB. On a system with 1 GB of RAM, I can run about 200 processes easily. Most people don't have 300 modules, so I suspect httpd to be much smaller. >- fast, with little overhead to begin with. You don't use a templating system because it's fast. You use it because it's faster to develop. It's the same reason people choose to use Perl instead of C. >- very basic non-syntax I'm a little confused by this one There are templating system like Mason that have their own tags ([+ +]) and systems like Text::Template that use style tags. Both are pretty easy for programmers to understand, but designers (the people using the templating system) will probably find Text::Template simpler and easier to learn and use. >- extensibility via sub-classing. This is notably where many templating systems come up short. I think TemplateToolkit provides the most flexibility in this area. Text::Template, while not sub-classable, is easily wrapped. I'm not trying to suggest that what you've written isn't "worthy." I'm only making a point about templating systems. If your goal is to write a templating system, you shouldn't just look at what already exists and strip out the stuff you feel isn't important. If you really want to help, you should consider contributing to existing templating systems to find the happy medium you're looking for. Robert Landrum -- "A good magician never reveals his secret; the unbelievable trick becomes simple and obvious once it is explained. So too with UNIX."
Re: Apache::SimpleTemplate (don't do it!)
hi, i'm sure many of us have had situations like this, but that doesn't mean that everyone who wants to do some templating is going to fall into the same trap every time. to clarify what i mean by 'simple': - trivial to install and to use - small disk footprint < 10 modules total. preferably 1 - small memory footprint this is usually the first bottleneck i see with mod_perl. i don't know how big these others systems get, but with the high numbers of modules... - fast, with little overhead to begin with. just because they're mod_perl, does not mean they're fast enough. - very basic non-syntax it's either code or it's not. no added tags, etc. - extensibility via sub-classing. i really think these criteria are reasonable, and that there should be such a minimal approach available. (i just did some quick tests against Embperl, and my memory and speed concerns are justified.) most projects may still be better off using Embperl, Mason, ASP, TT from the beginning. But all should not be forced to just because others had bad experiences when they started out with a basic templating scheme. i am still waiting for some direct positive feedback, though. :) peter
Re: Apache::SimpleTemplate (don't do it!)
>Yes. Writing a templating system in Perl is trivial. Writing a >*useful* templating system in Perl is demonstratably hard. I too have written a templating system. About a year ago I wrote a simple module called dbq.pm. It performed database queries. Basically, you could mock up a simple html page, add some special dbq tags, and it would run queries against the database. I wrote it to see if I could write a simple version of ColdFusion It took 90 minutes to write on a saturday night. On monday morning, I made the mistake of showing it to my boss. He made it is personal quest to try to rewrite parts of our existing CGI system using this 90 minute version of ColdFusion. As his quest continued, he found that there were certain features that were not present. It was quickly made a "company project," and new features (such as the ability to interface with our existing widget and api modules) were added. Then we switched to using XHTML. Everything had to be compliant. We started using Expat. DBQ (now XML::DBQ) started core dumping mysteriously. We traced everything to a problems with the (then unstable) Expat libraries. So we rewrote the XML parser using native perl. Since we now had full control over the parser, we found we could add new features (like if else constructs and defines). Then we added the ability to execute internal perl functions (like substr). Our quest was still not over, and we continued to add more features. And it is now that we realize that we have written a system that is 3 times slower than CGI, 8 times slower than mod_perl, 10 times more difficult to read than perl, and is being used in about 45% of our site. The moral of this story is that using an existing templating system will save you more hours of coding, learning, debugging, upgrading, adding new features, and maintaining than you could possibly hope to account for when writing a "Simple" templating system. I hope this helps answer any questions about why you should not write your own templating system. Robert Landrum