Re: Apache::SimpleTemplate (don't do it!)

2001-07-10 Thread Patrick

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!)

2001-07-10 Thread Joachim Zobel

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!)

2001-07-09 Thread peter


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!)

2001-07-09 Thread Robert Landrum

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 HTML 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!)

2001-07-09 Thread Patrick

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!)

2001-07-09 Thread Perrin Harkins

 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!)

2001-07-09 Thread Gerald Richter


 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!)

2001-07-09 Thread Robin Berjon

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. dreamIt 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./dream

  - 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!)

2001-07-08 Thread Robert Landrum

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