Slashdot Mirror

Vim + Template Toolkit does it for me. Large sites or small, TT2 is the biz.

We too have used Emberl 1.3.x for 6 years, and we keep find all sorts of bugs with it. It has a heavy .xs layer, and have had many problems with Seg Faults. We're stuck with it for now because of legacy, but we're planning a move in the near future to Tempate Toolkit,

• Mason - Mason's syntax almost looks like php's <% %>, but it's perl.
• Template Toolkit - Another great templating language, it encourages you to seperate your code from your template, which is a good thing.

I second this! Templating systems abound, and are actually easier to use than embedding markup in code (or worse, code inside markup, as is possible with PHP[0]).

In fact, looking at Perl's HTML::Template module, one can see how easily and quickly anyone with HTML knowledge can make a template.

It's not just limited to HTML, either. The Template Toolkit is a very easy-to learn templating system that works for any kind of text-based templates. I've even seen it used to populate ODF documents...

Basically, there's just no excuse for not separating code and data this way in any kind of production code.

[0]: Not knocking PHP, here: good PHP programmers avoid escaping from markup into PHP, but PHP *does* make it possible. A lot of programmers abuse the capability.

A year ago, a friend asked me to help write a web page for her softball league, to track team rosters, etc. Having done a couple of web pages in Perl, and with about 10 years of Perl experience, it was my first thought. However, I'd been hearing a lot about PHP. So I read a PHP book and did a bit of experimenting.

To my mind, PHP is "Perl Lite". Yes, its nice to embed functionality directly in the page. But PHP is far too watered down in capabilities, and lacks CPAN. If you want markup functionality, give Template Toolkit a try. If you don't like TT, try Mason. Unless you want a canned Wiki that's easy to customize, I don't see a reason for PHP.

Why does everyone link CGI and perl like they were the same.

I write my CGI apps in bash. Yes, bash. Pipelines are fun and nearly unparalleled in any language for their power and flexibility, and I have a vast function library in the filesystem. Obviously this is neither secure nor performant, but that's the quick and dirty start.

When it needs to get more complex, I'll put it in perl either as mason components or a FastCGI. More FastCGI, less mason these days. Some of my stuff works better in python because it gets a boost from psyco, but from that point I start looking at a CGI app in good ol C++ (with a CGI library of course).

Long as we're plugging toolkits, I'll put in one for Template Toolkit. Probably a better bet than Mason if you're just looking for a template engine (Mason's better for complex components, especially ones that break, since it always gives you backtraces)

I'd like to argue that Perl is very maintainable. Many studies show a correlation between LOC and number of defects. So the important thing is reducing the LOC written. The differences accountable to language syntax is negligable when you can reduce the amount of code you write by order(s) of magnitude. With Perl, you have CPAN (http://search.cpan.org/), a repository of pre-written, tested code, the vast majority of which are classes ready to use in object-oriented fashion. Now, I'm not going to say that Perl's OO syntax is anything but inelegant, but it works. What is elegant is the way CPAN works. I won't go into that here, but it does allow you to decrease by orders of magnitude the amount of code you have to write. There are great solutions for all kinds of things, such as object-relational mapping (point Class::DBI at your database, and you instantly have get/set methods to update your tables) and powerful templating (http://template-toolkit.org/), just to name a couple. There are 4000+ other examples there.

As an example of reducing lines of code, here's an article on writing a database-driven web application in 18 lines of code, and a similar article here.

But this doesn't apply to just database or web frameworks. Thanks to CPAN, this applies to anything you set out to do. CPAN modules (in general; there are exceptions) are encapsulated best practices, well tested, and a major productivity booster. And, they drastically reduce the amount of code you need to write, making your code more maintainable.

Implementing a new template doesn't require touching any Perl code. The submitter simply needs to provide a new set of Template Toolkit templates.

The problem stems from the fact that slashdot's pages are generated from tons of little bits of template, and so taking someone's hack of a static front page doesn't really get you very far to having a working implementation.

We had a bunch of slightly different document formats that some hapless and unintelligent programmer elected to describe with XML.

Agreed. It would have been better to describe them in XML Schema (that's what it's for!), or in an XSL Template.

Unfortunately, XML has no control structures

XSL has control structures. It looks like your programmer has tried to use XML when it didn't quite fit.

the tools don't handle includes robustly

xinclude has been robust for me. As long as you're using modern parsers/processors, it should be robust.

there are no conditional constructs, no loops,

Again, it seems like what you wanted was XSL templated documents. Actually, any form of templating with conditionals and looping would probably work. I have done cool things with Template Toolkit. But when working with end-to-end XML, you can't beat XSL.

So if you have two invoice forms, one with 10 lines for detail items and one with 11, you are stuck with cut-and-paste-and-manually-edit as your primary software development model

Editing XML files is not software development! You should generate them. There are many ways to do it, but more details would be necessary to find the best way.

The problem with XML is that some people don't use it correctly. But that's true with any technology. There's nothing intrinsically wrong with XML.

The Perl equivalent is Class::DBI. This is quite a good module for working with databases, as it can save you from writing a lot of code. This article discusses the power of Class::DBI combined with the Template Toolkit, the best pure-MVC templating system there is. Maypole is a system built around these two modules that lets you create a complete Web-based database interface in as little as ten lines of code! Another Maypole article is here.

The Perl bit is already written. You just need to write a set of Template Toolkit templates. I seem to remember from looking before that the way they are used in Slash is pretty obvious once you find the template files in the source distribution.

Slash uses Template Toolkit. It's a nice system, but the Slash templates haven't changed much visually in years.

Slashcode uses Template Toolkit, which is quite a flexible (and separate) templating system written in Perl. Anyone who knows template toolkit could theoretically create a new slashdot theme and submit it. The garish section themes are created by swapping out a few of the template elements and introducing others in their place.

I don't know about how jumbled the perl and SQL are, but the template stuff's pretty divorced from the rest. See the Slashcode site, for example.

It's tough to write good docs. Once a client of mine wanted very thorough documentation (API docs, user's manual, etc) for a project beyond the README's and INSTALL's I usually bundle with the code.

