Fwd: Re: [Web-SIG] Client-side support: what are we aiming for?

[John J Lee]

On Fri, 24 Oct 2003, Moof wrote:

> David Fraser wrote:
>
>
>  > Actually HTML parsing would be fantastic for testing web
> applications, > so maybe that could be related to the Web API.
>
>
> Actually, that is a very important point. Many python programmers are
> fans of Test-driven development. I'm currently developing an app with
> Webware and Cheetah, and find it very difficult to write tests for a lot
> of the stuff I do. This is mostly due to a huge amount of background
> work I need to do to set up an emulation environment first (make sure my
> request and session objects work correctly as far as I need them to for
> my testing, replacing the Page write and writeln methods, and so on) and
> even then, verifying a whole generated page is a pain.

Isn't it the fault of the framework you're using if it doesn't make unit
testing easy?  Still, I guess it's true that HTML parsing is a necessary
part of some unit tests (not only functional tests).


> So a standard HTML parser would be nice, as well as keeping TDD in mind
> when we design request and response (and possibly session) objects.

We already have an HTML parser (two, in fact).


>  > The parsing doesn't have to be very intelligent or do validation,
> HTML > syntax is fairly simple.
>  > I think that does belong in the standard library.
>
>
> Speaking of validation, a sort of standard form validation library would
> be nice: something to say "I'm expecting this value to be an int between
> 1-31" or "I'm expecting this to be a string with the following legal
> characters" and so on. It's not that difficult to write yourself, but I
> seem to find myself reinventing the wheel every time I do. A standard
> "best practice" way of doing this would be wonderful.

I guess that would look similar to ClientForm?  If not, what?

I'm not enthusiastic about putting something like that in the std lib.
One reason is that, unless you build it on top of a DOM-like API, you end
up with a library that gets you 'so far and no further' -- as soon as you
need to know what that <a href> URL is (the one underneath the third table
from the top), you're stuck, because the parser that built the forms
object model didn't record that.  So, it makes a lot of sense to build
this kind of forms- and tables-parsing code on top of a DOM-like API that
represents the whole document, not just the forms and/or the tables.  And
if you're going to be DOM-*like*, it makes sense to do it on top of the
HTML DOM *itself*, so you can support embedded scripting.  But HTML DOM
'as deployed' in browsers is not pretty, and doesn't really belong in the
standard library.  Well, that was the train of thought that lead to
DOMForm, anyway.  I can see that embedded scripting might be of little
interest to many people, so maybe there's a place for a Pythonic HTML
DOM-like API in the std lib.  Does anybody else care about
interoperability with the HTML DOM proper, or is it just me?


John