Re: comparison of templating methods?
On Sun, Jun 10, 2001 at 10:36:17PM +0800, Gunther Birznieks wrote: At 08:59 AM 6/8/2001 -0500, will trillich wrote: which of the existing paradigms will the widget farm most closely resemble? and what are your expectations for tradeoff in functionality/modularity-vs-performance? 1) What do you mean by your first question? if i was going to minimize a future learning curve, i'd like to be able to jump aboard the widget farm already armed with knowledge of how to do something similar. if it's nothing at all like mason, but similar to axkit, then (if i expect to be an ardent fan of the widget attack) i'd be better off pursuing axkit. for example. 2) I believe there is nothing being done in the widget farm that would really hinder performance other than being objects with methods. Really without a good object structure then a widget farm is wholly useless. you're definitely right, there. i'm just noticing that several templating methods add molasses in january effects to the rendering of some pages. of course, there may be more to blame in the instance of implementation, than in the implementation itself... thanks for your replies -- we're leaning towards axkit or mason at the moment-- -- I figure: if a man's gonna gamble, may as well do it without plowing. -- Bama Dillert, Some Came Running [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: comparison of templating methods?
On Mon, 11 Jun 2001, will trillich wrote: At 08:59 AM 6/8/2001 -0500, will trillich wrote: which of the existing paradigms will the widget farm most closely resemble? and what are your expectations for tradeoff in functionality/modularity-vs-performance? 1) What do you mean by your first question? if i was going to minimize a future learning curve, i'd like to be able to jump aboard the widget farm already armed with knowledge of how to do something similar. if it's nothing at all like mason, but similar to axkit, then (if i expect to be an ardent fan of the widget attack) i'd be better off pursuing axkit. for example. Actually I've just built a widget-type system for AxKit, though it's not documented yet. I've sent a couple of posts to the perl-widget mailing list about it, though I don't think AxKit is terribly popular with the users there (but then I suppose you could say that about XML and Perl users in general). 2) I believe there is nothing being done in the widget farm that would really hinder performance other than being objects with methods. Really without a good object structure then a widget farm is wholly useless. you're definitely right, there. i'm just noticing that several templating methods add molasses in january effects to the rendering of some pages. of course, there may be more to blame in the instance of implementation, than in the implementation itself... I think anyone expecting this stuff to be performant is kidding themselves. I can get XSP pages back in about 100ms with the current CVS AxKit, and of course that slows down with many connections. You always pay for these kind of abstractions. thanks for your replies -- we're leaning towards axkit or mason at the moment-- Cool :-) -- Matt/ /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
Re: comparison of templating methods?
At 08:25 PM 6/8/2001 +0200, Gerald Richter wrote: At 02:26 PM 6/7/2001 +1000, Steve Smith wrote: HTML::Embperl For me, this has one major win over the other toolkits: auto form population from a hash. The online mortgage application system I wrote has about 1,800 form fields, which have to be populated with data from a database. By making the form fields match DB column names, I can reduce the code to do this to: my $data = $dbh-fetchrow_hashref($query); %fdat = (%fdat, %$data); Embperl then parses the form and populates it with the matching name=value pairs in %fdat, including select options. Beautiful! Not that it's a reality now, but this is one of the things that the Perl Widget Library project on source forge is hoping to accomplish for template languages. It's a cross template way of organizing form information and map it to db fields. The reality is that there are many fields that cannot map easily 1-1 to a database as you say. eg a date in a database is usually a date field. But in a form, it might be a combination of 3 form fields (dropdown for month, year and day separately). Such things could be solved by using DBIx::Recordset for database access and define some filters, which are able to transform the content of a field to/from format you need it. Well, that assumes everything is a database... everything I think I see, looks like a database to me... If you look at PHP's GPC model and then realize that it goes farther into allowing other datasources such as S or a DB or a secondary DB if the first one is empty for that field, then you'll see that abstracting it in a common way rather than a DBI-specific view is much more powerful and is something that applications do occasionally have to do. Writing a filter is doable but really kind of a hack really.
Re: comparison of templating methods?
At 08:59 AM 6/8/2001 -0500, will trillich wrote: On Fri, Jun 08, 2001 at 06:52:14PM +0800, Gunther Birznieks wrote: At 02:26 PM 6/7/2001 +1000, Steve Smith wrote: HTML::Embperl For me, this has one major win over the other toolkits: auto form population from a hash. The online mortgage application system I wrote has about 1,800 form fields, which have to be populated with data from a database. By making the form fields match DB column names, I can reduce the code to do this to: my $data = $dbh-fetchrow_hashref($query); %fdat = (%fdat, %$data); Embperl then parses the form and populates it with the matching name=value pairs in %fdat, including select options. Beautiful! Not that it's a reality now, but this is one of the things that the Perl Widget Library project on source forge is hoping to accomplish for template languages. It's a cross template way of organizing form information and map it to db fields. The reality is that there are many fields that cannot map easily 1-1 to a database as you say. eg a date in a database is usually a date field. But in a form, it might be a combination of 3 form fields (dropdown for month, year and day separately). which of the existing paradigms will the widget farm most closely resemble? and what are your expectations for tradeoff in functionality/modularity-vs-performance? 1) What do you mean by your first question? 2) I believe there is nothing being done in the widget farm that would really hinder performance other than being objects with methods. Really without a good object structure then a widget farm is wholly useless. If you need extremely high performance pages than you probably need to code more low level than throwing abstractions around like widgets. Please read the following, and then take the conversation to the widget-specific mailing list if you are interested in talking more about it. http://www.officevision.com/pub/Widget/ Thanks, Gunther -- I figure: if a man's gonna gamble, may as well do it without plowing. -- Bama Dillert, Some Came Running [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us! __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: comparison of templating methods?
will trillich wrote: HTML::Mason Template-Toolkit tuppence type='mine' These are only two I have much experience with. I've found both to be well written, stable and well supported. TT makes it easier to separate the logic from the presentation layer IMHO. But every time I code a project in mason I find myself smiling and thinking 'This is fun', at least occasionally. Projects seem to come together _much_ faster with Mason, though overall coding time isn't much different. With Mason you have to work harder if you want to separate logic presentation, but its fairly straightfoward if you put some thought into your component design ahead of time. So typically, if I need skinability, or if I need to give edit capability to html'ers with no perl but light scripting ability I use TT, otherwise I use Mason. /tuppence J
Re: comparison of templating methods?
will trillich wrote: HTML::Mason Template-Toolkit tuppence type='mine' These are only two I have much experience with. I've found both to be well written, stable and well supported. TT makes it easier to separate the logic from the presentation layer IMHO. But every time I code a project in mason I find myself smiling and thinking 'This is fun', at least occasionally. Projects seem to come together _much_ faster with Mason, though overall coding time isn't much different. With Mason you have to work harder if you want to separate logic presentation, but its fairly straightfoward if you put some thought into your component design ahead of time. So typically, if I need skinability, or if I need to give edit capability to html'ers with no perl but light scripting ability I use TT, otherwise I use Mason. /tuppence J
Re: comparison of templating methods?
will trillich wrote: HTML::Mason Template-Toolkit tuppence type='mine' These are only two I have much experience with. I've found both to be well written, stable and well supported. TT makes it easier to separate the logic from the presentation layer IMHO. But every time I code a project in mason I find myself smiling and thinking 'This is fun', at least occasionally. Projects seem to come together _much_ faster with Mason, though overall coding time isn't much different. With Mason you have to work harder if you want to separate logic presentation, but its fairly straightfoward if you put some thought into your component design ahead of time. So typically, if I need skinability, or if I need to give edit capability to html'ers with no perl but light scripting ability I use TT, otherwise I use Mason. /tuppence J
Re: comparison of templating methods?
At 02:26 PM 6/7/2001 +1000, Steve Smith wrote: HTML::Embperl For me, this has one major win over the other toolkits: auto form population from a hash. The online mortgage application system I wrote has about 1,800 form fields, which have to be populated with data from a database. By making the form fields match DB column names, I can reduce the code to do this to: my $data = $dbh-fetchrow_hashref($query); %fdat = (%fdat, %$data); Embperl then parses the form and populates it with the matching name=value pairs in %fdat, including select options. Beautiful! Not that it's a reality now, but this is one of the things that the Perl Widget Library project on source forge is hoping to accomplish for template languages. It's a cross template way of organizing form information and map it to db fields. The reality is that there are many fields that cannot map easily 1-1 to a database as you say. eg a date in a database is usually a date field. But in a form, it might be a combination of 3 form fields (dropdown for month, year and day separately). Later, Gunther
Re: comparison of templating methods?
On Fri, Jun 08, 2001 at 10:49:39AM +0800, Stas Bekman wrote: This is your ultimate answer :) : Choosing a Templating System. http://conferences.oreillynet.com/cs/os2001/view/e_sess/1263 Hopefully Perrin will release his paper close to the conference. looking forward to that! thanks. -- I figure: if a man's gonna gamble, may as well do it without plowing. -- Bama Dillert, Some Came Running [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: comparison of templating methods?
At 02:26 PM 6/7/2001 +1000, Steve Smith wrote: HTML::Embperl For me, this has one major win over the other toolkits: auto form population from a hash. The online mortgage application system I wrote has about 1,800 form fields, which have to be populated with data from a database. By making the form fields match DB column names, I can reduce the code to do this to: my $data = $dbh-fetchrow_hashref($query); %fdat = (%fdat, %$data); Embperl then parses the form and populates it with the matching name=value pairs in %fdat, including select options. Beautiful! Not that it's a reality now, but this is one of the things that the Perl Widget Library project on source forge is hoping to accomplish for template languages. It's a cross template way of organizing form information and map it to db fields. The reality is that there are many fields that cannot map easily 1-1 to a database as you say. eg a date in a database is usually a date field. But in a form, it might be a combination of 3 form fields (dropdown for month, year and day separately). Such things could be solved by using DBIx::Recordset for database access and define some filters, which are able to transform the content of a field to/from format you need it. 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 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: comparison of templating methods?
will trillich [EMAIL PROTECTED] writes: AxKit HTML::Embperl The two that I've had the most experience with are AxKit and HTML::Embperl, and I'd recommend them both. They are both well maintained (both released updates in this week) and the mailing lists for both are very responsive and helpful. AxKit presents XML data in whatever format you choose using XSL (or XPathScript), making it very powerful and giving it staying power (since it's standards based). I haven't had the need to use some of AxKit's other features (XPathScript, XSP), but that's because I've been able to accomplish everything I've needed to with XML/XSLT. I've been using HTML::Embperl for strict HTML presentation. I've recently begun to play with HTML::EmbperlObject (part of the same package), and I like it, a lot. It allows you to define a single file as a base template (or a skin to borrow another term), which is wrapped around individual components. This allows you to keep all of your standard headers and footers in a single file, while your forms and results sets can be defined in separate, self contained templates. Add onto that all of the capabilities of HTML::Embperl, and you've got quite a nice package. XPathScript XSLT These aren't really templating toolkits - just specifications that can be useful for transforming XML data to whatever format you choose. The AxKit site has lots of good information and links on both of these.
Re: comparison of templating methods?
On Wed, 6 Jun 2001, will trillich wrote: warning type=religious holy war level=pandora's box okay -- there's code (mod_perl modules) and there's html, and we should keep them separate -- which gives rise to templates... i've heard of Apache::PageKit Apache::Template AxKit eXtropia? HTML::Mason HTML::Embperl HTML::Template OpenBedrock Template-Toolkit XPathScript XSLT regarding the tools that dovetail into the mod_perl paradigm, who's got a comparison over relative performance (and other strengths/weaknesses) of various templating methods? This is your ultimate answer :) : Choosing a Templating System. http://conferences.oreillynet.com/cs/os2001/view/e_sess/1263 Hopefully Perrin will release his paper close to the conference. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
comparison of templating methods?
warning type=religious holy war level=pandora's box okay -- there's code (mod_perl modules) and there's html, and we should keep them separate -- which gives rise to templates... i've heard of Apache::PageKit Apache::Template AxKit eXtropia? HTML::Mason HTML::Embperl HTML::Template OpenBedrock Template-Toolkit XPathScript XSLT regarding the tools that dovetail into the mod_perl paradigm, who's got a comparison over relative performance (and other strengths/weaknesses) of various templating methods? -- #95: We are waking up and linking to each other. We are watching. But we are not waiting. -- www.cluetrain.com [EMAIL PROTECTED] http://sourceforge.net/projects/newbiedoc -- we need your brain! http://www.dontUthink.com/ -- your brain needs us!
Re: comparison of templating methods?
HTML::Embperl For me, this has one major win over the other toolkits: auto form population from a hash. The online mortgage application system I wrote has about 1,800 form fields, which have to be populated with data from a database. By making the form fields match DB column names, I can reduce the code to do this to: my $data = $dbh-fetchrow_hashref($query); %fdat = (%fdat, %$data); Embperl then parses the form and populates it with the matching name=value pairs in %fdat, including select options. Beautiful! Steve
Re: comparison of templating methods?
regarding the tools that dovetail into the mod_perl paradigm,
who's got a comparison over relative performance (and other
strengths/weaknesses) of various templating methods?
There are various discussions on the mod_perl list about this topic in the
past (so take a look at the archives). Also there was an start to write such
a comparsion, but I am not aware that anybody has really finished it. The
only benchmarks I know are from Joshua. I append his mail below.
NOTE: While the hello.xxx benchmarks only prints Hello world, so they only
measures the startup overhead of the toolkit, the h2000.xxx tests tends a
little bit more towards a real application.
Gerald
- Original Message -
From: Joshua Chamas [EMAIL PROTECTED]
To: Mod Perl [EMAIL PROTECTED]
Sent: Saturday, January 06, 2001 12:37 PM
Subject: Linux Hello World 2000, Results In!!
Hey,
The Hello World 2000 benchmark is complete, and my results are below
along with the Hello World benchmark. Please feel free to contribute
h2000 benchmarks for any environment, or suggest changes for those
in the test suite, download at http://www.chamas.com/bench/hello.tar.gz
The h2000 bench is geared toward web apps with templates.
Please note that I couldn't get a java String-Int type cast right,
so fudged one line in the h2000.jsp ( fix? ) Also note, as seen
below, I am using the latest versions of PHP IBM's Java, but not
of perl, so the results may not be fair in comparing the languages
on my platform.
--Josh
]# ./bench.pl -version -time=60 ( -h for help )
Test Name Test File Hits/sec Total Hits Total Time
sec/Hits Bytes/Hit
-- -- -- --
-- --
Apache::ASP v2.07 2000 h2000.asp 228.0 13687 hits 60.03 sec
0.004386 28997 byte
HTML::Embperl v2.0a18 2000 h2000.epl 247.3 14846 hits 60.04 sec
0.004044 28809 byte
HTML::Mason v0.895 2000h2000.mas 222.9 13378 hits 60.01 sec
0.004485 28798 byte
mod_caucho JSP 2000h2000.jsp 328.9 19741 hits 60.03 sec
0.003041 28964 byte
mod_php PHP 2000 h2000.php 261.8 15717 hits 60.04 sec
0.003820 28865 byte
Template v2.00 Toolkit 2000h2000.tt 55.6 3336 hits 60.01 sec
0.017987 2 byte
Apache::ASP v2.07 hello.asp 390.6 23444 hits 60.01 sec
0.002560 241 bytes
Apache::Dispatch v0.08 handler hello/worl 656.1 39374 hits 60.01 sec
0.001524 196 bytes
Apache::ePerl hello.eper 344.8 20687 hits 60.00 sec
0.002900 217 bytes
Apache::Registry v2.01 CGI Raw hello_raw. 706.4 42394 hits 60.02 sec
0.001416 52 bytes
Apache::Registry v2.01 CGI.pm hello.reg 458.5 27529 hits 60.03 sec
0.002181 216 bytes
Apache::SSI v2.16 hello.shtm 559.4 33571 hits 60.01 sec
0.001788 199 bytes
HTML statichello.html 1158.4 5 hits 43.16 sec
0.000863 311 bytes
HTML::Embperl v2.0a18 hello.epl 458.2 27496 hits 60.01 sec
0.002183 219 bytes
HTML::Mason v0.895 hello.mas 365.3 21925 hits 60.02 sec
0.002737 197 bytes
HTML::Template v2.0hello.htmp 567.2 34041 hits 60.01 sec
0.001763 198 bytes
mod_caucho JSP hello.jsp 860.6 5 hits 58.10 sec
0.001162 230 bytes
mod_include SSIhello.shtm 996.6 5 hits 50.17 sec
0.001003 198 bytes
mod_perl handler hello.benc 852.6 5 hits 58.64 sec
0.001173 196 bytes
mod_php PHPhello.php 734.8 44095 hits 60.01 sec
0.001361 225 bytes
Template v2.00 Toolkit hello.tt522.1 31338 hits 60.02 sec
0.001915 198 bytes
Apache Server Header Tokens
---
(Unix)
Apache/1.3.14
OpenSSL/0.9.6
PHP/4.0.3pl1
Resin/1.2.1
mod_perl/1.24
mod_ssl/2.7.1
PERL Version: 5.00503
JAVA Version: java version 1.3.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20001124 (JIT enabled:
jitc))
Operating System: Linux 2.2.14-5.0smp (root@porky) (gcc egcs-2.91.66) #1
2CPU [gate]
Re: comparison of templating methods?
On Thu, 7 Jun 2001, Steve Smith wrote: HTML::Embperl For me, this has one major win over the other toolkits: auto form population from a hash. The online mortgage application system I You may also fill in HTML forms with Apache::ASP and Apache::PageKit. With PageKit it automatically gets the data from the request parameters, but you may also set it using the fillinform method from the Model. Both of these applications use HTML::FillInForm to fill in the HTML Forms.
