[Seaside] Quick question

Avi Bryant avi.bryant at gmail.com
Thu Oct 20 18:50:16 UTC 2005


On Oct 20, 2005, at 10:59 AM, William E Harford wrote:

> So how would an ancestor of WAScriptLibrary be able to override a body
> callback if it was specified in the HTML? Am I missing something
> obvious?
>
> I am pretty sure this can be done pragmatically in JavaScript.
> I have not tried it but would something like the below work?
>
> ...
>
> oldOnload = document.body.onload;
> function newOnload(){
>     oldOnload();
>     whatEver();
> }
> document.body.onload = newOnload;
>
> ...
>
> Again I have not tried this so it may or may not work.

Yes, I'm sure it's possible to get something like that to work.  But  
if the general idea is to get whatEver() (presumably implemented in  
your script library) added to the onLoad(), then the best thing to do  
is to add

self session addLoadScript: 'whatEver()'

somewhere in your render methods.
>
> It also seams kind of inconsistent to have seaside handle the body's
> onload callback in this new manner but not any other callbacks.

Well, the body's onload callback is unique - there's only one of  
them, so we need to manage sharing it somehow.  I also wanted to be  
able to specify load scripts both before the rendering process even  
starts (ie, from action callbacks), and after the <head> has been  
finished.  That's where the current mechanism came from, though I'm  
very open to other suggestions.

> My dream html renderer would allow me to manipulate  any arbitrary  
> part
> of the yet to be sent html page. So for example ....
>
> (html root tag: 'body') onLoad:'newAttributeValue();'.
>
> So instead of constructing the html page in a top down manner it would
> be constructed in a outside in manner. (do you follow?).


Yep, I follow.  One of my design goals which that's in conflict with  
that is to make it at least theoretically possible to stream the HTTP  
response rather than buffering it - to save memory, increase  
performance, and shorten the perceived load time of large pages.  I  
say "theoretically" because so far I haven't done the necessary work  
on Comanche to make this actually work end to end, but I want to at  
least keep the Seaside end of things satisfying this constraint.

It may be that we're sacrificing too much for that goal, especially  
given that we don't get any concrete benefits from it yet - opinions  
are welcomed.

Avi


More information about the Seaside mailing list