Rails spinoffs - Dec 2006 - Scriptaculous loader ... how to clone it?

Hi,

I would like to use the system loader as in scriptaculous.js to load
dynamicly some of my javascript files.

So I copied and pasted the code from scriptaculous.js into my
modules.js (this file should load all my js files from the directory
"modules" !). But the problem is when I launch my web page, the
scriptaculous.js works correctly but not the modules.js.
I think the two methods load, in each files, conflict when the page
starts... Am I wrong?

I tried ton trace each load function by adding some alert() in the
codes, in the require method, and surprise ... it works! When I delete
these alert() ... nothing happens anymore!

So anyone doesn''t have a solution for me or a tip or something else?

Thanks in advance.
Dams

Below, you can see the code:

// based on scriptaculous method to import javascript librairies !!!
var Modules = {
  require: function(libraryName) {
    // inserting via DOM fails in Safari 2.0, so brute force approach
    document.write(''<script type="text/javascript"
src="''+libraryName+''"></script>'');
  },
  load: function() {

    if((typeof Prototype == ''undefined'') || (typeof Element
=''undefined'') || (typeof
Element.Methods==''undefined'') ||
parseFloat(Prototype.Version.split(".")[0] + "." +
Prototype.Version.split(".")[1]) < 1.5)
       throw("modulous requires the Prototype JavaScript framework
>1.5.0");

    $A(document.getElementsByTagName("SCRIPT")).findAll( function(s) {
      //alert(s.src);
      return (s.src && s.src.match(/modules\.js(\?.*)?$/));
    }).each( function(s) {
      var path = s.src.replace(/modules\.js(\?.*)?$/,'''');
      var includes = s.src.match(/\?.*load=([a-z,]*)/);
      //alert(path);

      //(includes ? includes[1] :
''clist,faq,permissions,persons,previews,services'').split('','').each(

(''clist,faq,permissions,persons,previews,services'').split('','').each(
       function(include) {
       		// alert(''including
''+include+''.js'');
       		Modules.require(path+include+''.js'') });
    });
  }
}

Modules.load();


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12/12/06, pancheri.damien-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<pancheri.damien-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Hi,
>
> I would like to use the system loader as in scriptaculous.js to load
> dynamicly some of my javascript files.
>
> So I copied and pasted the code from scriptaculous.js into my
> modules.js (this file should load all my js files from the directory
> "modules" !). But the problem is when I launch my web page, the
> scriptaculous.js works correctly but not the modules.js.
> I think the two methods load, in each files, conflict when the page
> starts... Am I wrong?
>
There is a very recent thread that describes the problems with
scriptaculous.js that you might find helpful.

<http://groups.google.com/group/rubyonrails-spinoffs/browse_frm/thread/00df2729c2ec3ff4/c7b2819631657ef4#c7b2819631657ef4>

It really is too bad so many people are getting burned by this script.

Peter
-------
http://forkjavascript.org

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Hey there,
Peter Michaux a écrit :
> It really is too bad so many people are getting burned by this
> script.
I just can''t believe you, Peter.  "So many"? 
"Burned"?  We''ve had
barely a couple people announcing they have issues when using the loader
in very specific situations, compared to thousands, if not tens of
thousands, who use it everyday without a glinch, and you go "so many"?
Man, you''ve been told, and told again, that while we value your answers
whenever they are constructive, and put your technical expertise to the
benefit of the readers, it is just horrendously bad form to come here
just in order to say such stuff as "script.aculo.us burns,"
"Prototype
is poorly designed," or "Prototype''s API is cryptic."
I mean, you created a fork, you''re working on your own, and honestly, I
wish you God speed with it!  Competition is always good, as are
diversity and innovation.
But we who know and love Prototype and script.aculo.us won''t come to
*your* ML and endlessly bash your lib!  Can''t you SEE how bad this
looks?
Prototype and script.aculo.us ain''t perfect.  They''re
certainly not
fitting the needs of everyone, and they certainly have design decisions
that raise issues here and there, making tech compromises or proceeding
from an overarching sense of code aesthetics you obviously don''t agree
with.  Jesus, Peter, FINE!  So does RoR, and the simple truth is:
there''s no point in trying to be everything to everybody.  Do that, and
you end up being XHTML2, WS-*, EJB2.1, SOAP...  You end up with a tech
so bloated its name alone is a trade joke.
There are products that are better suited for every particular project.
 I''ll bet your Fork is better suited here and there.  I''ll
also bet I''ll
be perfectly fine with Prototype and script.aculo.us most of the time.
I don''t even have to guess: they''ve been a breeze on quite a
few
projects of mine so far.
But for crying out loud, can''t you grasp that you don''t just
come on a
product-specific ML and trash the product?  Especially in FLOSS?  In a
world of contribution, your contribution for the past weeks has turned
from "yeah, I know it''s a toughie, here''s how you can get
this lib to do
what you need" to "These libs suck, use mine!"
There''s constructive criticism, and then there''s bashing.  You
crossed
the line a while back, and I''m sorry you did.  While this ML has a
rather very good mood usually, being nicer than most on newbies (a
strong point, as Kathy Sierra would remind anyone), your voice (and
quite a few others) are now raising an awkward echo.
I understand how working on a lib with an entirely different
architecture and design can make it tough for you to still be in a
mindset to contribute in-lib solutions on this ML, but if the mental
exercise it requires it too hard, just let go, Peter!  Focus 100% on
Fork, and leave us in peace, with the solution we love so far!  Check in
now and then to announce your new releases, so we might check it out,
but don''t wrap up your posts with "It''s about time you
morons realize
what''s good for you," alright?
I''ve been mostly quiet throughout the rants and trolls, but this is the
last drop in the bucket.  I''m abashed at the way you go about this.
Just to look at your blog entry about announcing Fork makes me sick.
It''s so blunt, so gratuituous.  The phraseology reminds me so much of
1984, you wouldn''t believe.
Since when "you guys suck, I''m so much better than you"
became a valid
opening line for cooperation, giving or asking for help?
-- 
Christophe Porteneuve a.k.a. TDD
"[They] did not know it was impossible, so they did it." --Mark Twain
Email: tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Peter,

I tried your solution ... and it doesn''t work ...
I tried to modify it:

var Modules = {
	require: function(libraryName) {
	        document.write(''<script type="text/javascript"
src="''+libraryName+''"></script>'');
  	},
  	reload: function() {

		var scriptTags = document.getElementsByTagName("SCRIPT");
		var scriptaculous, modules = false;


		if((typeof Prototype==''undefined'') ||
       		(typeof Element == ''undefined'') ||
       		(typeof Element.Methods==''undefined'') ||
       		parseFloat(Prototype.Version.split(".")[0] + "." +
Prototype.Version.split(".")[1]) < 1.5)
       		throw("script.aculo.us requires the Prototype JavaScript
framework >= 1.5.0");


		for(var i=0;i<scriptTags.length;i++) {

		  	if(scriptTags[i].src &&
		  		(scriptTags[i].src.match(/modules\.js(\?.*)?$/) ||
		  		 scriptTags[i].src.match(/scriptaculous\.js(\?.*)?$/))) {

				if (scriptTags[i].src.match(/modules\.js(\?.*)?$/)) {
					var path1 =
scriptTags[i].src.replace(/modules\.js(\?.*)?$/,'''');
		  		}
				if (scriptTags[i].src.match(/scriptaculous\.js(\?.*)?$/)) {
					var path2
scriptTags[i].src.replace(/scriptaculous\.js(\?.*)?$/,'''');
		  		}


				if (path1 && !modules) {
				
(''clist,faq,permissions,persons,previews,services'').split('','').each(
			       		function(include) {
Modules.require(path1+include+''.js'');
});
			       	modules = !modules;
				}
				if (path2 && !scriptaculous) {
			    
(''builder,effects,dragdrop,controls,slider'').split('','').each(
			       		function(include) {
Modules.require(path2+include+''.js'')
});
			       	scriptaculous = !scriptaculous;
				}

			}
		}
  	}
}

Modules.reload();

I commented the ''Scriptaculous.load();'' in the
scriptaculous.js file to
avoid a pre-loading of the scriptaculous libraries.
My code doesn''t permitt to load independently custom libraries, you
have to write the appropriate code in the reload method ...

Thanks for your ideas.


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

FOn 12/13/06, pancheri.damien-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<pancheri.damien-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Peter,
>
> I tried your solution ... and it doesn''t work ...
This example works for me in Firefox 1.5, Firefox 2, Safari 2, Opera 9 and IE6

<http://peter.michaux.ca/temp/loader/page.html>

It looks like there is a new loader script in the works that uses the
same DOM decent idea

<http://groups.google.com/group/rubyonrails-spinoffs/msg/1a11381f8f5ea543>

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Peter Michaux wrote:
> FOn 12/13/06, pancheri.damien-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<pancheri.damien-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > Peter,
> >
> > I tried your solution ... and it doesn''t work ...
>
> This example works for me in Firefox 1.5, Firefox 2, Safari 2, Opera 9 and
IE6
>
> <http://peter.michaux.ca/temp/loader/page.html>
>
> It looks like there is a new loader script in the works that uses the
> same DOM decent idea
getElementsByTagName only fails in the above scenario if a second load
script is used with a different path to the first one (hence you need
an updated path) *and* it is in the head element.  Below is a load
script that works fine as long as the second and subsequent loads are
done from the body.  It can easily be extended to include more
features, I just wanted to show you can avoid a recursive node walk
(which must grate on anyone looking for a clean design).

For convenience, it''s probably best to put all the load scripts in the
body if this method is used.

If you use DOM methods to add the scripts, there is no issue at all
with either multiple calls to getElementsByTagName or just using the
(live) collection returned by the first call.  I understand
document.write() is used because old versions of Safari don''t properly
add scripts via DOM - I''m not sure that''s an issue with
scriptaculous
since large slabs of it don''t work in Safari 1.x anyway.

It seems Firefox doesn''t update the DOM for elements written to the
head using document.write() until after the head is closed, but it
seems to update the body as it goes - more testing is required, I
focused on Firefox 2.0 and checked in IE 6.

var loadJS = (function()
{
  var gotScripts, path, scriptList;
  var lastScript = function(){
    return gotScripts[gotScripts.length-1];
  }

  return {
    load : function(obj)
    {
      scriptList = obj || [];
      gotScripts = document.getElementsByTagName(''script'');
      path = lastScript().src.replace(/[^\/]+\.js.*$/,'''');

      for (var i=0, len=scriptList.length; i<len; i++){
        document.write(''<script type="text/javascript"
src="''
          + path + ''/'' + scriptList[i]
          + ''"><\/script>'');
      }
    }
  }
})();


Load scripts consist of:

loadJS.load( [
    ''foo.js'',
    ''bar.js''
  ]);


HTML looks like:

 <head>
  <title>Project</title>
  <script type="text/javascript">
   document.write(''<script type="text/javascript"
src="x.js"><\/script>'');
  </script>
  <script type="text/javascript"
src="scripts/load.js"></script>
  <script type="text/javascript"
src="scripts1/load1.js"></script>
 </head>
 <body>
  <script type="text/javascript"
src="scripts2/load2.js"></script>
  <script type="text/javascript"
src="scripts3/load3.js"></script>
  ...
 </body>


-- 
Fred


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12/13/06, Fred <ozfred-AFFH1GffN5hPR4JQBCEnsQ@public.gmane.org>
wrote:
>
> getElementsByTagName only fails in the above scenario if a second load
> script is used with a different path to the first one (hence you need
> an updated path) *and* it is in the head element.  Below is a load
> script that works fine as long as the second and subsequent loads are
> done from the body.  It can easily be extended to include more
> features, I just wanted to show you can avoid a recursive node walk
> (which must grate on anyone looking for a clean design).
The recursive descent is only document->head->head elements. It is not
a complex deep walk with long descents into fruitless branches. It is
almost a direct hit especially if you put the loader script inclusion
high in the head element.

There are situations where you can''t move scripts from the head to
body elements just willy-nilly

<http://www.w3schools.com/js/js_whereto.asp>

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Peter Michaux wrote:
> On 12/13/06, Fred <ozfred-AFFH1GffN5hPR4JQBCEnsQ@public.gmane.org>
wrote:
> >
> > getElementsByTagName only fails in the above scenario if a second load
> > script is used with a different path to the first one (hence you need
> > an updated path) *and* it is in the head element.  Below is a load
> > script that works fine as long as the second and subsequent loads are
> > done from the body.  It can easily be extended to include more
> > features, I just wanted to show you can avoid a recursive node walk
> > (which must grate on anyone looking for a clean design).
>
> The recursive descent is only document->head->head elements. It is
not
> a complex deep walk with long descents into fruitless branches. It is
> almost a direct hit especially if you put the loader script inclusion
> high in the head element.
My error, I assumed you''d used the same approach as that implemented in
the other thread which includes processing instructions for recursion
(although it should have occurred to me that since no element in the
head that can have childNodes it would never be called).

The only remaining issue is that you need to run down all the
(progressively more numerous) elements each time the load function is
called, which is probably not a concern as it should only be called a
couple of times at most.

Have you tested recursive loading? That is, calling a load script from
a load script?  Don''t roll your eyes like that, someone will try it!
;-D

I can also imagine someone trying to put functions into separate files,
then using a load script as a kind of include file.  They could end up
trying to load a very large number of files using a large number of
nested load scripts.  Devil''s advocate is a fun job.

> There are situations where you can''t move scripts from the head to
> body elements just willy-nilly
I can only think of cases where you might want elements to be parsed
after a particular script element, but those elements can only appear
in the head.  I imagine those cases are few and far between.
>
> <http://www.w3schools.com/js/js_whereto.asp>
Ugggh... my opinion of w3schools just slipped a couple more notches:

  "JavaScripts in the body section will be executed WHILE the page
loads.
   JavaScripts in the head section will be executed when CALLED."

Whoever wrote that needs to learn about execution contexts,
specifically global code and function code - Section 10.1.2 of the
ECMAScript specification refers.

Javascript will be executed according to the rules for parsing and
executing contained in the ECMAScript Language Specification, which is
essentially that global code is executed as it is encountered,
functions will be executed when called.  The very act of declaring a
function executes global code, wherever it is.

There are no processing or execution rules based on where in an HTML
document the script element (and hence the code) is physically located.
 The only side effects of that might be if a script element is not in
the head or body a browser might decide to ignore it or put it into the
head or body.  As far as I know, no browser will do the first, they all
do the second, even if the script element is placed before the DOCTYPE
or after the closing body tag (or between head and body tags, or
anywhere it shouldn''t be).


-- 
Fred


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12/13/06, Fred <ozfred-AFFH1GffN5hPR4JQBCEnsQ@public.gmane.org>
wrote:
>
> Peter Michaux wrote:
>
> The only remaining issue is that you need to run down all the
> (progressively more numerous) elements each time the load function is
> called, which is probably not a concern as it should only be called a
> couple of times at most.
I agree this is not the issue. If performance is an issue then a
loading script probably isn''t used since it requires an extra
client-server communication which will be slow even just to check if
the cached version is up to date.
> Have you tested recursive loading? That is, calling a load script from
> a load script?  Don''t roll your eyes like that, someone will try
it!
> ;-D
I hope people don''t do this but It just worked in IE6, FF2, S2 &
O9.

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Christophe Porteneuve wrote:
> Hey there,
>
> Peter Michaux a écrit :
> > It really is too bad so many people are getting burned by this
> > script.
>
> I just can''t believe you, Peter.  "So many"? 
"Burned"?
A little hyperbole goes a long way...
>  We''ve had
> barely a couple people announcing they have issues when using the loader
> in very specific situations, compared to thousands, if not tens of
> thousands,
You really think there are "tens of thousands" of users (i.e.
developers) who have tried multiple load scripts calling the
scriptaculous load function?  Hmmm, hoist with your own
petard.
> who use it everyday without a glinch, and you go "so many"?
Have a serious look at the scriptaculous loader function, it is a prime
example of turgid, confused programming.  It contains a blatant syntax
error (throw without try..catch), is fragile (as demonstrated here),
uses an amazing series of nested functions with iterators that are
completely unnecessary and and really shouldn''t be served as the
primary link in loading the other libraries.
It deserves criticism.
Peter''s alternative function does a much better job, why not submit it
with a Trac ticket?

-- 
Fred

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12/13/06, Fred <ozfred-AFFH1GffN5hPR4JQBCEnsQ@public.gmane.org> wrote:
> Have a serious look at the scriptaculous loader function, it is a prime
> example of turgid, confused programming.  It contains a blatant syntax
> error (throw without try..catch), is fragile (as demonstrated here),
> uses an amazing series of nested functions with iterators that are
> completely unnecessary and and really shouldn''t be served as the
> primary link in loading the other libraries.
>
> It deserves criticism.
>
> Peter''s alternative function does a much better job, why not
submit it
> with a Trac ticket?
I reopened the ticket and attached a new scriptaculous.js file. It
seems to work.

<http://dev.rubyonrails.org/ticket/4335>

Peter

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---