[Kss-devel] Server response format

[Godefroid Chapelle]

Jeroen Vloothuis wrote:
> The current server side infrastructure generates XML/HTML output as a 
> response (aside from a test renderer used in unit tests). This rendering 
> has a problem in my opinion. I hope to illustrate the problems I see 
> with it so that we can either discuss a fix/replacement or you can 
> enlighten me on the design choices.
> 
> After alle headers etc. are generated the KSS response consists of:
> 
> <kukit:commands>
> <kukit:command tal:repeat="command context"
>       selector="div#demo" name="setHtmlAsChild"
>       selectorType=""
>       tal:attributes="selector python: command.getSelector();
>                       name python: command.getName();
>                       selectorType python: command.getSelectorType()">
>      <kukit:param tal:repeat="param python: command.params" name="html"
>              tal:attributes="name python: param.name"
>              tal:content="structure python: param.content">
>          <h1 xmlns="http://www.w3.org/1999/xhtml">it worked</h1>
>      </kukit:param>
> </kukit:command>
> </kukit:commands>
> 
> Using the structure statement means that all output is passed as is. 
> This has the implication of generating something like:
> 
> ...
> <kukit:param name="html">
>      <h1>it worked
> </kukit:param>
> ...
> 

IIRC, this would not work in some of the browsers that demand 
well-formed XML for XMLHTTPRequests.

> Code like that is obviously not valid XML. A problem with this is that 
> it breaks the whole response parsing. Therefore you do not get nice 
> local errors for the command which should actually break.
> 
> As far as I can see the current fix for this is to use BeautifulSoup to 
> fix up any broken data. In my opinion this is a fix to a problem which 
> should not be there in the first place.
> 
> For an application developer this implicit magic can have nasty side 
> effects when debugging styling problems (due to a wrong fix).
> 
> Like I said earlier I think the approach is flawed from the start. There 
> is no reason I can think of to alter the structure of the response 
> document. What I mean by this is that all data should be escaped and not 
> made part of the DOM.
> 
> So the earlier example would like like:
> 
> ...
> <kukit:param name="html">
>      &lt;h1&gt;it worked
> </kukit:param>
> ...
> 
> This would make it possible to write a schema for the KSS reponse and 
> validate it against that shema. If you allow arbitrary data this will 
> not be possible.
> 
> At the moment I do not see why escaping should not be default way. All 
> actions that need DOM force any string anyway (for use with client side 
> actions).
> 
> I would rather not duplicate the current behaviour (at least not until I 
> understand why it is done this way) in the new kss.commands package. So 
> please enlighten me on the design choices so that I may understand them.

IIRC, the main reason for this "broken" format is IE6. The trouble being 
its broken implementation for importing  in the browser document the 
nodes from the document in the response of the XMLHTTPRequest.

I am afraid you'd need to go through all the hurdles we overcame before 
finding a new format that really works.

One of those hurdles was the fact we had to be in the html namespace 
instead of being able to use the a plain kukit namespace.

However, if you can prove me wrong, I am all for a format that we could 
validate. Keep in mind that a new format would imply changes in the js 
client as well, iow stuff that would need to be tested in each browser 
that we want to support.

But I'd advise you to do this as a second step if you want to have a 
pure Python implementation. Do not underestimate the time invested in 
the current code ;-)
-- 
Godefroid Chapelle (aka __gotcha)- BubbleNet  http://bubblenet.be