[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