[Seaside] releases (was re: registerObjectForBacktracking, submit and execute block)

[radoslav hodnicak]

On Thu, 2 Sep 2004, Avi Bryant wrote:

> 3) You include a timestamp in the update URL to prevent caching.  I'm
> not sure about this one; shouldn't this be doable with headers instead?
>   Is IE really so broken that this is necessary?

Yes it is. If you XMLHttpRequest (that's verb :-)) an url that was
accessed before you'll get the old result (no connection to web server is
made). If this can be prevented using headers I don't know.

> Then there are three that are fairly coupled:
>
> 1) You've changed #urlForLiveRequest: to use text/xml, and put
> everything under the top-level tags into CDATA.
> 2) Because the DOM can now be directly addressed by Javascript, you can
> easily pull out and update multiple top-level elements.  But the main
> content is in a CDATA, so that you can still use innerHTML.
> 3) Again, because the top-level elements can now be directly addressed,
> you can easily update just the attributes (if cued by a special marker
> attribute) of the top-level elements.
>
> There are a couple of things that make me uneasy here.  First, allowing
> 2) and 3) is nice, but also adds to the complexity of the API a fair
> bit.  I'm not totally sure it's worthwhile for the extra efficiency.
> What are the use cases where these were especially useful?

Uhm what do you mean with efficiency? I certainly want to be able to
update several elements at once - what would be the solution otherwise -
sending several xmlhttprequests each updating one element?

> Second, I definitely don't like the implementation using CDATA - it
> means the document we're returning isn't a useful HTML or XHTML
> document, but a strange hybrid that only makes sense in the particular
> context of the client-side Javascript.  I understand the pragmatic
> reasons for this, but it feels like a hack and I'd like to avoid it if
> at all possible.

First let me say that this implementation is result of my inability to
write a regex that would do the same :-). Yeah it's a hack, I freely admit
that. After two days fighting with DOM and cursing at inept javascript
debuggers I was glad to get it to work at all.

> If we're going in that direction, I would rather completely throw away
> any pretense that what we're returning is a piece of an HTML document,
> and return some structured XML document instead with explicit
> declarations like
>
> <update id="foo">
> 	<innerHTML>
> 	... CDATA here ...
> 	</innerHTML>
> </update>
>
> <update id="bar">
> 	<attribute name="class" value="whatever"/>
> </update>
>
> Thoughts?

I'm really fine with any implementation that works, more hackish or less
hackish. Because it's hidden. In my live update code (in seaside) I just
render various parts of the page like I always do.

Btw did you find out why my changes don't work in safari?

rado