Thanks for all your advices T.J.! I read some snippets of the Proto-
Scripty wiki and my dynamic script loading was in the right way.

> It doesn't process them if you assign them as strings via innerHTML,
> which is what your modified update would do (Element#update uses
> innerHTML behind the scenes).  It does process them correctly if you
> insert them using DOM methods as your code does, even if you don't put
> them in the head.
Hm, actually I'm already using Prototype 1.6.1 RC2 (by the way, thanks
for this IE8 special release) and it seems that Element#update has
been completely reworked but still uses the innerHTML approach. I'm I

> Ah, interesting approach.  I think I'd prefer to leave Prototype
> unmodified and build my own updater-like-thing via Ajax.Request, but
> obviously it's up to you.
Don't worry, the registration of the Ajax.Responders callback is not
done in prototype.js but in a specific initialization script! ;)
Actually, all our asynchronous updates are already delegating to
Ajax.Request because validation and exception messages thrown by the
usecase workflow do not produce failed requests but are instead
redirected to some specific forward page, which will allow to capture
these kind of errors:

Ajax.Request.prototype.error = false;

        onComplete: function(responder) {
                // Ensure that external scripts are successfully loaded:
                var reponseText = responder.transport.responseText;

/* This should be part of Prototype Ajax core... ;) */
Object.extend(Ajax.Updater, {
        callbacks : [],

        register : function(callback){

Object.extend(Ajax, {
        update: function(element, url, options){
                element = $(element);
                options = Ajax._checkOptions(options);
                options.onComplete = options.onComplete.wrap(function(original,
                        // Apply update callbacks:

                // Delegate:
                return Ajax.request(url, options);

        request : function(url, options){
                options = Ajax._checkOptions(options);
                options.onComplete = options.onComplete.wrap(function(original,
                        // Check for worflow errors (note that response has 
already been
                        if (transport.request.error){
                        } else {

                // Delegate:
                return new Ajax.Request(url, options);


Don't hesitate to 'pimp' my code, if you detect some conflict. Hope
this may be usefull for anyone using the Struts forward engine.

> Very likely.  The inline scripts will get evaluated very, very soon
> after the content is updated (Element#update does it via Function#defer
> [1]), whereas the external scripts may still be downloading at that
> point.  A really robust solution would probably walk through the
> script tags (inline and external) in the order in which they appear
> and load/execute them sequentially...
You're right. Currently, I'm using events to notify observers that
script successfully loaded but your idea about scanning and executing
all script tags may be implemented when I'll get some time to spend on
JS optimization.

Thanks a lot!
You received this message because you are subscribed to the Google Groups 
"Prototype &" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to