Re: Feature sets [was Re: Templating System]
On 3 Aug 2000, (Randal L. Schwartz) wrote: "Drew" == Drew Taylor [EMAIL PROTECTED] writes: Drew I suppose I could... I was planning on having a nice checklist of Drew features/systems that would be a pain to do in a fixed width font. An Drew HTML table would make my life MUCH easier there. Is there something in Drew POD that makes tables easier? Why don't you write it as XML, then use Template::Toolkit and the DOM interface to generate what you want. Or XML::Simple with TT... Anyway, I've got a Pod::DocBookXML here somewhere if you want it. That would allow all authoring in POD, with =for docbook sections doing the tables. (of course you could do that with HTML too). -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Feature sets [was Re: Templating System]
On Thu, 3 Aug 2000, Gunther Birznieks wrote: At 05:10 PM 8/3/00 -0700, Perrin Harkins wrote: On Thu, 3 Aug 2000, Drew Taylor wrote: Having recently discovered the joy of CVS, I look forward to it. Awfully nice to able to roll back to a previous version - although (knock on wood!) I haven't had to use it yet. I can help if you get stuck. One book I would highly recommend on CVS is Open Source Development with CVS by Karl Franz Fogel. I found it to be not only highly informative but an incredibly fun read as well. Each of the semi-dry CVS chapters is followed up by a fun anecdotal chapter about open source development processes and how and why they work (esp focusing if possible on how CVS helps that process). I've also found it to be a better "advanced" reference than any of the CVS documentation I have. Somehow it just "feels" indexed better. I own no stock in Coriolis Books by the way. :) And its available free online: http://cvsbook.red-bean.com/ -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Feature sets [was Re: Templating System]
At 08:03 AM 8/4/00 +0100, Matt Sergeant wrote: On Thu, 3 Aug 2000, Gunther Birznieks wrote: At 05:10 PM 8/3/00 -0700, Perrin Harkins wrote: On Thu, 3 Aug 2000, Drew Taylor wrote: Having recently discovered the joy of CVS, I look forward to it. Awfully nice to able to roll back to a previous version - although (knock on wood!) I haven't had to use it yet. I can help if you get stuck. One book I would highly recommend on CVS is Open Source Development with CVS by Karl Franz Fogel. I found it to be not only highly informative but an incredibly fun read as well. Each of the semi-dry CVS chapters is followed up by a fun anecdotal chapter about open source development processes and how and why they work (esp focusing if possible on how CVS helps that process). I've also found it to be a better "advanced" reference than any of the CVS documentation I have. Somehow it just "feels" indexed better. I own no stock in Coriolis Books by the way. :) And its available free online: http://cvsbook.red-bean.com/ Not all chapters are free. Just the CVS related ones (the other ones kind of make the whole subject more pleasurable to read about YMMV). -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
Re: Feature sets [was Re: Templating System]
I hope that you write the doc is POD :) I suppose I could... I was planning on having a nice checklist of features/systems that would be a pain to do in a fixed width font. An HTML table would make my life MUCH easier there. Is there something in POD that makes tables easier? Write the text in POD, and put the checklist data in with some neutral format. Then we can use a customized pod2html converter on it to generate a pretty table. XML would be a nice way to store the raw data. This might end up being kind of big for an in-line, so we could do something like "=table data_file.xml" and keep it in a separate file. (Or is it better to use "=for html" and put the rest inside that, so that it still passes syntax checks for standard POD?) I believe XML is a way too heavy for docs writing. Why one will want to get a messy source code, when you can get away with a minimalistic POD. Just look at the Guide's source code and look at the generated PDF -- isn't it great? I love POD. And if you want more than POD provides, it takes secs to add the new functionality. Stas, do you have code available for the guide generator? That might come in handy. The guide building code was completely rewritten lately. Now it uses HTML templates (+css) to customize the look and feel, so if you want to roll your own documentation project you don't have to touch the code anymore. The html2ps translator is bundled in distribution, so there is no installation overhead, just grab the package from CPAN: cpan install mod_perl_guide If there will be enough interest, I'll release the package as a standalone in the future. As for POD, I've already extended the POD in POD2HTML (which was buggy anyway). For example, I've added new directives for embedding images, linking to files and more... I don't afraid to extend the POD since I can easily convert all my extended pod files back into the standard POD format. So if you want a syntax for tables, this should be easy to add, like: =table args =tr args =td args ... =/td =/tr =/table Drew, if this all sounds like too much trouble for the first draft and you already started in HTML, I'd say just finish that up and we'll distill it into POD later. (html2pod?) Not a good idea :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: Feature sets [was Re: Templating System]
Gunther Birznieks ([EMAIL PROTECTED]) said something to this effect: One book I would highly recommend on CVS is Open Source Development with CVS by Karl Franz Fogel. I found it to be not only highly informative but an incredibly fun read as well. Each of the semi-dry CVS chapters is followed up by a fun anecdotal chapter about open source development processes and how and why they work (esp focusing if possible on how CVS helps that process). I've also found it to be a better "advanced" reference than any of the CVS documentation I have. Somehow it just "feels" indexed better. I own no stock in Coriolis Books by the way. :) Most of this book is available from http://cvsbook.red-bean.com/ (all except chapters 1,3,5, and 7), for those of you who aren't familiar is CVS. The site contains the book in HTML, Info, Texinfo, and Postscript format, and you can get the working copy vis anonymous CVS, also. (darren) -- Tell a man that there are 400 Billion stars and he'll believe you. Tell him that a bench has wet paint and he has to touch it.
Re: Feature sets [was Re: Templating System]
On Fri, 4 Aug 2000, Stas Bekman wrote: I hope that you write the doc is POD :) I suppose I could... I was planning on having a nice checklist of features/systems that would be a pain to do in a fixed width font. An HTML table would make my life MUCH easier there. Is there something in POD that makes tables easier? Write the text in POD, and put the checklist data in with some neutral format. Then we can use a customized pod2html converter on it to generate a pretty table. XML would be a nice way to store the raw data. This might end up being kind of big for an in-line, so we could do something like "=table data_file.xml" and keep it in a separate file. (Or is it better to use "=for html" and put the rest inside that, so that it still passes syntax checks for standard POD?) I believe XML is a way too heavy for docs writing. Why one will want to get a messy source code, when you can get away with a minimalistic POD. Just look at the Guide's source code and look at the generated PDF -- isn't it great? I love POD. And if you want more than POD provides, it takes secs to add the new functionality. People are migrating to XML because there are good editors coming onto the market (though sadly none for Linux yet, but I'm getting close to persuading Arbotext to port Adept to Linux...). The editors hide the complexity and you never need to see the source code. But its there if you need it (unlike Word, for example). As for POD, I've already extended the POD in POD2HTML (which was buggy anyway). For example, I've added new directives for embedding images, linking to files and more... I don't afraid to extend the POD since I can easily convert all my extended pod files back into the standard POD format. So if you want a syntax for tables, this should be easy to add, like: =table args =tr args =td args ... =/td =/tr =/table Ugh... I believe SDF has better support for tables, without resorting to nastiness like that. I think if you like POD, you'll love SDF, Stas. http://www.mincom.com/mtr/sdf/ -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: [doc writing] (was Re: Feature sets [was Re: Templating System])
On Fri, 4 Aug 2000, Stas Bekman wrote: People are migrating to XML because there are good editors coming onto the market (though sadly none for Linux yet, but I'm getting close to persuading Arbotext to port Adept to Linux...). The editors hide the complexity and you never need to see the source code. But its there if you need it (unlike Word, for example). Well, this is a whole different story :) Once there will be such an editor, things will be much better. Well the tools are now pretty nice for Windows. But you forget about the benefits of the source code editing, which is diff and tools working with it. Surely enough big editors support their own diff formats and tools, but they aren't possessed by many people. And with POD everybody has a text editor :) As with XML :) Ugh... I believe SDF has better support for tables, without resorting to nastiness like that. I think if you like POD, you'll love SDF, Stas. http://www.mincom.com/mtr/sdf/ Thanks for the link, Matt. I've seen this technology a while ago. The reason that I didn't use it, is that it's a much bigger superset of syntax that I need. If all I miss is a tables formatting, I'd rather add this support than go for a complete format change. I wonder if it would be easy to rip the table support out of SDF and use that, rather than change completely to SDF. I find table support to be POD's only real severe weakness. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Feature sets [was Re: Templating System]
Stas Bekman wrote: I believe XML is a way too heavy for docs writing. Why one will want to get a messy source code, when you can get away with a minimalistic POD. Just look at the Guide's source code and look at the generated PDF -- isn't it great? I love POD. And if you want more than POD provides, it takes secs to add the new functionality. I agree. XML has a nice "cool" factor, but I want to make this guide as simple as possible. As for POD, I've already extended the POD in POD2HTML (which was buggy anyway). For example, I've added new directives for embedding images, linking to files and more... I don't afraid to extend the POD since I can easily convert all my extended pod files back into the standard POD format. So if you want a syntax for tables, this should be easy to add, like: =table args =tr args =td args ... =/td =/tr =/table That might be a useful extension. How do you do tables now? "=for html"? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
On 2 Aug 2000, (Randal L. Schwartz) wrote: "Ron" == Ron Pero [EMAIL PROTECTED] writes: Ron A few days ago I sent this suggestion to Drew Taylor, who is Ron preparing a web page comparing the templating systems. He said he Ron likes the idea. The Categorical "Congratulations: you wrote a Ron templating system!" web memorial. Wow, if making suggestions here gets that kind of immediate results, let me also suggest I need a girlfriend who is travel-compatible and email friendly. Maybe one will show up. :) Not with your dancing :-P Or do you get only one wish per quarter? :) The genie is back in the bottle now :) -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Feature sets [was Re: Templating System]
"Randal L. Schwartz" wrote: "Ron" == Ron Pero [EMAIL PROTECTED] writes: Ron A few days ago I sent this suggestion to Drew Taylor, who is Ron preparing a web page comparing the templating systems. He said he Ron likes the idea. The Categorical "Congratulations: you wrote a Ron templating system!" web memorial. Wow, if making suggestions here gets that kind of immediate results, let me also suggest I need a girlfriend who is travel-compatible and email friendly. Maybe one will show up. :) Or do you get only one wish per quarter? :) Sorry, it's one wish per _year_. I'm a little slow that way. ;-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Ken Williams wrote: [EMAIL PROTECTED] (Gunther Birznieks) wrote: I am afraid that while I agree, a check system is really quite useful to me. Some things do need more quantification, but that can be done later. eg lightweight vs heavyweight is subjective. But it can be broken up into saying something like how much code needs to be loaded at start time (an issue for CGI/Perl). eg I think people would agree that the startup of CGI.pm is different from CGI::Lite which is different from cgi-lib.pl. Of course, there are many other features that you get from them that can make a difference in your program. Anyway, that is why this checklist is being designed by all of you and handled by an independent 3rd party. It's not a marketing tool. So if you complain about session support being a checkbox, I am sure that the feature name could be refined. I agree. I came up with an initial set of checkboxes (posted here last week), but I'd have no qualms about some author wanting to ditch some of those. I think a useful comparison would use feature comparisons only as a means of revealing the comparitive philosophies of the systems. I think splitting the systems into tiers (simple, average, framework) will also help to solve this problem. And of course, the feature checklist will be a continually evolving creature. Gunther, has anyone found a good home for such a comparison to be hosted? It would be cool if it were at perl.apache.org, or even better at www.perl.com or something (since it's not mod_perl specific). As long as it's easily updatable by its maintainers (and who are they?). Excellent question. I was planning to initially host the document on my home page. But I'm sure that wouldn't last for too long. I guess the initial maintainer would be me, but I would have no problem expanding that list in the future. Which brings up the question - how would it be maintained? CVS? I'm all ears... -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
I think splitting the systems into tiers (simple, average, framework) will also help to solve this problem. And of course, the feature checklist will be a continually evolving creature. Absolutely agree. There is no reason to reinvent the wheel. I don't see why a complete app server system couldn't be put together in such a way as to allow the use of the individual technologies on their own. It would be one of the rare circumstances where the sum of the parts was equal to the whole. -- __ Mr. Erich L. Markert [EMAIL PROTECTED] Computer Learning Center TEL (914)422-4328 Pace University 1 Martine Ave White Plains, New York 10606-1932 Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer
Re: Feature sets [was Re: Templating System]
Ron Pero wrote: [cut] * Place the templating systems into a spectrum of categories, from simplest to most complex/developed. It would look approximately like this (not attempting to be complete): -Level one, simplest * Simple tag/anchor replacement * Embedded code evaluation -Level two, complete templating, but templating only * HTML::Template * Template Toolkit * HTML - Tree (??) -Level three, templating plus (added features such as session management, database integration, etc.) * Apache::ASP * Embperl * HTML::Mason * AxKit Perhaps the other dimension could be whether it is based on browsing a page that calls Perl, or invoking a Perl script that brings in a page. Then you'd have a nice 2D grid that I would think would impart a lot of information at a glance. Not that there aren't products that would go into more than one cell. Another thing to note would be whether the product is useful for generating static pages, like Template Toolkit, and (I'm sure) others.
Re: Feature sets [was Re: Templating System]
On Thu, 3 Aug 2000, Perrin Harkins wrote: On Thu, 3 Aug 2000, Drew Taylor wrote: Gunther, has anyone found a good home for such a comparison to be hosted? It would be cool if it were at perl.apache.org, or even better at www.perl.com or something (since it's not mod_perl specific). As long as it's easily updatable by its maintainers (and who are they?). Excellent question. I was planning to initially host the document on my home page. But I'm sure that wouldn't last for too long. I guess the initial maintainer would be me, but I would have no problem expanding that list in the future. Which brings up the question - how would it be maintained? CVS? I'm all ears... Let's create a http://sourceforge.net project for it, which will give us an instant CVS and mailing list (for people working on the documents), and allow everyone to see the work in progress. Once it's together, we can figure out how to get onto perl.com and/or perl.apache.org. Documentation maintenance is a different process from code maintenance. I'm telling this on the base of working on the guide in the last 1.5 years. The maintainer is responsible for keeping the document clean and consistent. Therefore it really makes things better if there is an owner of the documentation project and people submitting the patches to him or her. Drew, once you get an initial doc, we will give you a CVS access to the modperl-site repository, which is given to all people who do significant contribution to the project. It shouldn't take a long time. If in the future you will not be able to maintain someone else would do that, so there is no problem with that. Forking the project onto another server isn't really a good idea. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: Feature sets [was Re: Templating System]
Stas Bekman wrote: On Thu, 3 Aug 2000, Perrin Harkins wrote: On Thu, 3 Aug 2000, Drew Taylor wrote: Gunther, has anyone found a good home for such a comparison to be hosted? It would be cool if it were at perl.apache.org, or even better at www.perl.com or something (since it's not mod_perl specific). As long as it's easily updatable by its maintainers (and who are they?). Excellent question. I was planning to initially host the document on my home page. But I'm sure that wouldn't last for too long. I guess the initial maintainer would be me, but I would have no problem expanding that list in the future. Which brings up the question - how would it be maintained? CVS? I'm all ears... Let's create a http://sourceforge.net project for it, which will give us an instant CVS and mailing list (for people working on the documents), and allow everyone to see the work in progress. Once it's together, we can figure out how to get onto perl.com and/or perl.apache.org. Documentation maintenance is a different process from code maintenance. I'm telling this on the base of working on the guide in the last 1.5 years. The maintainer is responsible for keeping the document clean and consistent. Therefore it really makes things better if there is an owner of the documentation project and people submitting the patches to him or her. Drew, once you get an initial doc, we will give you a CVS access to the modperl-site repository, which is given to all people who do significant contribution to the project. It shouldn't take a long time. Sounds great. Hopefully I will be able to have a first version out this weekend. I have been slammed at work this week, so I'll most likely be doing the writing on my personal time. I'll post when where the first draft will be located. After that we can talk CVS. BTW, you probably don't remember me, but we briefly met at ApacheCon and I attended your mod_perl classes there (and enjoyed them). :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Stas Bekman wrote: On Thu, 3 Aug 2000, Perrin Harkins wrote: On Thu, 3 Aug 2000, Drew Taylor wrote: Gunther, has anyone found a good home for such a comparison to be hosted? It would be cool if it were at perl.apache.org, or even better at www.perl.com or something (since it's not mod_perl specific). As long as it's easily updatable by its maintainers (and who are they?). Excellent question. I was planning to initially host the document on my home page. But I'm sure that wouldn't last for too long. I guess the initial maintainer would be me, but I would have no problem expanding that list in the future. Which brings up the question - how would it be maintained? CVS? I'm all ears... Let's create a http://sourceforge.net project for it, which will give us an instant CVS and mailing list (for people working on the documents), and allow everyone to see the work in progress. Once it's together, we can figure out how to get onto perl.com and/or perl.apache.org. Documentation maintenance is a different process from code maintenance. I'm telling this on the base of working on the guide in the last 1.5 years. The maintainer is responsible for keeping the document clean and consistent. Therefore it really makes things better if there is an owner of the documentation project and people submitting the patches to him or her. Drew, once you get an initial doc, we will give you a CVS access to the modperl-site repository, which is given to all people who do significant contribution to the project. It shouldn't take a long time. Sounds great. Hopefully I will be able to have a first version out this weekend. I have been slammed at work this week, so I'll most likely be doing the writing on my personal time. I'll post when where the first draft will be located. After that we can talk CVS. Sure, no problem. One of the current cvs access holders can commit the first release for you, and then you will be able to continue by yourself. Obviously getting all the support that you might need on the way. I hope that you write the doc is POD :) BTW, you probably don't remember me, but we briefly met at ApacheCon and I attended your mod_perl classes there (and enjoyed them). :-) :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: Feature sets [was Re: Templating System]
[this goes off the list] BTW, you probably don't remember me, but we briefly met at ApacheCon and Do you have a picture online. I'm sure I'll recall once I see you again! I attended your mod_perl classes there (and enjoyed them). :-) Thanks a lot! 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/ Man, why didn't you tell us that you live in Charlotte! We have spent about 7 hours in Charlotte twice on our way to and from the Perl conference 2 weeks ago. We were bored to death as our plane was late... twice :( Are you coming to London for YAPC or ApacheCon? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: Feature sets [was Re: Templating System]
I apologize, I forgot to strip the list's address when sending this. On Thu, 3 Aug 2000, Stas Bekman wrote: [this goes off the list] ...snipped... _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: Feature sets [was Re: Templating System]
Stas Bekman wrote: Sure, no problem. One of the current cvs access holders can commit the first release for you, and then you will be able to continue by yourself. Obviously getting all the support that you might need on the way. Having recently discovered the joy of CVS, I look forward to it. Awfully nice to able to roll back to a previous version - although (knock on wood!) I haven't had to use it yet. I hope that you write the doc is POD :) I suppose I could... I was planning on having a nice checklist of features/systems that would be a pain to do in a fixed width font. An HTML table would make my life MUCH easier there. Is there something in POD that makes tables easier? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
On Thu, 3 Aug 2000, Drew Taylor wrote: Having recently discovered the joy of CVS, I look forward to it. Awfully nice to able to roll back to a previous version - although (knock on wood!) I haven't had to use it yet. I can help if you get stuck. I hope that you write the doc is POD :) I suppose I could... I was planning on having a nice checklist of features/systems that would be a pain to do in a fixed width font. An HTML table would make my life MUCH easier there. Is there something in POD that makes tables easier? Write the text in POD, and put the checklist data in with some neutral format. Then we can use a customized pod2html converter on it to generate a pretty table. XML would be a nice way to store the raw data. This might end up being kind of big for an in-line, so we could do something like "=table data_file.xml" and keep it in a separate file. (Or is it better to use "=for html" and put the rest inside that, so that it still passes syntax checks for standard POD?) Stas, do you have code available for the guide generator? That might come in handy. Drew, if this all sounds like too much trouble for the first draft and you already started in HTML, I'd say just finish that up and we'll distill it into POD later. (html2pod?) - Perrin
Re: Feature sets [was Re: Templating System]
Perrin Harkins wrote: On Thu, 3 Aug 2000, Drew Taylor wrote: Having recently discovered the joy of CVS, I look forward to it. Awfully nice to able to roll back to a previous version - although (knock on wood!) I haven't had to use it yet. I can help if you get stuck. I hope that you write the doc is POD :) I suppose I could... I was planning on having a nice checklist of features/systems that would be a pain to do in a fixed width font. An HTML table would make my life MUCH easier there. Is there something in POD that makes tables easier? Write the text in POD, and put the checklist data in with some neutral format. Then we can use a customized pod2html converter on it to generate a pretty table. XML would be a nice way to store the raw data. This might end up being kind of big for an in-line, so we could do something like "=table data_file.xml" and keep it in a separate file. (Or is it better to use "=for html" and put the rest inside that, so that it still passes syntax checks for standard POD?) sounds like we need a good templating system to do this for us. anyone know a good templating system? sorry - couldn't resist. :-)) Stas, do you have code available for the guide generator? That might come in handy. Drew, if this all sounds like too much trouble for the first draft and you already started in HTML, I'd say just finish that up and we'll distill it into POD later. (html2pod?) - Perrin -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
Re: Feature sets [was Re: Templating System]
"Drew" == Drew Taylor [EMAIL PROTECTED] writes: Drew I suppose I could... I was planning on having a nice checklist of Drew features/systems that would be a pain to do in a fixed width font. An Drew HTML table would make my life MUCH easier there. Is there something in Drew POD that makes tables easier? Why don't you write it as XML, then use Template::Toolkit and the DOM interface to generate what you want. /me shows hint of bias :-) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Feature sets [was Re: Templating System]
At 05:10 PM 8/3/00 -0700, Perrin Harkins wrote: On Thu, 3 Aug 2000, Drew Taylor wrote: Having recently discovered the joy of CVS, I look forward to it. Awfully nice to able to roll back to a previous version - although (knock on wood!) I haven't had to use it yet. I can help if you get stuck. One book I would highly recommend on CVS is Open Source Development with CVS by Karl Franz Fogel. I found it to be not only highly informative but an incredibly fun read as well. Each of the semi-dry CVS chapters is followed up by a fun anecdotal chapter about open source development processes and how and why they work (esp focusing if possible on how CVS helps that process). I've also found it to be a better "advanced" reference than any of the CVS documentation I have. Somehow it just "feels" indexed better. I own no stock in Coriolis Books by the way. :) I hope that you write the doc is POD :) I suppose I could... I was planning on having a nice checklist of features/systems that would be a pain to do in a fixed width font. An HTML table would make my life MUCH easier there. Is there something in POD that makes tables easier? Write the text in POD, and put the checklist data in with some neutral format. Then we can use a customized pod2html converter on it to generate a pretty table. XML would be a nice way to store the raw data. This might end up being kind of big for an in-line, so we could do something like "=table data_file.xml" and keep it in a separate file. (Or is it better to use "=for html" and put the rest inside that, so that it still passes syntax checks for standard POD?) Stas, do you have code available for the guide generator? That might come in handy. I have to second this suggestion. Stas does make the source available to the guide generator. Download the guide from CPAN and poke around the distribution... :) We've been using it to do ALL our extropia documentation for 2 months now (actually we use a modified older version, and am waiting to get some time to upgrade since Stas has done many improvements). Does this format look familiar (albeit a little old)? http://www.extropia.com/docs/webdb/ It's really awesome. I generate standalone HTML for standalone distribution of scripts, HTML docs that integrate into the look and feel of our website, and PDF within seconds each time we make a change. :) Drew, if this all sounds like too much trouble for the first draft and you already started in HTML, I'd say just finish that up and we'll distill it into POD later. (html2pod?) Could be. Although, HTML is a pain in the ass to add onto anyway. It's a lot easier to see differences between versions of docs in POD than in HTML where you have all the formatting tags that interfere with reading diffs. Later, Gunther
Re: Feature sets [was Re: Templating System]
At 05:33 PM 8/3/00 -0700, Randal L. Schwartz wrote: "Drew" == Drew Taylor [EMAIL PROTECTED] writes: Drew I suppose I could... I was planning on having a nice checklist of Drew features/systems that would be a pain to do in a fixed width font. An Drew HTML table would make my life MUCH easier there. Is there something in Drew POD that makes tables easier? Why don't you write it as XML, then use Template::Toolkit and the DOM interface to generate what you want. One problem is deciding off the bat what you want to support in terms of XML tags. Perhaps this could resolved quickly by simply mapping the POD tags to XML from the start as a lowest common denominator format. And then also using an XML Editor that helps you conform to the DOM. I have to say that I find it much easier to write in POD because it's a lowest common denominator format right off the bat. And then generate other things from it (could even generate XML and do a transform on that I guess). From my old fogey perspective, for writing raw docs, I dislike writing XML about as much as I dislike writing direct HTML. Perhaps I dislike it even more because every XML markup is different and I hate having all the XML markups I deal with swim about my small head. I already know POD and POD is a suitable LCD language, so... Another thing that is nice about a POD format from the beginning is kind of the same thing that is nice about coding in Perl. Instant gratification. I know I can see immediately the results of my writing. As opposed to going through a compile cycle because I am already writing in one of the formats I like to read docs in. I know there are XML editors out there though that can be fed a DOM of sorts. And that could probably help that issue. Anyway, I guess for these reasons I''ve been a fan of Stas' guide generator because it's easy for me and I already know POD. Although I imagine it would be an interesting addition to the Guide Generator to make it use XML instead of POD as the basis. And who knows, maybe I am just being old by suggesting that native POD has advantages over XML... and that maybe COBOL could be used to format the tables for the feature comparison. Oops, I realize I hadn't suggested that. Yet. :) Later, Gunther
RE: Feature sets [was Re: Templating System]
I have to say that I am also interested in template kits myself. My requirements are almost identical to yours (minus a few advanced things). Basically, I write open source web applications in Perl -- that means that they must be able to run reasonably fast on non-modperl systems and must run on a variety of ISPs (ie not dedicated servers where you control the version of Perl). Of course, mod_perl support is crucial for those that want to "scale", but normal CGI/Perl support is really a biggie that I haven't seen highlighted within the context of this thread. Here are my CGI/Perl requirements: 1) Must be 100% pure Perl or support pure-Perl alternatives if certain libs arent compiled. Many people who download CGI scripts don't know how to compile stuff. 2) Must support Perl 5.004 and above. Ideal to support Perl 5.003. Enough ISPs and corporations around the world are still on 5.004 that only supporting the latest Perl version is not doable. 3) Must incur as minimal load-time as possible. CGI/Perl scripts are not cached like mod_perl scripts. So CGI/Perl people must have a template system that can choose to load a minimal amount of code if really advanced features aren't used. IE would rather not have a templating system as large as CGI.pm. Or rather it can be as large as CGI.pm, but only if the extra code is loaded when advanced features are accessed -- normal CGI/Perl users should not be penalized. 4) Must have a license that supports redistribution in other scripts. I think most of the systems out there do that (maybe all the Perl ones do). CPAN is great for us, but again, most real-world web app users are not CPAN savvy and don't have the rights to install global modules on their ISP nor the learning to install them locally. So an open source web app that takes advantage of a template system really should also contain that template system. The power users can remove it from the local dir if they have a globally installed version of the system. Anyway, I felt that I should state these feature requirements because this list is so mod_perl centric, I think sometimes we forget the "little" people. And there are many more of them out there than mod_perl servers and Perl/CPAN savvy people. RANT_IN_ADVANCEAnd please don't say that they should RTFM. Most users do not have time to RTFM. If they did, they would be us. :) These users are people who know their business and typically learn just enough tech to install something that will help their business -- they don't care or want a CS degree in the process./RANT_IN_ADVANCE Later, Gunther At 09:45 AM 8/1/00 -0700, Bill Moseley wrote: It seems as if there needs to be a general templating mailing list... Here I have a comment about comparing template systems, and then I solicit advice on which system to use... The only reason I'm using my own templating system (besides the requirement that everyone writes one) is because I realized it would take me less time to code up a simple one than wade through all the available packages, downloading, installing, and trying each out. And frankly, some are so feature-rich that they scared me off - I wanted a template system in my application, not the other way around. I really should leave the programming to The Experts, so having a nice comparison of features would be a huge help, and it might have convinced me to pick one of the available systems. In additions to a comparison of features, people (including me) might find it useful to have a general overview and comparison of the different templating _technologies_ and what type of applications work well with each and why. In my mind, almost all my applications seem to fit a system where a my application uses the templates, instead of the templates using my application. In other words, URLs map to the application and not to pages. I assume the likes of TT and HTML::Template fit this, but Embperl, Mason, and ASP are more based on URLs mapping to templates. Maybe this is an incorrect assumption? I'd also like to see and compare which ones are designed to work best with mod_perl, and the benefits that mod_perl provides the system. It seems like each of the various templating web sites have great info, but it would just be very helpful to see it in one place and see each compared against the others. Now, I think I have rather simple needs. I'm not sure which current system best fits. The tricky part for me is when used with co-branding. Any suggestions? Here is what I need: - Get HTML out of my code, but limit code in templates as non-perl people will be editing the templates -- although I need ways to do some tricks in the templates like changing the bgcolor of a row of a table if some condition is met, or adding an additional column to every row if data in one row meets some condition. - Shared template cache across server children, plus some smart way to detect changed templates without doing a stat() on every
Re: Feature sets [was Re: Templating System]
Gunther Birznieks wrote: Of course, mod_perl support is crucial for those that want to "scale", but normal CGI/Perl support is really a biggie that I haven't seen highlighted within the context of this thread. Most of the popular template modules support CGI use. Almost everything except Apache::ASP claims to work, although I don't think you'd find anyone doing much with Mason through CGI. It sounds like you want more of a "just templates" solution anyway. The question is which ones perform well in a non-persistent environment. I would expect the simple regex type to beat the compile-to-perl-subs type in this scenario. At a guess, maybe HTML::Template and CGI::FastTemplate would be contenders here. Some of the small compile-to-perl-subs ones might work as well, like Text::Template. - Perrin
RE: Feature sets [was Re: Templating System]
Hi there,
I have a pure perl implementation of a simple templating system which is
(what I consider to be) relatively lightweight - it copes well in both
cgi-bin and mod_perl environments, at least for me. I've looked at various
other modules, and do believe mine brings an alternative slant to the
proceedings 8)
A simple example of it in action (if it were called My::Simple::Template)
would be:
use My::Simple::Template;
my $template = new My::Simple::Template;
$template-tags( { key1 = 'value1', key2 = 'value2' } );
print $template-generate("/path/to/template.html");
I've been thinking about releasing it for a while (I've just received
permission from my employer to do so) under the GPL/Artistic license,
although I'm pretty nervous about the quality of the code (primarily due to
having not released anything for public scrutiny before!). I know that there
are a few things that could do with a bit of tidying up, however 8)
It's around 300 lines of code (plus docs) and has been tested with perl
5.005 (although it should work with earlier versions with a bit of
fiddling), on under solaris, linux and windows, cgi-bin and mod_perl. I'll
quite happily supply what I currently have to anyone who's interested.
Synopsis of "main" features:
* in-line insertions with name/value pairs (obviously)
* loops
* basic if/else constructs
* template comments
* file includes
* file and database caching of preprocessed templates
* "loose" expansion of tags
* "template subroutines" (hard to explain in one line)
Please mail me if you're interested in finding out more
Chris
-Original Message-
From: Gunther Birznieks [mailto:[EMAIL PROTECTED]]
Sent: 02 August 2000 09:20
To: [EMAIL PROTECTED]
Subject: RE: Feature sets [was Re: Templating System]
I have to say that I am also interested in template kits myself.
My requirements are almost identical to yours (minus a few advanced things).
Basically, I write open source web applications in Perl -- that means that
they must be able to run reasonably fast on non-modperl systems and must
run on a variety of ISPs (ie not dedicated servers where you control the
version of Perl).
Of course, mod_perl support is crucial for those that want to "scale", but
normal CGI/Perl support is really a biggie that I haven't seen highlighted
within the context of this thread.
Here are my CGI/Perl requirements:
1) Must be 100% pure Perl or support pure-Perl alternatives if certain libs
arent compiled. Many people who download CGI scripts don't know how to
compile stuff.
2) Must support Perl 5.004 and above. Ideal to support Perl 5.003. Enough
ISPs and corporations around the world are still on 5.004 that only
supporting the latest Perl version is not doable.
3) Must incur as minimal load-time as possible. CGI/Perl scripts are not
cached like mod_perl scripts.
So CGI/Perl people must have a template system that can choose to load a
minimal amount of code if really advanced features aren't used. IE would
rather not have a templating system as large as CGI.pm. Or rather it can be
as large as CGI.pm, but only if the extra code is loaded when advanced
features are accessed -- normal CGI/Perl users should not be penalized.
4) Must have a license that supports redistribution in other scripts. I
think most of the systems out there do that (maybe all the Perl ones do).
CPAN is great for us, but again, most real-world web app users are not CPAN
savvy and don't have the rights to install global modules on their ISP nor
the learning to install them locally. So an open source web app that takes
advantage of a template system really should also contain that template
system. The power users can remove it from the local dir if they have a
globally installed version of the system.
Anyway, I felt that I should state these feature requirements because this
list is so mod_perl centric, I think sometimes we forget the "little"
people. And there are many more of them out there than mod_perl servers and
Perl/CPAN savvy people.
RANT_IN_ADVANCEAnd please don't say that they should RTFM. Most users do
not have time to RTFM. If they did, they would be us. :) These users are
people who know their business and typically learn just enough tech to
install something that will help their business -- they don't care or want
a CS degree in the process./RANT_IN_ADVANCE
Later,
Gunther
_
This message has been checked for all known viruses by UUNET delivered
through the MessageLabs Virus Control Centre. For further information visit
http://www.uk.uu.net/products/security/virus/
Re: Feature sets [was Re: Templating System]
"Eric" == Eric Cholet [EMAIL PROTECTED] writes: Hi there, I have a pure perl implementation of a simple templating system which is (what I consider to be) relatively lightweight - it copes well in both cgi-bin and mod_perl environments, at least for me. I've looked at various other modules, and do believe mine brings an alternative slant to the proceedings 8) [...] Eric This looks very similar to HTML::Template: [...] I think it's a rite of passage to look at all the templating systems, and decide "I can do better, along axis $X", and write your own. Then you discover after a while that: a) writing templating systems is no fun the moment you let someone else start using it, because they want feature $Y which you thought nobody would need b) you understand why that other package was so fat :-) Maybe we should have a "Congratulations: you wrote a templating system!" web memorial. :) One brief serious note: I think the fact that there are SO MANY is a tribute to just how easy it is to process text in Perl. I don't think there are 47 templating system for Java. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Feature sets [was Re: Templating System]
Randal Schwartz [EMAIL PROTECTED] writes: One brief serious note: I think the fact that there are SO MANY is a tribute to just how easy it is to process text in Perl. I don't think there are 47 templating system for Java. :) Couldn't agree more. Sometimes Perl is too easy/powerful for its own good. It probably takes less time and effort for any decent Perl hacker to write his/her own simple customized templating system than to download, install, and understand an existing system, not to mention evaluate several systems. Obviously, we need to add strong typing or something to slow people down. :) Jon
Re: Feature sets [was Re: Templating System]
Drew Taylor wrote: Ken Williams wrote: I suggest having not just a simple checkmark, but a 3-way check. A system either supports a feature, or it doesn't, or it *optionally* supports it (can be switched on and off). This is often very helpful to know, and might let one get a good sense of the differences between various systems at a glance. Another great idea! Should we go one farther and have a checkbox for "coming in next version", or is that going to far? I'm thinking it is too easy to get wrapped up in "forward looking statements" by having "coming soon". Although I feel that Mason would do adequately in a feature comparison, I have to say that feature checklists scare me. The reason that they're most often seen in ads and back-of-the-box marketing blurbs is their potential for deception: (1) the set of features you choose, no matter how impartial, bias the results (2) a binary check value (even three or four check values) conveys way too little information (3) in software especially there is a fine distinction between a feature being "built into" versus "supported by" a product Case in point: session handling. I grind my teeth everytime I hear that "Mason doesn't have built-in session handling". Right, and it doesn't have built-in arithmetic processing either. It relies on Apache::Session and the Perl interpreter, respectively, for these features. Yet I've often been tempted, for marketing purposes, to add a "use_session" option to Mason that simply brings in Apache::Session with a few lines of glue code, so I could boast built-in session handling. If I were selling a product I'm sure I'd do this. One of the reasons I like the open source world is that I don't have to resort to this level of chicanery. I guess I'm just cautioning the makers of this feature list to choose the display format carefully so as to minimize information loss. Maybe each template package should get one page with standardized format and questions (what features do you have, what are your system and memory requirements, what does a sample page look like, etc.). That way people could flip back and forth through the pages and get a sense of comparison, and the authors would get to focus on what they consider most important. Jon
Re: Feature sets [was Re: Templating System]
Chris,
This sounds precisely like CGI::FastTemplate, which I have used heavily and
like a lot. My other favorite templating system is HTML::Template, but
CGI::FastTemplate is *very* lightweight.
- David
- Original Message -
From: Chris Carline [EMAIL PROTECTED]
To: Gunther Birznieks [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, August 02, 2000 2:32 AM
Subject: RE: Feature sets [was Re: Templating System]
Hi there,
I have a pure perl implementation of a simple templating system which is
(what I consider to be) relatively lightweight - it copes well in both
cgi-bin and mod_perl environments, at least for me. I've looked at various
other modules, and do believe mine brings an alternative slant to the
proceedings 8)
A simple example of it in action (if it were called My::Simple::Template)
would be:
use My::Simple::Template;
my $template = new My::Simple::Template;
$template-tags( { key1 = 'value1', key2 = 'value2' } );
print $template-generate("/path/to/template.html");
I've been thinking about releasing it for a while (I've just received
permission from my employer to do so) under the GPL/Artistic license,
although I'm pretty nervous about the quality of the code (primarily due
to
having not released anything for public scrutiny before!). I know that
there
are a few things that could do with a bit of tidying up, however 8)
It's around 300 lines of code (plus docs) and has been tested with perl
5.005 (although it should work with earlier versions with a bit of
fiddling), on under solaris, linux and windows, cgi-bin and mod_perl. I'll
quite happily supply what I currently have to anyone who's interested.
Synopsis of "main" features:
* in-line insertions with name/value pairs (obviously)
* loops
* basic if/else constructs
* template comments
* file includes
* file and database caching of preprocessed templates
* "loose" expansion of tags
* "template subroutines" (hard to explain in one line)
Please mail me if you're interested in finding out more
Chris
-Original Message-
From: Gunther Birznieks [mailto:[EMAIL PROTECTED]]
Sent: 02 August 2000 09:20
To: [EMAIL PROTECTED]
Subject: RE: Feature sets [was Re: Templating System]
I have to say that I am also interested in template kits myself.
My requirements are almost identical to yours (minus a few advanced
things).
Basically, I write open source web applications in Perl -- that means that
they must be able to run reasonably fast on non-modperl systems and must
run on a variety of ISPs (ie not dedicated servers where you control the
version of Perl).
Of course, mod_perl support is crucial for those that want to "scale", but
normal CGI/Perl support is really a biggie that I haven't seen highlighted
within the context of this thread.
Here are my CGI/Perl requirements:
1) Must be 100% pure Perl or support pure-Perl alternatives if certain
libs
arent compiled. Many people who download CGI scripts don't know how to
compile stuff.
2) Must support Perl 5.004 and above. Ideal to support Perl 5.003. Enough
ISPs and corporations around the world are still on 5.004 that only
supporting the latest Perl version is not doable.
3) Must incur as minimal load-time as possible. CGI/Perl scripts are not
cached like mod_perl scripts.
So CGI/Perl people must have a template system that can choose to load a
minimal amount of code if really advanced features aren't used. IE would
rather not have a templating system as large as CGI.pm. Or rather it can
be
as large as CGI.pm, but only if the extra code is loaded when advanced
features are accessed -- normal CGI/Perl users should not be penalized.
4) Must have a license that supports redistribution in other scripts. I
think most of the systems out there do that (maybe all the Perl ones do).
CPAN is great for us, but again, most real-world web app users are not
CPAN
savvy and don't have the rights to install global modules on their ISP nor
the learning to install them locally. So an open source web app that takes
advantage of a template system really should also contain that template
system. The power users can remove it from the local dir if they have a
globally installed version of the system.
Anyway, I felt that I should state these feature requirements because this
list is so mod_perl centric, I think sometimes we forget the "little"
people. And there are many more of them out there than mod_perl servers
and
Perl/CPAN savvy people.
RANT_IN_ADVANCEAnd please don't say that they should RTFM. Most users do
not have time to RTFM. If they did, they would be us. :) These users are
people who know their business and typically learn just enough tech to
install something that will help their business -- they don't care or want
a CS degree in the process./RANT_IN_ADVANCE
Later,
Gunther
__
Re: Feature sets [was Re: Templating System]
Maybe we should have a "Congratulations: you wrote a templating system!" web memorial. :) One brief serious note: I think the fact that there are SO MANY is a tribute to just how easy it is to process text in Perl. I don't think there are 47 templating system for Java. :) A few days ago I sent this suggestion to Drew Taylor, who is preparing a web page comparing the templating systems. He said he likes the idea. The Categorical "Congratulations: you wrote a templating system!" web memorial. * Place the templating systems into a spectrum of categories, from simplest to most complex/developed. It would look approximately like this (not attempting to be complete): -Level one, simplest * Simple tag/anchor replacement * Embedded code evaluation -Level two, complete templating, but templating only * HTML::Template * Template Toolkit * HTML - Tree (??) -Level three, templating plus (added features such as session management, database integration, etc.) * Apache::ASP * Embperl * HTML::Mason * AxKit Ron At 06:32 AM 08/02/00 -0700, Randal L. Schwartz wrote: "Eric" == Eric Cholet [EMAIL PROTECTED] writes: Hi there, I have a pure perl implementation of a simple templating system which is (what I consider to be) relatively lightweight - it copes well in both cgi-bin and mod_perl environments, at least for me. I've looked at various other modules, and do believe mine brings an alternative slant to the proceedings 8) [...] Eric This looks very similar to HTML::Template: [...] I think it's a rite of passage to look at all the templating systems, and decide "I can do better, along axis $X", and write your own. Then you discover after a while that: a) writing templating systems is no fun the moment you let someone else start using it, because they want feature $Y which you thought nobody would need b) you understand why that other package was so fat :-) Maybe we should have a "Congratulations: you wrote a templating system!" web memorial. :) One brief serious note: I think the fact that there are SO MANY is a tribute to just how easy it is to process text in Perl. I don't think there are 47 templating system for Java. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Feature sets [was Re: Templating System]
"Ron" == Ron Pero [EMAIL PROTECTED] writes: Ron A few days ago I sent this suggestion to Drew Taylor, who is Ron preparing a web page comparing the templating systems. He said he Ron likes the idea. The Categorical "Congratulations: you wrote a Ron templating system!" web memorial. Wow, if making suggestions here gets that kind of immediate results, let me also suggest I need a girlfriend who is travel-compatible and email friendly. Maybe one will show up. :) Or do you get only one wish per quarter? :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Feature sets [was Re: Templating System]
Matt Sergeant wrote: On Tue, 1 Aug 2000, Drew Taylor wrote: Bill Moseley wrote: It seems as if there needs to be a general templating mailing list... Here I have a comment about comparing template systems, and then I solicit advice on which system to use... snip Bill, After all the response the thread generated, I wonder if perhaps we (meaning the people who have control over those things :-) really _should_ setup another list. Look at the history of this list: it often gets very bursty and the quiet again. I think setting up a perl-template mailing list would be initially heavily trafficed, but be pretty much dead in a few weeks (or days even). I'd agree. The list tends to hit a raw never and trafic goes up alot and then its quite again. I would like to see discussion here as long as its relevant. Greg Cope -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Feature sets [was Re: Templating System]
I am afraid that while I agree, a check system is really quite useful to me. Some things do need more quantification, but that can be done later. eg lightweight vs heavyweight is subjective. But it can be broken up into saying something like how much code needs to be loaded at start time (an issue for CGI/Perl). eg I think people would agree that the startup of CGI.pm is different from CGI::Lite which is different from cgi-lib.pl. Of course, there are many other features that you get from them that can make a difference in your program. Anyway, that is why this checklist is being designed by all of you and handled by an independent 3rd party. It's not a marketing tool. So if you complain about session support being a checkbox, I am sure that the feature name could be refined. Later, Gunther At 08:26 AM 8/2/00 -0700, Jonathan Swartz wrote: Drew Taylor wrote: Ken Williams wrote: I suggest having not just a simple checkmark, but a 3-way check. A system either supports a feature, or it doesn't, or it *optionally* supports it (can be switched on and off). This is often very helpful to know, and might let one get a good sense of the differences between various systems at a glance. Another great idea! Should we go one farther and have a checkbox for "coming in next version", or is that going to far? I'm thinking it is too easy to get wrapped up in "forward looking statements" by having "coming soon". Although I feel that Mason would do adequately in a feature comparison, I have to say that feature checklists scare me. The reason that they're most often seen in ads and back-of-the-box marketing blurbs is their potential for deception: (1) the set of features you choose, no matter how impartial, bias the results (2) a binary check value (even three or four check values) conveys way too little information (3) in software especially there is a fine distinction between a feature being "built into" versus "supported by" a product Case in point: session handling. I grind my teeth everytime I hear that "Mason doesn't have built-in session handling". Right, and it doesn't have built-in arithmetic processing either. It relies on Apache::Session and the Perl interpreter, respectively, for these features. Yet I've often been tempted, for marketing purposes, to add a "use_session" option to Mason that simply brings in Apache::Session with a few lines of glue code, so I could boast built-in session handling. If I were selling a product I'm sure I'd do this. One of the reasons I like the open source world is that I don't have to resort to this level of chicanery. I guess I'm just cautioning the makers of this feature list to choose the display format carefully so as to minimize information loss. Maybe each template package should get one page with standardized format and questions (what features do you have, what are your system and memory requirements, what does a sample page look like, etc.). That way people could flip back and forth through the pages and get a sense of comparison, and the authors would get to focus on what they consider most important. Jon
Re: Feature sets [was Re: Templating System]
[EMAIL PROTECTED] (Gunther Birznieks) wrote: I am afraid that while I agree, a check system is really quite useful to me. Some things do need more quantification, but that can be done later. eg lightweight vs heavyweight is subjective. But it can be broken up into saying something like how much code needs to be loaded at start time (an issue for CGI/Perl). eg I think people would agree that the startup of CGI.pm is different from CGI::Lite which is different from cgi-lib.pl. Of course, there are many other features that you get from them that can make a difference in your program. Anyway, that is why this checklist is being designed by all of you and handled by an independent 3rd party. It's not a marketing tool. So if you complain about session support being a checkbox, I am sure that the feature name could be refined. I agree. I came up with an initial set of checkboxes (posted here last week), but I'd have no qualms about some author wanting to ditch some of those. I think a useful comparison would use feature comparisons only as a means of revealing the comparitive philosophies of the systems. Gunther, has anyone found a good home for such a comparison to be hosted? It would be cool if it were at perl.apache.org, or even better at www.perl.com or something (since it's not mod_perl specific). As long as it's easily updatable by its maintainers (and who are they?).
RE: Feature sets [was Re: Templating System]
It seems as if there needs to be a general templating mailing list... Here I have a comment about comparing template systems, and then I solicit advice on which system to use... The only reason I'm using my own templating system (besides the requirement that everyone writes one) is because I realized it would take me less time to code up a simple one than wade through all the available packages, downloading, installing, and trying each out. And frankly, some are so feature-rich that they scared me off - I wanted a template system in my application, not the other way around. I really should leave the programming to The Experts, so having a nice comparison of features would be a huge help, and it might have convinced me to pick one of the available systems. In additions to a comparison of features, people (including me) might find it useful to have a general overview and comparison of the different templating _technologies_ and what type of applications work well with each and why. In my mind, almost all my applications seem to fit a system where a my application uses the templates, instead of the templates using my application. In other words, URLs map to the application and not to pages. I assume the likes of TT and HTML::Template fit this, but Embperl, Mason, and ASP are more based on URLs mapping to templates. Maybe this is an incorrect assumption? I'd also like to see and compare which ones are designed to work best with mod_perl, and the benefits that mod_perl provides the system. It seems like each of the various templating web sites have great info, but it would just be very helpful to see it in one place and see each compared against the others. Now, I think I have rather simple needs. I'm not sure which current system best fits. The tricky part for me is when used with co-branding. Any suggestions? Here is what I need: - Get HTML out of my code, but limit code in templates as non-perl people will be editing the templates -- although I need ways to do some tricks in the templates like changing the bgcolor of a row of a table if some condition is met, or adding an additional column to every row if data in one row meets some condition. - Shared template cache across server children, plus some smart way to detect changed templates without doing a stat() on every request (which is what I'm currently doing -- and since my templates are full of INCLUDEd other templates, that's a bunch of stats). - Not sure if it makes much difference in speed, but parts of my templates only need to be filled in when first loaded off disk since the data is static once loaded (e.g. base url, base path, titles). Other parts are filled in with each request, as is common. - Easy way to handle co-branding (partners/views). I have a site that is used by a number of other sites -- basically our site is wrapped in their "look". Admittedly, I could probably use a better design. My program maps various pages of the application (e.g. main page, search page, results page, error page, help page) to different template files. Say all the templates are stored in the "templates" directory. Subdirectories in the "templates" directory contain the templates for each of the co-branded sites. When running as co-branded the template mapper first looks in the co-branded subdirectory for the template, then if not found there, looks in the top level templates directory for a template of the same name. More helpful in my case, the same process works for templates included within templates so that many of the templates (and included templates) are shared. I guess that's someone like the "components" feature of Mason. - I'm not sure how I feel on this issue: I want my templates to be limited in what data they can access, but I also don't want to have to specify or pass the exact data my template will use to the template system. When the HTML people want to add a new field on the page I don't want to have to always go into the application and provide that new data to the template -- and that defeats one of the purposes of the template system. So, any suggestions on what one or two templating systems I should try that would do at least the above? Thanks, Bill Moseley mailto:[EMAIL PROTECTED]
Re: Feature sets [was Re: Templating System]
Bill Moseley wrote: It seems as if there needs to be a general templating mailing list... Here I have a comment about comparing template systems, and then I solicit advice on which system to use... snip Bill, After all the response the thread generated, I wonder if perhaps we (meaning the people who have control over those things :-) really _should_ setup another list. I will take yours (and everyone else's) thoughts to heart when I'm putting together the comparison document/site. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Drew Taylor wrote: Bill Moseley wrote: After all the response the thread generated, I wonder if perhaps we (meaning the people who have control over those things :-) really _should_ setup another list. I could see the efficacy of a template developers site for those people involved in the actual development of whatever solution but I think another list would confusion. Besides, template questions would still be asked on mod_perl anyway... My $0.02. -- __ Mr. Erich L. Markert [EMAIL PROTECTED] Computer Learning Center TEL (914)422-4328 Pace University 1 Martine Ave White Plains, New York 10606-1932 Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer
Re: Feature sets [was Re: Templating System]
"Erich L. Markert" wrote: Drew Taylor wrote: Bill Moseley wrote: After all the response the thread generated, I wonder if perhaps we (meaning the people who have control over those things :-) really _should_ setup another list. I could see the efficacy of a template developers site for those people involved in the actual development of whatever solution but I think another list would confusion. Besides, template questions would still be asked on mod_perl anyway... So true. I do hope to eventually create an entire site dedicated to template developers. But you have to start crawling before you can run. :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
On Tue, 1 Aug 2000, Drew Taylor wrote: Bill Moseley wrote: It seems as if there needs to be a general templating mailing list... Here I have a comment about comparing template systems, and then I solicit advice on which system to use... snip Bill, After all the response the thread generated, I wonder if perhaps we (meaning the people who have control over those things :-) really _should_ setup another list. Look at the history of this list: it often gets very bursty and the quiet again. I think setting up a perl-template mailing list would be initially heavily trafficed, but be pretty much dead in a few weeks (or days even). -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Feature sets [was Re: Templating System]
Look at the history of this list: it often gets very bursty and the quiet again. I think setting up a perl-template mailing list would be initially heavily trafficed, but be pretty much dead in a few weeks (or days even). I agree to that Gerald - 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 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: Feature sets [was Re: Templating System]
Matt Sergeant wrote: On Tue, 1 Aug 2000, Drew Taylor wrote: Bill Moseley wrote: It seems as if there needs to be a general templating mailing list... Here I have a comment about comparing template systems, and then I solicit advice on which system to use... snip Bill, After all the response the thread generated, I wonder if perhaps we (meaning the people who have control over those things :-) really _should_ setup another list. Look at the history of this list: it often gets very bursty and the quiet again. I think setting up a perl-template mailing list would be initially heavily trafficed, but be pretty much dead in a few weeks (or days even). Oh so true! Hopefully as people put together resources and the URLs are publicized, we can avoid some of the same questions that come up time and time again. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
RE: Feature sets [was Re: Templating System]
On Tue, 1 Aug 2000, Bill Moseley wrote: In additions to a comparison of features, people (including me) might find it useful to have a general overview and comparison of the different templating _technologies_ and what type of applications work well with each and why. I was planning to help out with writing just such an essay. It needs to explain things like callback vs. pipeline, and why you might want one or the other for certain apps. In my mind, almost all my applications seem to fit a system where a my application uses the templates, instead of the templates using my application. In other words, URLs map to the application and not to pages. I assume the likes of TT and HTML::Template fit this, but Embperl, Mason, and ASP are more based on URLs mapping to templates. Yes, the first is pipeline, and the second is callbacks (in my terminology anyway). Now, I think I have rather simple needs. I'm not sure which current system best fits. The tricky part for me is when used with co-branding. Any suggestions? TT, Mason, and HTML::Template would all work, and others probably would too but I'm not as familiar with how they handle template search paths. - Shared template cache across server children That's pretty hard for any system that compiles templates to perl subs, which most of the fastest ones do. You can't share compiled perl subs across children except by loading them before the fork. plus some smart way to detect changed templates without doing a stat() on every request (which is what I'm currently doing -- and since my templates are full of INCLUDEd other templates, that's a bunch of stats). I wonder if people make too much of the file stat cost. Well, Mason handles this in a reasonably efficient way and I think the others just let you turn it on or off at most, but even with Mason if you want it to do the right thing you'll have to code some stuff on your end to let it know your templates have changed (or manually touch a file). (Hmmm... that might be a cool feature to add to TT in the Template::Provider class.) Say all the templates are stored in the "templates" directory. Subdirectories in the "templates" directory contain the templates for each of the co-branded sites. When running as co-branded the template mapper first looks in the co-branded subdirectory for the template, then if not found there, looks in the top level templates directory for a template of the same name. More helpful in my case, the same process works for templates included within templates so that many of the templates (and included templates) are shared. I guess that's someone like the "components" feature of Mason. Yes, Mason and TT both work this way. - I'm not sure how I feel on this issue: I want my templates to be limited in what data they can access, but I also don't want to have to specify or pass the exact data my template will use to the template system. When the HTML people want to add a new field on the page I don't want to have to always go into the application and provide that new data to the template -- and that defeats one of the purposes of the template system. How's that cake you're eating? Seriously, the best you can do is probably to use a pipeline model and build data providers according to a certain design that some other part of your program will recognize and automatically make their data available to templates. Plugins, basically. - Perrin
Re: Feature sets [was Re: Templating System]
In my mind, almost all my applications seem to fit a system where a my application uses the templates, instead of the templates using my application. In other words, URLs map to the application and not to pages. I assume the likes of TT and HTML::Template fit this, but Embperl, Mason, and ASP are more based on URLs mapping to templates. Yes, the first is pipeline, and the second is callbacks (in my terminology anyway). Embperl can be used in both ways. Also standard is the URL maps to template I know maybe people that maps the URL to a application, that uses Embperl only for rendering the template. - Shared template cache across server children That's pretty hard for any system that compiles templates to perl subs, which most of the fastest ones do. You can't share compiled perl subs across children except by loading them before the fork. Yes, compiled Perl code can't be shared. mod_perl 2.0 will take us a step futher in this direction (as far as you use threads and not forked processes). Say all the templates are stored in the "templates" directory. Subdirectories in the "templates" directory contain the templates for each of the co-branded sites. When running as co-branded the template mapper first looks in the co-branded subdirectory for the template, then if not found there, looks in the top level templates directory for a template of the same name. More helpful in my case, the same process works for templates included within templates so that many of the templates (and included templates) are shared. I guess that's someone like the "components" feature of Mason. Yes, Mason and TT both work this way. EmbperlObject provides the same within Embperl and sets up a Perl class hierachie, so you not only search for whole pages/files/components in parent directory, but also can overwrite methods. Gerald - 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 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: Feature sets [was Re: Templating System]
Ken Williams [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Frank D. Cringle) wrote: unconstructive grumble This sounds dreadfully microsoftian. Trashcan: check; Bouncing paperclip: check. Well yeah, if you choose features that nobody cares about, then nobody will care whether the package supports them. But they should care. They should choose the package that does not support irrelevant features, since (given similar quality of implementation) it will be smaller, more efficient and more reliable. Personally I think it would be really nice to have a comparison between modules, and I think its chief purpose would NOT be to indicate which systems are *better* than others, but what the intent of various modules are. It would enable someone at a glance to know whether something fills the I-am-your-entire-WWW-world niche, or is just a simple templater. That's fine. What I am objecting to is the (mis-)use of the term "Templating system". A template is a passive sheet of metal or plastic with holes in it. It does not include levers and gears and motors. -- Frank Cringle, [EMAIL PROTECTED] voice: (+49 2304) 467101; fax: 943357
Re: Feature sets [was Re: Templating System]
On Fri, 28 Jul 2000, Drew Taylor wrote: After all this discussion, what would benefit me most in choosing my next template system would be a concise central repository of the features benefits for the major template systems (TT, Apache::ASP, Embperl, Mason, HTML::Template come to mind first). I've been planning to do that, but I'm too busy to work on it right now. Maybe I can add some things to what you come up with. - Perrin
Re: Feature sets [was Re: Templating System]
Yes please ! I've been following these threads with avid interest as I am just starting to look at this technology. I'm currently using SSI to call mod_perl scripts to handle the dynamic parts of the pages but this is getting very unwieldy when I start doing form handling. I need to move to a more structured template system for ease of development maintenance. If you would like some help with the comparison, please let me know. Simon Wilcox Intranet Development Manager Williams Lea Group From Drew Taylor [EMAIL PROTECTED] Date 14:54:16 28 July 2000 To: modperl [EMAIL PROTECTED] cc:(bcc: Simon Wilcox/BASE/WilliamsLea) Fax to: Subject: Feature sets [was Re: Templating System] After all this discussion, what would benefit me most in choosing my next template system would be a concise central repository of the features benefits for the major template systems (TT, Apache::ASP, Embperl, Mason, HTML::Template come to mind first). I'd volunteer to help put it together, but I don't know what the above features are. If the principal maintainer(s) for each system could post a short blurb about it, I would be happy to compile them together for use by all. Would anyone else benefit from a template summary? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Simon, You aren't the only one who was pleasantly surprised to come back to a mailbox overflowing with messages on a topic near dear to my heart. :-) As for summarizing, I have some pretty good info already: a private email from a user of embperl, Andy's post of TT, and Joshua pointed me to Apache::ASP's website. I'll probably do some serious reading this weekend and (hopefully) begin to sketch out the comparison. And yes, help is always appreciated. :-) [EMAIL PROTECTED] wrote: Yes please ! I've been following these threads with avid interest as I am just starting to look at this technology. I'm currently using SSI to call mod_perl scripts to handle the dynamic parts of the pages but this is getting very unwieldy when I start doing form handling. If you would like some help with the comparison, please let me know. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
RE: Feature sets [was Re: Templating System]
As for summarizing, I have some pretty good info already: a private email from a user of embperl, Andy's post of TT, and Joshua pointed me to Apache::ASP's website. I'll probably do some serious reading this weekend and (hopefully) begin to sketch out the comparison. And yes, help is always appreciated. :-) For Embperl 1.x http://perl.apache.org/embperl/Features.pod.1.html is a good starting point and for Embperl 2.0 add the things that I wrote in my mail (search for "preview Embperl 2.0"). If you have put something together, I would be happy to review it, to make sure things about Embperl are correct. Gerald
Re: Feature sets [was Re: Templating System]
Gerald Richter wrote: As for summarizing, I have some pretty good info already: a private email from a user of embperl, Andy's post of TT, and Joshua pointed me to Apache::ASP's website. I'll probably do some serious reading this weekend and (hopefully) begin to sketch out the comparison. And yes, help is always appreciated. :-) For Embperl 1.x http://perl.apache.org/embperl/Features.pod.1.html is a good starting point and for Embperl 2.0 add the things that I wrote in my mail (search for "preview Embperl 2.0"). Thanks. I have saved the text of the "preview embperl 2.0" post. If you have put something together, I would be happy to review it, to make sure things about Embperl are correct. Of course! Having never used embperl, I'd rather go straight to the source. :-) Vivek had an excellent suggestion in private email: put together a list of features and let the developers check off the options their system supports. My biggest question is who comes up with the feature list in the first place? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
RE: Feature sets [was Re: Templating System]
Vivek had an excellent suggestion in private email: put together a list of features and let the developers check off the options their system supports. My biggest question is who comes up with the feature list in the first place? I would suggest it the other way round. Put together what you already have and let the developers correct and complete it. I often had thought about creating such a comparison, but I don't have the time to do so, but doing a proof read of what you have created should be possible. Gerald
Re: Feature sets [was Re: Templating System]
Gerald Richter wrote: Vivek had an excellent suggestion in private email: put together a list of features and let the developers check off the options their system supports. My biggest question is who comes up with the feature list in the first place? I would suggest it the other way round. Put together what you already have and let the developers correct and complete it. I often had thought about creating such a comparison, but I don't have the time to do so, but doing a proof read of what you have created should be possible. OK. I will do that and when I have the first draft done, I will post with a link to the document. I'll just grow and evolve the document(s) as needed. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
[EMAIL PROTECTED] (Drew Taylor) wrote: Gerald Richter wrote: Vivek had an excellent suggestion in private email: put together a list of features and let the developers check off the options their system supports. My biggest question is who comes up with the feature list in the first place? I would suggest it the other way round. Put together what you already have and let the developers correct and complete it. I often had thought about creating such a comparison, but I don't have the time to do so, but doing a proof read of what you have created should be possible. I suggest having not just a simple checkmark, but a 3-way check. A system either supports a feature, or it doesn't, or it *optionally* supports it (can be switched on and off). This is often very helpful to know, and might let one get a good sense of the differences between various systems at a glance.
Re: Feature sets [was Re: Templating System]
Ken Williams wrote: I suggest having not just a simple checkmark, but a 3-way check. A system either supports a feature, or it doesn't, or it *optionally* supports it (can be switched on and off). This is often very helpful to know, and might let one get a good sense of the differences between various systems at a glance. Another great idea! Should we go one farther and have a checkbox for "coming in next version", or is that going to far? I'm thinking it is too easy to get wrapped up in "forward looking statements" by having "coming soon". -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
On Fri, 28 Jul 2000, Drew Taylor wrote: Ken Williams wrote: I suggest having not just a simple checkmark, but a 3-way check. A system either supports a feature, or it doesn't, or it *optionally* supports it (can be switched on and off). This is often very helpful to know, and might let one get a good sense of the differences between various systems at a glance. Another great idea! Should we go one farther and have a checkbox for "coming in next version", or is that going to far? I'm thinking it is too easy to get wrapped up in "forward looking statements" by having "coming soon". This is getting too complex. Just do a couple of paragraphs on each, and let everyone bang it out to a bit more than that. I guarantee that once one template system designer says "Mine does X", the others will chime in and say "Well mine can do X too, and optionally Y". Eventually you'll get the perfect document... However I suggest taking that stage off the list, and just let them send patches direct to you, and announce when you've got a new version. A-la guide. In fact it might be a nice addition to the guide. (here I am making Stas and Eric's book even longer...) -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: Feature sets [was Re: Templating System]
Matt Sergeant wrote: This is getting too complex. Just do a couple of paragraphs on each, and let everyone bang it out to a bit more than that. I guarantee that once one template system designer says "Mine does X", the others will chime in and say "Well mine can do X too, and optionally Y". Eventually you'll get the perfect document... True. And it's also the only sane way to do it as well. :-) However I suggest taking that stage off the list, and just let them send patches direct to you, and announce when you've got a new version. A-la guide. In fact it might be a nice addition to the guide. (here I am making Stas and Eric's book even longer...) If it turns out to be good enough for the guide, I'll be happy to contribute it. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Feature sets [was Re: Templating System]
Drew Taylor [EMAIL PROTECTED] writes: Ken Williams wrote: I suggest having not just a simple checkmark, but a 3-way check. A system either supports a feature, or it doesn't, or it *optionally* supports it (can be switched on and off). This is often very helpful to know, and might let one get a good sense of the differences between various systems at a glance. Another great idea! Should we go one farther and have a checkbox for "coming in next version", or is that going to far? I'm thinking it is too easy to get wrapped up in "forward looking statements" by having "coming soon". unconstructive grumble This sounds dreadfully microsoftian. Trashcan: check; Bouncing paperclip: check. I suspect HTML::Template will achieve the highest functionality to checkbox ratio. -- Frank Cringle, [EMAIL PROTECTED] voice: (+49 2304) 467101; fax: 943357
Re: Feature sets [was Re: Templating System]
[EMAIL PROTECTED] (Frank D. Cringle) wrote: Drew Taylor [EMAIL PROTECTED] writes: Ken Williams wrote: I suggest having not just a simple checkmark, but a 3-way check. A system either supports a feature, or it doesn't, or it *optionally* supports it (can be switched on and off). This is often very helpful to know, and might let one get a good sense of the differences between various systems at a glance. Another great idea! Should we go one farther and have a checkbox for "coming in next version", or is that going to far? I'm thinking it is too easy to get wrapped up in "forward looking statements" by having "coming soon". unconstructive grumble This sounds dreadfully microsoftian. Trashcan: check; Bouncing paperclip: check. Well yeah, if you choose features that nobody cares about, then nobody will care whether the package supports them. Personally I think it would be really nice to have a comparison between modules, and I think its chief purpose would NOT be to indicate which systems are *better* than others, but what the intent of various modules are. It would enable someone at a glance to know whether something fills the I-am-your-entire-WWW-world niche, or is just a simple templater. I suspect HTML::Template will achieve the highest functionality to checkbox ratio. I'm not sure what you mean. I suppose it means that even though it only does a couple of simple things, HTML::Template is a useful tool? I certainly don't disagree. It's got its niche, and it fills it well. Let me get the feature ball rolling (if the ball already rolls, I apologize): * conditional statements (if/else) * embedded loops * arbitrary embedded Perl code * HTML/URI escaping on output * integrated session handling * controlled data caching * modular template/component framework * runs as PerlHandler * Perl debugger support * understands modifies page's HTML * configurable tag delimiters This may (unintentionally) line up a little too neatly with Mason's feature set, because it's the set I know best. These attributes don't make one system better than another, and they CERTAINLY don't tell the whole story, but a chart of them would help people compare each system's goals at a glance. One of the reasons for the proliferation of templating systems is that people can't easily figure out what systems do what, so they just write their own slightly different system.
