1. Yes, that's fine.  $$() will return an empty array if nothing
matches, and so each() won't have anything to iterate over, and the
whole thing becomes a no-op.

2. Code organization is probably something that's highly specific to
each application. :-)  But answering your specific question, sure,
there's no reason you can't put all of your code in one JavaScript
file and have that same file used for all of the pages.  Just make
sure that the right code is used for each page (ideally by using
functional tests -- like your #1 above, which sets up the ULs if they
exist and does nothing if they don't -- rather than checking the page
name or something).  Although the first time a user hits any of the
four pages they may end up downloading a bit of code they won't use on
that page, if they go to the next page it'll already be cached for
them (presumably, you need to make sure your scripts are cacheable).
Unless we're talking about a *lot* of code that page doesn't use, the
overhead should be negligible.  That said, though, there's not
necessarily anything wrong with having a common file and then a file
specific to each page, except for the fact that that give the browser
One More Thing to download.  Remember that typically, the browser or
the server -- or both -- will only allow two active connections
between the browser and the server at once, so if you have three
things for the browser to download (for example, the HTML file, the
CSS file, and the JavaScript file), one of those three will get queued
until one of the first two completes.  The more files you throw into
the mix, the more queuing, the worse your perceived load time.  Making
sure files are cacheable -- without requiring the browser to send an
"if-modified-since" GET -- is also HUGELY important.  There's a tip[1]
on the unofficial wiki that talks about various ways of improving your
perceived load time, with links to a useful blog post by the folks
over at Google Code about how they improved the performance of their
site, instructions for using Prototype & script.aculo.us from the
Google CDN (if you like) rather than hosting them on your own server,

[1] http://proto-scripty.wikidot.com/prototype:tip-minimizing-download-times

T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available

On Mar 25, 2:22 am, Doug Reeder <reeder...@gmail.com> wrote:
> I'm writing an app with three or four views, which are implemented as  
> separate HTML pages.  Any of the pages might be the first one loaded.  
> Some code needs to be executed regardless of which page loads first,  
> and some code is specific to each of the pages.   Currently, I have  
> code strewn around in a messy fashion, with things like
> document.observe("dom:loaded", function() {
>      preloadTreeImages();
>      $$('ul.treeroot li').each( function(elem) {
>          toggleListItem(elem, true);
>      });
>      $$('ul.treeroot').each( function(elem) {
>          elem.observe('click', respondToClick);
>          elem.observe('textInput', respondToTextInput);
>      });
> });
> In particular, I am calling document.observe("dom:loaded", function()  
> {...}); from a common.js file which is included in each page, and also  
> from a .js file specific to each page, which is legal, but  
> undisciplined.
> 1) is it legal to make calls like
>      $$('ul.treeroot').each( function(elem) {
>          elem.observe('click', respondToClick);
>          elem.observe('textInput', respondToTextInput);
>      });
> when there might not be any UL elements of class "treeroot"?
> 2) How should I be organizing code for an app like this?  Can I put  
> everything in one .js file and put a <script> tag which references it  
> in each html page?
> (I'm thinking these questions aren't as clear as they could be, but I  
> can't think how to ask them better right now.)
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to