Forum OpenACS Development: Re: Checks for HTML standard compliance

Collapse
Posted by Antonio Pisano on
A tcl/xotcl brand new validator is something I didn't want to put in the mix for now, as it would require efforts and many tests before we can rely on it. Unless someone says and proves it is very easy...

I think I can come up with something that does what I proposed, but I need a little tip.

Resuming my proposal:
into Developer Support I would put a new feature which could be turned on and off at will. When turned on, for every request which mime/type is 'text/html' (or other kind of markup subject to validation, but we could start just with HTML/XHTML for now) produced text will be sent to a validation command. Such command could be a callback or be specified by a parameter, what matters is that it is capable of telling if page is invalid and where/why.

The result of the validation will then be logged into a table. There will be a UI to inspect/manage this logging into DS and also to configure what to log. We could, for example, log only request issued by a certain user, or into a certain package, or on a single page, so one could test a page without putting server to its knees.

I would log:
- user issuing request
- timestamp
- package_key of the request
- package version
- url
- page parameters (GET/POST)
- actual script being executed
- page content
- row/column of validation error
- description of the error

I know some of this information is already logged/collected by the request processor, but I still don't understand where exactly.

What I need to know from someone with some more insights is:
- where can I intercept page content just before it is served?
- are there already tables collecting some of the stats I described?
- is this something worth trying in the first place??

Collapse
Posted by Michael Aram on
Hi Antonio,

I have had practically exactly the same feature in mind for quite some time now (extending the DS with a toggle that [dis|en]ables (X)HTML validation of the generated output). Therefore, I naturally do second your proposal in general, although I think that overall this does not have a very high priority for the OpenACS project (especially if in-browser plugins exists that basically do the same job).

All the best,
Michael