I immediately doubled the estimate. Why? Because you are basically writing the logic of the app all over again, except in this funny programming language called "English". And when you update one you have to update the other. Not to mention you have to update your unit tests too (which is another thing most programmers don't do).

I'm not trying to make excuses or saying that we should skip documentation, it's just that it doesn't "scratch the itch". I don't believe that open source exists because of altruism, but because somebody solved their own problem and didn't keep it from the world. So we need folks who are truly interested in documentation (like technical writing geeks).

As open source grows we need to find all sorts of folks: technical writers, usability experts, designers, artists, testers.... we should also not be afraid to hold "fundraisers" to hire an outside team to do this. Wouldn't it rock if Mozilla, KDE, Gnome, etc., had a *thorough* going over with a talented usability team?

Anyway there's one concrete piece of advice I can give any open source programmer, especially if its not a gui-based tool: PUT EXAMPLE USAGE ON THE FRONT PAGE OF THE WEB SITE!!!

This annoys me to no end. Too many sites just have blocks of text describing how great their stuff is.. but no example of setting up a config file, running it from the command line, etc.

I would love to see a step-by-step up and running document, nothing fancy. Show some examples of what your config files and so forth look like. How about screen shots of command line operation? If it's too complicated to show in a few pages, *simplify it*.

The quicker I can get your program up and running, and the less work I have to do, the less I have to hack in my existing configs and so forth, the faster I will be sending you patches.

Positive example: The awesome Ruby on Rails framework has a setup *movie* showing exactly how to go from zero to app in 10 minutes. I wish all projects had something like that, and more importantly, I wish all projects were SIMPLE enough to demo in a few minutes.

Negative example: I was wondering if Perl's Template Toolkit was the right template system for me. I was looking for a very basic kit that could mix Perl directly with HTML (a-la PHP) with no fluff and bloat. I couldn't see any example on the front page and after a minimal amount of searching, I still had no idea what it was like to actually *use* the damn thing. Just bullet lists of features (which are shared by pretty much all similar systems).

So, as a first step down the road of good documentation, try this user-focused idea: give some examples up front.

I really wish the parent didn't use buzzwordy phrases like "enabling rapid development methodologies," because the aforementioned tools really do kick some serious ass (once combined with a proper templating system.

Slashcode does indeed use templates, based on the Template Toolkit Perl module. It's actually quite slick.

There's a web-based interface to edit the templates which, IMHO, is a bit less slick, but it works.

(I commercially hosted Slashcode sites for a couple years.)

And indeed, I did exactly that once for a site -- changed a few templates and the resulting site was reasonably standards compliant. Wasn't hard at all. Why Taco hasn't done it here yet is way beyond my comprehension.

Installing Perl's as simple as downloading the msi from Activestate and double clicking it, and then clicking the standard 'yep, install me' stuff. I assume that Python and stuff is that easy on windows too (I've never had to install it on Win32)

