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

[Avi Bryant]

On Aug 31, 2004, at 12:31 AM, radoslav hodnicak wrote:

> On Mon, 30 Aug 2004, Avi Bryant wrote:
>
>> Soon... see below for my plans.
>
> http://4096.sk/~rh/Seaside2.5b2-rh.3.mcz
>
> My changes for the live XMLHttpRequest stuff to allow updating multiple
> elements as well as only attributes (changed the live test class to
> demostrate it).

Thanks.  There are several changes here, so let me see if I've got them 
straight.  First there are three that are, AFAICT, independent of 
anything else:

1) There's a change to WAWalkback to show inst vars as well as temps.  
I've now incorporated this into the 2.5b line.
2) You've added #selectInputOn:of:list:liveAction:, as well as 
liveSelect() in the javascript.  It looks worth including, but I 
haven't done so yet.
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?

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?
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.

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?
Avi