Re: Web development I: Web::Toolkit

[A. Pagaltzis]

* Amir E. Aharoni <[EMAIL PROTECTED]> [2006-09-17 16:25]:
> 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 <[EMAIL PROTECTED]> [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 ... 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 // 

Re: the CGI.pm in Perl 6

[A. Pagaltzis]

* Randal L. Schwartz  [2006-09-19 21:25]:
> The form-generation stuff needs tight coupling with the getting
> (and setting) of the incoming param values.  You couldn't just
> use two random modules for that... they'd have to specifically
> know about each other and work together.

Err, no. They just need a known protocol, and the semantics of
CGI.pm’s `param` method have spread pretty widely and are now
used by many other modules as well. In general, you can pass
instances from any of these modules to anything that expects
something that speaks that protocol and they work just fine.
F.ex., you can pass CGI::Simple objects into HTML::Template for
variable prepopuluation and it Just Works because they talk to
each other using the CGI.pm `param` protocol.

Form handling clearly requires no coupling.

Regards,
-- 
Aristotle Pagaltzis // 

Re: the CGI.pm in Perl 6 (create a design on the wiki)

[Mark Stosberg]

Juerd wrote:
> 
> It does make sense to have a single toolkit that does all this. It does
> not make sense to have a single .pm that does all this. There's
> absolutely no need for having all these different tasks in one module.
> There's not even any benefit. You can just as well use a couple of
> nicely named, grouped, and reasonably standalone roles or classes, and
> then a single module to combine them all for the ease of use that you
> like.

I suggest that those who have concrete ideas sketch out the API through
a new page on the wiki. That could make it easier for someone else to
pick up, if they have programming skill, but less API design experience.
The result might be even multiple API designs (A more compatible CGI.pm
and cleaner/newer/different Web.pm solution).

http://rakudo.org/perl6/index.cgi

 Mark

Re: the CGI.pm in Perl 6

[Juerd]

Randal L. Schwartz skribis 2006-09-19  8:16 (-0700):
> No, it's an *integrated* task.  The form-generation stuff needs tight coupling
> with the getting (and setting) of the incoming param values.

Integrated task? Tight coupling? If I didn't know you, I'd immediately
say you have no idea what you're talking about. But you do, so I'm a bit
puzzled as to why you would say this. Could you explain your point of
view a bit further?

The only coupling needed is the getting of "param"s. This can be done
perfectly by passing the CGI object, or (uglier) by using a subclass of
CGI.pm. In Perl 6, it can be done by adding HTML generation as a role to
the existing object.

In fact, CGI.pm itself only uses ->param and utility functions that are
specific to HTML generation, in methods like _textfield.

> You couldn't just use two random modules for that... they'd have to
> specifically know about each other and work together.

There's a tradition of treating CGI.pm's param method as an known
protocol, and often you can pass a CGI object, or any other object witha
similar param method, to certain modules. One of them is
HTML::FillInForm, which proves rather directly that no tight coupling or
integration is needed, at all. A simple method with a strict definition
is enough, and CGI.pm has provided just that. 

It's okay to have two modules that were designed to work together, as it
is okay to have one module depend on and use another.

Otherwise, why would you still want to factor things into separate
modules anyway? Maintenance and usability are important issues, but
being able to use only what you need is quite attractive too. CGI.pm
uses elaborate autoloading techniques, that would not be needed, or
could be much simpler, if there was clear separation of tasks from the
beginning.

> That's why it's great that it's all in CGI.pm.  If I just want param
> handling, I import/compile only that part.  If I also want sticky
> forms, I just ask it for a bit more.  And as long as I'm there, I
> import "header" or "redirect" or "cookie" to do that "last bit" of my
> application.  CGI.pm has the *right* mix for small tasks.  It *does*
> make sense.

It does make sense to have a single toolkit that does all this. It does
not make sense to have a single .pm that does all this. There's
absolutely no need for having all these different tasks in one module.
There's not even any benefit. You can just as well use a couple of
nicely named, grouped, and reasonably standalone roles or classes, and
then a single module to combine them all for the ease of use that you
like.
-- 
korajn salutojn,

  juerd waalboer:  perl hacker  <[EMAIL PROTECTED]>  
  convolution: ict solutions and consultancy <[EMAIL PROTECTED]>

Re: the CGI.pm in Perl 6

[Steve Pitchford]

Randal L. Schwartz wrote:


"David" == David Cantrell <[EMAIL PROTECTED]> writes:
   



 


But don't throw out the simplicity of CGI.pm's basic task handling: parsing
the incoming parameters (including file upload), and generating sticky forms
and other common HTML elements.
 



David> That's two tasks.  It should be two modules.

No, it's an *integrated* task.  The form-generation stuff needs tight coupling
with the getting (and setting) of the incoming param values.  You couldn't
just use two random modules for that... they'd have to specifically know about
each other and work together.

That's why it's great that it's all in CGI.pm.  If I just want param handling,
I import/compile only that part.  If I also want sticky forms, I just ask it
for a bit more.  And as long as I'm there, I import "header" or "redirect" or
"cookie" to do that "last bit" of my application.  CGI.pm has the *right*
mix for small tasks.  It *does* make sense.

 

To be honest I'm not sure I follow your argument. Why does populating a 
form from incoming form data require "closer integration"
than, say, pulling it out of a database and populating a form for 
further editing?. Surely its just a question of a consistant interface?


Forgive me if I have misunderstood your point.

Steve

Re: the CGI.pm in Perl 6

[Thomas Wittek]

(Randal L. Schwartz) schrieb:
> > "David" == David Cantrell <[EMAIL PROTECTED]> writes:
> David> That's two tasks.  It should be two modules.
>
> No, it's an *integrated* task.  The form-generation stuff needs tight
> coupling
> with the getting (and setting) of the incoming param values.

A separate module, say HTML::Formgenerator, could easily use CGI.pm (or
Web.pm,...) to get and set parameters:

  $value = $query->param('foo');

  $query->param('foo','an','array','of','values');

I see no need to integrate those modules.

Regards
-- 
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]

Re: the CGI.pm in Perl 6

[Randal L. Schwartz]

> "David" == David Cantrell <[EMAIL PROTECTED]> writes:

>> But don't throw out the simplicity of CGI.pm's basic task handling: parsing
>> the incoming parameters (including file upload), and generating sticky forms
>> and other common HTML elements.

David> That's two tasks.  It should be two modules.

No, it's an *integrated* task.  The form-generation stuff needs tight coupling
with the getting (and setting) of the incoming param values.  You couldn't
just use two random modules for that... they'd have to specifically know about
each other and work together.

That's why it's great that it's all in CGI.pm.  If I just want param handling,
I import/compile only that part.  If I also want sticky forms, I just ask it
for a bit more.  And as long as I'm there, I import "header" or "redirect" or
"cookie" to do that "last bit" of my application.  CGI.pm has the *right*
mix for small tasks.  It *does* make sense.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
 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!