Script in head tag

Hi there,

In updateRoot: we don't have the canvas. Beside the script element which invokes
a file of a javascript library, how do I add a script with actual javascript
code there?

Sebastian
PD: not good idea for regular code but a good one for initialization code like
the one provided by google with:
google.load('prototype','1.6')
google.load('scriptaculous','1.8')
(see: http://code.google.com/apis/ajaxlibs)

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> In updateRoot: we don't have the canvas. Beside the script element which invokes
> a file of a javascript library, how do I add a script with actual javascript
> code there?

aHtmlRoot addScript: 'abc'

> PD: not good idea for regular code but a good one for initialization code like
> the one provided by google with:
> google.load('prototype','1.6')
> google.load('scriptaculous','1.8')
> (see: http://code.google.com/apis/ajaxlibs)

I would directly embed the URLs of the particular libraries. That's
much more efficient than having  Javascript being started to fetch the
files.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Can't you just use "self session addLoadScript:" from a render method?

Julian

On Wed, Oct 22, 2008 at 12:12 PM, Sebastian Sastre <[hidden email]> wrote: _______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

That will make UA to execute that code at the very last possible moment. I wont
just the contrary. This is intended to make things at DOM initialization time.
So you can even take some action before anything is displayed.

Sebastian Sastre

 

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > a file of a javascript library, how do I add a script with
> actual javascript
> > code there?
>
> aHtmlRoot addScript: 'abc'
>
Yup, that made it.
That’s what I was doing so far. Using google.load has the advantage of getting
the libraries with no requests when other site was visited by the user and has
requested those already (which will occur if that site also used google.load and
the very same version of the libraries of your app of course). You can bet that
is efficient.

Cheers, and thanks again,

Sebastian
PD: I've observed in #writeHeadOn: a grouped write (element, scripts and
stylesheets) which breaks order of what you ask root to render. I'm reviewing it
because strict order is crucial for using this.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> That's what I was doing so far. Using google.load has the advantage of getting
> the libraries with no requests when other site was visited by the user and has
> requested those already (which will occur if that site also used google.load and
> the very same version of the libraries of your app of course). You can bet that
> is efficient.

I can hardly believe that. First the Javascript VM is loading the
Google Library. Then you call that library to load other libraries.
This patches the DOM and adds references to these other libraries that
are then loaded. If you had put these other libraries in the head from
the beginning, the browser would have started to load them
immediately. Maybe I am misunderstanding something?

> PD: I've observed in #writeHeadOn: a grouped write (element, scripts and
> stylesheets) which breaks order of what you ask root to render. I'm reviewing it
> because strict order is crucial for using this.

#addScript: and #addStyle: are actually ment for internal use. It is
currently used by the methods WAComponent>>#styles and
WAComponent>>#scripts. The order is well thought (see the discussions
a few years ago in the mailing list).

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I can hardly believe that. First the Javascript VM is loading the
> Google Library. Then you call that library to load other libraries.
> This patches the DOM and adds references to these other libraries that
> are then loaded. If you had put these other libraries in the head from
> the beginning, the browser would have started to load them
> immediately. Maybe I am misunderstanding something?
>
No need to, you can feel it and see. Idea behind that is to favour consumers by
taking advantage of others sites loading same library as yours. So that cache
hit is statistically favoured by the library popularity. When that happen UA
will not make a request at all. The request time is much greater than a cached
load library time so that’s all that really matters.
That said, also there is the value of making easier version load and saving you
from the need to maintain that cacheable content in your server.
I saw the code is made like that to take advantage of one style per component.
But, as recently asked and Phillipe said, that is a convenient hack which is
actually useful but not really intended for production. As I don’t use #style in
my app's components, I find that convenience actually inconvenient.

Cheers

Sebastian

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Some clarification about this:
In the end applicability will say if this convenient or not.
One has to be aware this tends to favour sites more than rich apps.
For rich apps, like the ones we make with Seaside :), you may well decide to
maky user pay for the more likely to happen requests in favor of faster response
times a posteriori.

Cheers,

Sebastian

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 23-Oct-08, at 2:30 AM, Sebastian Sastre wrote:

> That’s what I was doing so far. Using google.load has the advantage  
> of getting
> the libraries with no requests when other site was visited by the  
> user and has
> requested those already (which will occur if that site also used  
> google.load and
> the very same version of the libraries of your app of course). You  
> can bet that
> is efficient.

Loading the libraries from Google improves the cachability of the  
javascript - as you say, if other web pages load the library from  
Google, it may already be in the cache, and we can avoid a network  
request to fetch it. But it true regardless of whether you put tags  
directly into the head or use google.load().

The value of google.load() is that you can load the libraries  
dynamically, based on information only available on the client, or in  
response to a user action. If you don't need that capability, it's  
better to just put tags in the head, as Lukas suggested.

Colin_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

The load() will be good for dynamic load and also for more briefly visits kind
of site. But less valuable for rich application where user will be willing to
wait a little more once at the beginning (say while subscribing a service) and
all request after that one are cache hits.

So.. I've returned to host libraries myself. I've configured apache to expire
some decades ahead for that version. I don't know why but seems like Google ones
expires in the same day so loading those from their url also went inconvenient.

Cheers,

Sebastian

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside