Web development I: Web::Toolkit
Juerd
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 <ju...@juerd.nl> <http://juerd.nl/sig>
convolution: ict solutions and consultancy <sa...@convolution.nl>
Amir E. Aharoni
> This is a very strict language, though, as it is based on XML.
> A document is either valid and unambiguous, or completely invalid.
Just like any programming language should be. And the XHTML rules are
quite reasonable. In practice *all* browsers effectively encourage
developers not to follow the strict standard, by allowing invalid
HTML. I usually browse the web with Firefox and HTML-Tidy extension,
and see very few sites that conform to any w3c standard.
> Because of this, XHTML needs to be a conscious choice, and never the
> default.
WordPress is an example of a webserver software tool that does try to
produce standard XHTML. It does it by default and very few bloggers
who use it care about it or, for that matter, notice it.
FuturisticPerl6WebPackage.pm should be like that too. I see no reason
that autogenerated code won't conform to standard XHTML. Every
deviation from standards and XML well-formedness should produce a
warning.
Wishful thinking: FuturisticPerl6WebPackage.pm could have
functionality that will output XHTML that adheres to both the
w3c-standard and the defacto-standard (warning about tags that only
works in certain browsers etc.) It might make it easier for developers
to test their sites on several browsers and platforms.
Aankhen
> WordPress is an example of a webserver software tool that does try to
> produce standard XHTML. It does it by default and very few bloggers
> who use it care about it or, for that matter, notice it.
> FuturisticPerl6WebPackage.pm should be like that too. I see no reason
> that autogenerated code won't conform to standard XHTML. Every
> deviation from standards and XML well-formedness should produce a
> warning.
The point is not to have autogenerated code conform to the XHTML
standard. The point is to not use XHTML simply because it's shiny.
XHTML 1.0 and 1.1 offer no practical benefits over HTML, but tangible
disadvantages. Using XHTML unnecessarily complicates processing and
adds lots of gotchas. If someone still wishes to use it, Web.pm (or
Web::Toolkit or Moo.pm or whatever it's called eventually) should be
perfectly capable of producing well-formed XHTML... but please, not
XHTML by default.
> Wishful thinking: FuturisticPerl6WebPackage.pm could have
> functionality that will output XHTML that adheres to both the
> w3c-standard and the defacto-standard (warning about tags that only
> works in certain browsers etc.) It might make it easier for developers
> to test their sites on several browsers and platforms.
The majority of problems arising in authoring documents for the Web
are due to poor implementations of CSS, not poor implementations of
HTML. If the XHTML produced by the module adheres to the W3C
standard, there won't be any elements that only work in certain
browsers (with the exception of <abbr>... no others I can think of
offhand).
Aankhen
--
"I meant *our* species."
"You said *your* species."
"Evidently I am insane. May I go now?"
Juerd
> 17/09/06, Juerd <ju...@convolution.nl> skribis:
> > This is a very strict language, though, as it is based on XML.
> > A document is either valid and unambiguous, or completely invalid.
> Just like any programming language should be.
X?HTML is not a programming language. But I don't want to discuss the
benefits and disadvantages of XHTML at all, except to mention that both
do have benefits and disadvantages.
> > Because of this, XHTML needs to be a conscious choice, and never the
> > default.
> WordPress is an example of a webserver software tool that does try to
> produce standard XHTML.
That's great. Our tool will not produce documents, though.
Our tool will produce incomplete X?HTML, and thus must support both HTML
and XHTML. An empty tag created for XHTML is not valid HTML, and vice
versa.
XHTML is a promise for very strict output. HTML is so much less. We
should try to avoid promising things on our users' behalves.
People who wish to output XHTML from a program that they write, have
consciously chosen for it. HTML on the other hand can safely be assumed
by default: browsers won't display error pages on invalid input.
> It does it by default and very few bloggers who use it care about it
> or, for that matter, notice it. FuturisticPerl6WebPackage.pm should
> be like that too.
I disagree strongly. If we were publishing entire documents, then by all
means let it be XHTML, as it is expected to be the future standard. But
we're not!
> I see no reason that autogenerated code won't conform to standard
> XHTML.
Open your eyes.
> Every deviation from standards and XML well-formedness should produce
> a warning.
You seem to be forgetting that Perl is all-purpose, and has a very
different cultural background than XML.
> Wishful thinking: FuturisticPerl6WebPackage.pm could have
> functionality that will output XHTML that adheres to both the
> w3c-standard and the defacto-standard (warning about tags that only
> works in certain browsers etc.) It might make it easier for developers
> to test their sites on several browsers and platforms.
I do not want to use any web programming toolkit, Perl or other
language, that without my explicit request scans my output and/or whines
about it.
Juerd
> The point is not to have autogenerated code conform to the XHTML
> standard. The point is to not use XHTML simply because it's shiny.
That's a good point, but my point was different.
XHTML should be a conscious choice, not a default, in a general purpose
web development library.
A. Pagaltzis
> WordPress is an example of a webserver software tool that does
> try to produce standard XHTML. It does it by default and very
> few bloggers who use it care about it or, for that matter,
> notice it.
Psh, whatever. Everyone serves their XHTML as `text/html`, in
which case no browser cares about the fact that it is supposedly
XML, and instead uses the tagsoup parser. Almost everyone who
thinks they’re serving XHTML is actually serving funny-looking
HTML (and that is broken according to SGML rules). Sites which
actually serve their markup as `application/xhtml+xml` are very
rare, not least because the MSFT browser doesn’t support the MIME
type. Many of those who do so, actually serve the *same* markup
as `text/html` to IE and as `application/xhtml+xml` to modern
browsers – which is very dumb for many reasons (that I can
expound on at request).
I have reluctantly had to realise that unless you need to embed
SVG, MathML or other XML vocabularies, choosing XHTML is a stupid
idea.
* Aankhen <aan...@gmail.com> [2006-09-17 21:00]:
> XHTML 1.0 and 1.1 offer no practical benefits over HTML, but
> tangible disadvantages.
To be fair, XHTML does let you embed MathML and SVG (as well as
XForms, pending browser support) in your markup, which is a great
boon where applicable. But that’s the only benefit XHTML provides
as of yet.
> If the XHTML produced by the module adheres to the W3C
> standard, there won't be any elements that only work in certain
> browsers (with the exception of <abbr>... no others I can think
> of offhand).
Plenty. IE6 doesn’t understand `q`, off the top of my head. I
know there are several more, plus a few that *no* browser
supports. On top of this, roughly 80% (or so it sometimes feels)
of the useful attributes defined in HTML do not have any tangible
browser support (such as `cite` on `blockquote`/`q`, or
`datetime` on `ins`/`del`).
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Thomas Wittek
> On top of this, roughly 80% (or so it sometimes feels)
> of the useful attributes defined in HTML do not have any tangible
> browser support (such as `cite` on `blockquote`/`q`, or
> `datetime` on `ins`/`del`).
At least without CSS. You can use those tags to create a more semantic
markup which can be styled using CSS.
Of course there is more than just design. The cite attribute of the
blockquote tag isn't supported by any browser AFAIK.
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: strea...@jabber.i-pobox.net
Aankhen
> * Aankhen <aan...@gmail.com> [2006-09-17 21:00]:
> > XHTML 1.0 and 1.1 offer no practical benefits over HTML, but
> > tangible disadvantages.
>
> To be fair, XHTML does let you embed MathML and SVG (as well as
> XForms, pending browser support) in your markup, which is a great
> boon where applicable. But that's the only benefit XHTML provides
> as of yet.
Not XHTML 1.0 and XHTML 1.1... there you need to use the compound
document types, e.g. XHTML + SVG + MathML. Since we're being fair,
XHTML 1.1 also offers specific elements for Ruby[1].
> > If the XHTML produced by the module adheres to the W3C
> > standard, there won't be any elements that only work in certain
> > browsers (with the exception of <abbr>... no others I can think
> > of offhand).
>
> Plenty. IE6 doesn't understand `q`, off the top of my head. I
> know there are several more, plus a few that *no* browser
> supports. On top of this, roughly 80% (or so it sometimes feels)
> of the useful attributes defined in HTML do not have any tangible
> browser support (such as `cite` on `blockquote`/`q`, or
> `datetime` on `ins`/`del`).
IE doesn't render q correctly, but the content of the element is still
available. As far as the attributes go, that's a UI problem with the
browsers. :-) Come to think of it, as long as those attributes show up
in the DOM correctly, I don't see how you could not support them.
Perhaps we could say no *useful* browser support?
[1] http://www.w3.org/TR/2001/REC-ruby-20010531/
Aankhen
A. Pagaltzis
> On 9/19/06, A. Pagaltzis <paga...@gmx.de> wrote:
> >On top of this, roughly 80% (or so it sometimes feels) of the
> >useful attributes defined in HTML do not have any tangible
> >browser support (such as `cite` on `blockquote`/`q`, or
> >`datetime` on `ins`/`del`).
>
> don't see how you could not support them. Perhaps we could say
> no *useful* browser support?
I did qualify my statement.
Aankhen
> I did qualify my statement.
I'm sorry, I must have missed it. :-)
Aankhen