Juerd's thoughts about Perl 6 web development Part one: Motivation and general thoughts
If you know me, you know that I never really liked Perl 5's CGI.pm. In essence, I like that it has enabled a lot of people to build dynamic web pages in a reasonably simple way. However, it was avery large monolithic piece of code that grew much too large. CGI.pm did things that reach far beyond the Common Gateway Specification. It had a lot of functionality that is often used with CGI programming, but isn't related to CGI specifically at all. I will, apart from this paragraph, refrain from comments about the coding style of CGI.pm. Perl 6 will also be used for web development. I think it's extremely important to have a very good de facto standard web development toolkit, that replaces the role that CGI.pm has played so far. We need to identify important functions of web development, and provide an easy way to them. Doing this, we should be careful not to provide a complex framework that beginners will find hard to understand, or that forces any particular structure to one's code. When Perl was still the most popular thing to use for dynamic web pages, little more than sending some data was done. Interactivity was often limited to a simple queries and responses, without much need for maintaining state in between. Nowadays, "sessions" are a very important aspect of web programming. Perl 5 provides a few ways of setting these up, but it's not part of the most popular web development toolkit, CGI.pm. CGI.pm does provide HTML generation functions. Why anyone would prefer to write exactly the same thing in an only slightly less awkward syntax, is entirely beyond me. One particular feature, sticky values in form elements, where the value from the request is used as the default value for the new form output, is very useful, though. A trend that I've noticed is that people begin by printing raw HTML, and add sticky values via HTML generation functions later. Some weird kind of sense for purity then often drives them to move entirely to HTML generation. Some smarter programmers use templating modules, often still relying on CGI.pm's form functions for pre-filling form fields. Sticky values are useful combined with form validation. If the given input data is invalid, you present the same form again, and prompt the user to fix their mistakes. With CGI.pm, the easy way to do this is to output an error message first, and then use the normal HTML generation functions to generate the HTML for form elements. However, users are now used to seeing the erroneous form field highlighted, with a more specific error message next to it. We should have an easy way to do that too. In the past years, Perl's leading position for web programming was taken over by PHP. This has to do with a lot of things. While PHP is technically inferior in numerous ways, it has a few strengths that make it very tempting for beginning programmers to pick this language over many others. Acknowledging that many of us dislike PHP for its programming language, we should try to accept that this product offers some things that Perl does not, most of which boil down to being usable out of the box. The programmer doesn't have to worry about all the details: many are delegated to the system administrator, which tends to be a good thing for bulk hosted web development. This opens up web programming to a much larger audience. Whether making it easy to write web programs is a good idea (in the light of security, spam, and overall code quality), is a different discussion. I personally would like things to be easy and simple, because I'm lazy. But I want this in a Perlish way, not a PHP-ish way. The Perlish way is, in my opinion and experience, more elegant and time saving. I stress that elegance and "line noise" are not mutually exclusive. Another recent development in web programming world is character encoding awareness. The times of letting the browser figure out what's going on are finally over. Modern web programming mostly uses UTF-8, and is explicit about that. We should make using UTF-8 in HTML output extremely easy, and highlight it in synopses and tutorials. Perl 5 had great Unicode support, and it is expected that it will be even better in Perl 6. We should use that to our users' advantage. Yet another recent development is XHTML. This is slowly becoming more popular. This is a very strict language, though, as it is based on XML. A document is either valid and unambiguous, or completely invalid. Because of this, XHTML needs to be a conscious choice, and never the default. That doesn't mean that choosing XHTML should be hard, and that our web toolkit only outputs HTML. I think we're obliged to implement both HTML and XHTML, whenever we generate output. This isn't necessarily related to HTML generation functions, but may also be important for HTML entities and carping. By consistently applying both HTML and XHTML, we set a good example for people who wish to extend the toolkit with new roles or classes. Web programming is normally done via HTTP, and this has two important stages that I think should be kept separated in code. They are the processing the request, and sending the response. Request and response can easily be represented by objects, as demonstrated in Perl 5's HTTP::Request and HTTP::Response. Other features are also important, but not fundamental. Already identified features are HTML form pre-filling ("sticky" values) and sessions. Fundamental features should be enabled by default, and other useful things should be provided as an option. Perl 6's roles can probably aid in composing the requested featureset in a single object. The name of the toolkit MUST NOT be "CGI". I want the name to indicate that the new toolkit is different from the Perl 5 CGI.pm. Not just because CGI was a bad name for that module anyway, but also to avoid confusion. A three letter name is attractive. I propose: Web. On the other hand, Template Toolkit is hard to search for using search engines like Google, so perhaps Web::Toolkit is a better name. This namespace could contain all the modules that are specifically catered to web development in general, entirely platform independent. CGI, mod_perl, HTTP::Daemon, it shouldn't matter. And these modules should be designed to work together. This doesn't necessarily require full planning and complex API's. It does, however, require a very solid base. I have some suggestions re its structure. I like the DRY principle. DRY stands for Don't Repeat Yourself. If someone chooses to output UTF-8, they shouldn't have to mention this with everything that outputs something. Likewise, when someone picks XHTML over HTML, this should be defined in one place and then used by every part of the toolkit. At the same time, these things should be overridable at any point. That can be done by temp'ing an attribute, for example. Next time I will write something about implementation. This will partly be from the perspective of implementation, partly based on examples of user oriented code. -- korajn salutojn, juerd waalboer: perl hacker <[EMAIL PROTECTED]> <http://juerd.nl/sig> convolution: ict solutions and consultancy <[EMAIL PROTECTED]>