Perl comes with lots of documentation, and it's as simple as writting a program and typing 'perl program_name' to run it. This is important as a kid - quick feedback. Something that's hard with languages like C and Java...and most importantly you don't need things main procedures and other fluff.

Of course, many people are going to suggest that even Perl's too complicated and contains too many punctuation marks for a beginner. I'd suggest then that they install the template toolkit with ppm (one command from the command line.) Then they can use that little programming langauges to make web pages really easily. Kids want to create things worthwhile (not just learn programming to print "hello world",) and learning how to create web pages with the Template Toolkit's a great way to get started.

Right, let the "I hate Perl, it ate my hampster" trolling begin.

The method you described for your web generation seems to be a rudimentary re-implimentation of the Template Toolkit Perl modules, probably the best way to generate templated material in Perl, and certainly preferable (IHMO) to either having code in the HTML, or HTML in the code...

True separation of business and display logic.

Do all your processing, calculating, searching, formulating, control flow in perl with no HTML to be seen. Whack all your data in a hash. Pass said hash to Template->process(). Then any [% variable %] text in the HTML looks in the hash. Every web designer worth their salt can deal with that. What is great too is that [% %] comes as ordinary copy in Dreamweaver et alia. They can see where it's going to go. This has its limitations though. Some designers don't grasp the concept of dynamically generated hidden fields to pass variables in a session stack. They tend to omit important tracking stuff.

Also Templates [TT2 being the favourite] will generate your emails. Combined with the rather strenuous Text::Autoformat, you get freakin' nicely formatted text emails.

Of course, one such example of a domain language is the Template Toolkit which is a language that's inside out and designed to be used in places like webpages and config scripts. It's used in Slashdot, and written in Perl (and can call perl routines really easily called.) There's a good justification why not to use pure Perl in the template in the manual

Of course, come Perl 6 we'll be able to redefine our own grammers. By using a module (technically a grammer) we'll be able to dynamically switch in anohter rule (er, perl 6 regex able to match grammers) in the current scope to parse the current section - essentially our own little mini langauge.

You never heard of mod_perl, FastCGI, Embperl, or the Template Toolkit if you're still talking about PERL CGI scripts, have you?

Apache and PERL is still the bleeding edge of web developement. It's just no more alone at the top. Perhaps you should take a look on these Benchmarks. Especially the JSP don't look very good there and Embperl2 is usually very close to PHP regarding performance. Only Apache modules written in C are without real competitor. But you should also think about the ease of developent if you compare C code with PERL, PHP, ASP or JSP.

Inadequate. HTML::Template is not even close to the functionality of Template Toolkit. TT2 has WRAPPER, VIEW, FILTER, THROW and CATCH, parameterized includes, variable scoping, and a great deal more. htmltmpl doesn't even cache.

I don't know if this is because of Perl's easier level of entry, or the quality of coders interested in the project, or the project leader Andy Wardley, but it's great to see. It's one of the reasons this project has gone so far so quickly. Not too long ago, TT was just an idea, and now it generates every page on Slashdot.

Well, individual users cannot have themes. But you can easily distribute a set of "templates" (see Template Toolkit for your theme and a site can install them. Pretty much all the layout is controlled through templates, and it is very flexible.

Here are a few technologies to consider (using Perl):

• Apache::ASP
• Embperl
• Mason
• Template::Toolkit

There are many more, but these are the ones I would consider for people who already know ASP. Apache::ASP looks like a very mature and solid product, as does Embperl. I would trust either of those.

Also, is there a business need to convert the existing ASP code to work with the new platform? If so, you might consider looking into ASP2PHP, if you're already considering PHP. The author says that it will convert most of the code to PHP.

Also, I can tell you that there is (sort of) a project in the works right now to build an ASP to Apache::ASP/Perl converter and/or interpreter. To follow this, just keep an eye on the mod_perl mailing list at one of the archive locations. It will probably be called VBScript::Parser. See http://perl.apache.org/#maillists for a list of searchable archives. Most of them are updated weekly.

Also, I've noticed some comments along the lines of "JSP is without a doubt the best/fastest technology out there". Uh... Where is your proof on this? I have a suggestion, go to the mod_perl mailing list and make this statement. See where it gets you. According to them, "It's widely accepted that server side Java solutions such as JServ, JSP and JRUN, are far slower then mod_perl solutions" (http://perl. apache.org/perl_myth.html#Java_does_away_with_the_ need_for).

That being said, I think that JSP is a fine technology, and there is nothing wrong with using it. I'm about to embark on a project myself using JSP. Just don't try to tell people it's the "Holy Grail". That's more than arguable.