Here's a quick lil' addon for Prototype that I use often.

Prototype.Promise(condition, action, interval)
condition is a string that you want met before an action is run.
action is a function that does the action.
interval is the polling rate for condition in seconds, and defaults to 1

So, for example, you may want function foo to run, but only once bar has been set:

function foo(a,b) {
this.retVal=a+b;
}
var thingy = {
retVal:0
};
Prototype.Promise(
'thingy.retVal=5',
foo.bind(thingy,5,10),
5
);


Then, in some point in the mysterious future, thingy.retVal gets set to 5, at which point, the Promise goes into effect, and thingy.retVal becomes 10.

Where I find this particularly useful is in making sure that a document is loaded before doing something (condition="$$('body').length>=1), as you can see it used for the include functions.

Speaking of which, the following include functions are great for getting scripts and stylesheets into your page. I won't bother with examples, as they're pretty straightforward.

Meanwhile, Prototype.scriptPath will point to wherever in your server's heirarchy Prototype was loaded from. The regex, you'll note allows for names like prototype.compressed.js, prototype.modified.js, 2007-09-28.prototype.js, etc - just in case you want to keep track of your various hacks of Prototype, as I do.

This is a version of my previous entrant, Promise, that will work with prototype, but does not require it. It's slightly more advanced, using .apply here and there.

It's basically a function to allow any other function to poll. Polling is generally regarded as bad practice in object oriented code, but can make very simple the matter of, for example, running a bit of code only after a single-run event (like onload) occurs (whether that be in the future or past), another unrelated bit of code needs to be hack-tracked, or any other generic condition.

Note that when the function runs, it doesn't necessarily run within the scope that's called it. Its context is set to itself, rather than its normal context, and it's asynchronous, so you'll not get a return value. If you use Prototype, you can bind the function and it'll behave as it should in terms of context, but I'm unaware of a way to cause an asynch function to block execution - and you'd really rather that not happen anyway, trust me.

Ok, so I was getting frustrated with the inability to hide data in javascript, as well as a number of other concerns with existing class structures (the requirement to use this.constructor in lieu of self, for example).

As a result, I've thrown together a nice little class constructor that accepts a class definition, as well as a class extender that allows you to build a new class from an existing one, with full access to all that private stuff.

Ok, so here's the deal. I've started to dally with Flash a bit, and I'm feeling all naked without my nifty Prototype functionality.

Most important to me are the bind() and curry() functions (though, others will rear their heads as my AS code gets more complex), Object.extend, and $A. They are para-ported here.

Dead simple interface for structured SQLite access within XUL, using Mozilla's SQLite Storage API.

Forgive the formality here; this is one of my professional scripts.

Analyte 1.0 (c) 2008 Bryan Elliott
Purpose:
Simplify inclusion of Google Analytics into any site, add GA tracking to non-HTML links, and reduce 'blocking' action of Google Analytics scripts.

Use:


License:
Unlimited license granted to Abacus Studios, Inc. and I-Site, Inc.
All other parties licensed under CC-BY-SA-3.0:

Creative Commons Attribution / Share Alike 3.0 US
Fulltext and synopsis at
http://creativecommons.org/licenses/by-sa/3.0/us/

This license need not appear in minified or otherwise compressed forms
of this script, so long as the script is in active use by a web site or
application, and no other credit is claimed.

A simple function (with support) that can provide the backbone to any templating system.

My previous entry on an easy to use SQLite interface for XUL/JS got me thinking: how many times have I had to write functions that were just wrappers for a little SQL?

Below is the fruits of that little query (excuse the pun). Forgive the dbXXX functions; my implementation depended on a small portion of a larger mysql library that I've grown accustomed to coding with.

Best use of ob_, custom error handling, and variable variales evar: simple templating.

_parse($filename[,$locals])
includes $filename and renders its output to the return value. $locals, if used, will add a set of variables to the included context.

Parse($template[,$locals])
Same as above, but allows you to define a base template folder and omit the .php - just for cleaner code.

t($template[,$obj])
...
t()
Same as Parse, but any output between the opening call and the closing call (no arguments) will be buffered intot he $content variable of the template.

Play around with t(..) to find out more; I don't feel like documenting it.

This is a Tiny PHP Uploading script. It SHOULD be safe from both really large files and non-image files.