Re: Checking server-side code

At 06:15 2000-05-19 -0400, Charles McCathieNevile wrote:
>The first piece about a prompt at save time is an implementation decision -
>it applies to a tool like homesite, which requires another app to preview and
>therefore needs the document to be saved, but it is irrelevant to a WYSIWYG
>tool in many cases, especially a multi-view, stylesheet capable tool like
>amaya.
>
>The more serious part of this is the assertion that we cannot check
>server-side code for accessibility - I disagree fairly strongly. To use an
>example of cold fusion, a tool like CFStudio can check whether things like
>alternative content are going to be produced in the final result.

For a server-side scripting or programming language you'd have to re-implement and interpret that language to be able to determine whether something will be produced that requires alternative content and whether that alternative content would be produced as well. For example, the decision whether or not to dynamically generate (!) an image and its ALT attribute may be three levels deep in severla nested conditional loops or case constructs.

CFStudio itself does not even interpret CFML (that's what the application server does); tools like HomeSite and Studio cannot possibly implement and interpret all server-side languages they (potentially) support: CFML, Perl, ASP, PHP, JSP, Java, MIVA... That's the job of the application server or server-side interpreter.

>To take
>Lotus Notes as another example, the template can check whether there is
>alternative content, and the database can check whether there is a value (or
>an explicit null) specified that can be used - the AIMM technique of
>checkpoint 4.6 (I think).

If it's simply a question of pulling a value from a database - maybe. But that's too simple. Real-life applications may be (I think usually are) far more complicated. We're no longer talking about documents - we're talking about applications, some parts of which in certain circumstances may produce part of a page - or whole complexes of pages in other circumstances.

The only realistic option in the case of server-side languages is to check the *resulting* HTML pages.

>  There are other examples - checking everything may
>be difficult, but for many of the cases where we have automated checking
>algorithms it is not really a quantum leap (although it is clearly extra
>work - there needs to be some dry-run of the code in the tool).

Building a (client-side!) interpreter for all (and more) of the languages I mentioned certainly would be a quantum leap. And I predict it's not going to happen.


>In a batch processor we run into a similar problem - there are two parts, and
>in one the tool can check that alternative content will be generated at all
>(or that the document will end up with structured content, or whatever) and
>in the other it can check the content that it runs on to ensure that the
>requied initial information is present.
>
>cheers
>
>Charles McCN
>
>On Thu, 18 May 2000, Marjolein Katsma wrote:
>[snip]
>   A prompt at saving is also out of the question: depending on the work
>   method some documents will have to be saved literally hundreds of times
>   while being worked on, before it's finalized. Also we should take into
>   account that frequently the document being created or edited is not
>   itself HTML but (a combination with) server-side code which will
>   ultimately _generate_ the HTML to be sent to the browser; accessibility
>   does not apply to server-side code, so even (forced) prompting at
>   deployment time (as opposed to saving) is not an option in many cases:
>   the server-side code is what will be deployed but only the resulting HTML
>   (i.e., after deployment) can be checked.
>   

Marjolein Katsma
HomeSite Help - http://hshelp.com/
Bookstore for Webmasters - http://hshelp.com/bookstore/bookstore.html

Received on Friday, 19 May 2000 11:34:23 UTC