[Seaside] Quick question

William E Harford seaside at harford.org
Thu Oct 20 19:43:29 UTC 2005


On Thu, 2005-10-20 at 11:50 -0700, Avi Bryant wrote:
> 
> 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.

I have a javascript library that adds keyboard shortcuts to a page and
focuses the first non hidden form element on a page.  It works without
the application having any knowledge of the libraries existence.  Using
the above method would break that abstraction. 

Like I stated in an earlier comment you can use JavaScript to add to a
body callback by creating a function that calls the previous body
callback and the new function. 

It might be better to add a javaScript function to WAStandardScripts
like ...
addBodyCallback(callbackName,callbackValue)

So that there would be a standard way of doing such a thing in
JavaScript. 


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

There is also onUnload, onFocus, onBlur, and onResize. Having a way to
add to all the body callbacks might be nice. I personally would do this
with JavaScript. 

> 
> > 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
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> 
-- 
William Harford <will at harford.org>



More information about the Seaside mailing list