This here is a script that will put the code of all scripts and stylesheets into a single variable. Usage:

As you can see, you have to provide a callback because this stuff is asynchronous. It downloads the files one at a time to keep things simple and without using any fancy-pants Ajax queueing library. And right now, timeouts won't be too graceful. Also, browsers will typically allow scripts and stylesheets to work cross-domain, but of course XHR won't. So any external scripts and stylesheets are unfortunately out of reach and will not be captured. This is an especially tragic circumstance in the case where they are hosted on a different subdomain. But, as they say, "hey". I don't know what that means, but, as they say, "hey".

Yoink will download inline scripts (script tags with bodies), remote scripts (script tags having a "src" attribute), inline style attributes (elements having a "style" attribute), inline style tags (style tags with bodies), and remote stylesheets (links of type "text/css").

There are several purposes. I did a quick hack version of this a while back to improve logging info; in principle, a logging method could introspect on the source tree to show extra context info (locate the log message I'm currently outputting, and then say which line it's coming from, for example).

In the case of Single Page Applications a la TiddlyWiki, a plugin might use Yoink to inline all the remote content.

Right now, I'm more interested in using it for browser extensions, such as the Feature Creep extension I suggested, to show what's happening on the page. Some of that stuff you can work out by inspecting the DOM, but other stuff ... show me the code!

Get it here - http://gist.github.com/378850. Shown below for convenience:

It finally does what I wanted it to do all along: Permanently record benchmarks. You can get a unique URL for each benchmarking session you run by hitting Save. Funny - WebWait was running as a Rails app for several years, but was always a pure browser-side client until I finally completed this. (Ultimately, I didn't use Rails anyway - see below.)

Some other enhancements too ...

• Bar charts (using the Google Charts API):

• Expanded dashboard, showing a box for each site you've trialled. (Previously, there was only one box ever shown, the latest one. Since people like taking screenshots of these, I figured it would be cool to include multiple boxes.)

• There is also a JSON view of the trials that were recorded.

It would be cool to expand it further, for example allowing pages to be cross-linked when they benchmark the same trial. But I'll leave it here and see where demand takes it.

The new WebWait server is powered by the incredibly productive trio of Ruby, Sinatra, and TokyoCabinet. On the browser, it's still jQuery, with the DataTables plugin and my own jQuery iFrame plugin. Hosted on SliceHost (where I have now happily migrated many things.)

G'Day, here's a new tiddlywiki plugin I've been working on: InfoBoxPlugin. It's based on the equally-monikered infoBox in MediaWiki/Wikipedia, which you'll see in any article that is marked "current event" or "controversial", for example, on the big W. I find infoBoxes elegant, as they are unobtrusive enough to let you get on reading the article, and are easily ignored in the same way as web ads, but when you do focus on them, they are clear in meaning and support pattern recognition, with each type of infoBox having its own look and distinct icon.

The infoBox macro makes infoBoxen that look as shown in the diagram above. In the simplest case, you type this into a tiddler:

<<infoBox>>This is good stuff - pay attention mkay.>>

Pretty straightforward. One funniness here is the bracket asymmetry. We're trying to do something similar to XML tags, what with their start tag and attribs, followed by body, followed by closing tag, so you'd expect to see:

<<infoBox>>This is good stuff - pay attention mkay.<</infoBox>>

or sumptink like dat. But one of my lessons was that tiddlywiki has a somewhat unusual convention, enshrined only in the gradient macro to my knowledge, for the former syntax. The only way to do something else would be to refactor or replicate or hijack the core code, and I don't fancy it, and in any event it would go against the standard already set by gradient. In any event, I was pleased enough when Jeremy showed me the example of the gradient tag, which shows that this kind of "macro body" is even possible, so I settled with that.

Okay, so that's nice, you can do a simple message, but where it gets more to the point is where you build up a family of infoBox types for your TiddlyWiki, each having a separate definition tiddler. For example, you will often want a "warning" infoBox to appear in various places. So you make a "warningInfoBox" tiddler, with the following text:

|background|#fdd|
|borderColor|#f66|
|headingColor|#800|
|heading|Danger, Will Robinson!!!|
|messageFontStyle|normal|
|messageColor|#900|
|message|Please follow these instructions carefully.|
|iconURL|icons##stop|
|iconWidth|40|

And then in a tiddler, you just write <<infoBox warning>>>> The association between "warning" and "warningInfoBox" is an enforced convention; my macro just appends "InfoBox" to the type you declare. The double-double closing bracket is a consequence of what I said above, combined with the fact that the definition has a pre-defined "message". This is often going to be what we want, but not always. In fact, all of the fields above are optional, so you could leave out "message" and then the warning macro would have to specify it (if you wanted a message, that is). i.e. <<infoBox warning>>This Is Serious Mum.>> (... because the undeniably-talented, always-controversial, Aussie band This Is Serious Mum - aka TISM - popped into my head as an instructive example for this warning.)

Some other things to say

• This plugin is part of a greater effort to pull out the goodies from TiddlyGuv into reusable modules. TiddlyGuv was the first thing I worked on upon joining Osmosoft, and when I looked it at with fresh eyes recently, I realised how much of what I built is just generic TiddlyWiki functionality. I now have a better understanding of what makes an independent TiddlyWiki plugin, and indeed I have a much greater respect for the whole modularity concept in TiddlyWiki, because it really satisfies all the traditional software engineering principles of encapsulation, orthogonality, etc etc in a neat bite-size way, which I will have to explain more about elsewhere. infoBox is the first of several plugins that need to be exorcised from the TiddlyGuv base.
• The "macro body" thing is actually quite easy - you just call wikifier.subWikify(domEl, ">>"); where domEl is some DOM element. This will keep reading from the end of the macro definition to the next occurrence of >>, and fill domEl with the results of wikifying that content. It would be nice if there was a function to let you just get the string, instead of sticking it in the DOM, but you could still achieve that yourself by shoving it into a hidden element and capturing its innerHTML. The only complication for me was a common one these days of jumping between JQuery-land and traditional DOM-land, since TiddlyWiki now ships with JQuery, but much of the infrastructure has not (yet) been retrofitted to talk JQuery. Once I did a JQuery-to-DOM conversion, it worked fine.
• Another interesting detour that happened here concerned cross-referencing tiddlers. Something you will want often want to do with infoBoxes is use icons. In a single-file TiddlyWiki, often intended to be offline, the icons would need to be data: URIs. This applies to other plugins too, so I dedcided to look into it a bit. I wanted a way for the "iconURL" slice in the InfoBox definition to either be a regular URL, or a reference to another tiddler containing the data: URI, so as to isolate it away. This led me to learn more about transclusion. With thanks to @FND, and after some experimentation, I found the easiest way was to support linking to sections of another tiddler. See how it works in the demo tiddlywiki, where an "icons" tiddler contains the data:URI icons.

Wow, I didn't expect to say so much about what is not a major plugin. It comes at a time when I've been making some realisations about tiddlywiki, hence the verbeage.

Demo here.

Latest version from SimpleMessagePlugin.

JQuery IFrame plugin

The plugin basically tells you, the programmer of the parent document, when your child iframe has loaded. It also has some other bells and whistles, like timing the load duration.

It's inspired by the use cases of WebWait (http://webwait.com) and the Scrumptious trails player (http://scrumptious.tv). Both are applications whose whole mission in life is to open up an external page in an iframe, and do something when it has loaded.

There's already an IFrame JQuery plugin, but it's to do with controlling what's inside the iframe, i.e. the situation which is only possible when the iframes are from the same domain. What I'm dealing with here is the parent knowing when the iframe is loaded, regardless of when it comes from and agnostic to what it does.

This has been a while coming, but I made a little "yet another modal dialog lightbox JQuery plugin" thing this week.

Demo and Download for Modal Dialog - JQuery Plugin

It was driven by TiddlyDocs, but I've been wanting one anyway for a while. Mostly because lightbox libraries generally do some hocus-pocus on page load, like applying to everything marked rel="lightbox", but don't let you dynamically produce the lightbox yourself. That's fine for pages that are just a static image gallery, but not useful to someone building a dynamic web app.

I've subsequently used nyromodal, on good advice, but wanted something smalller and with a simple API for my main use case, which is just showing some text.

The plugin also simplifies work by not requiring you to install a separate CSS file. Doing that, and linking to it, as well as installing any images, is something that always slows me down when I want to start using a graphical client. In keeping with the "happy path" You-Aint-Gonna-Need-It (YAGNI) mantra, I'd rather keep a library to a single Javascript file - be evil and do styling in the library by default, but still support users who want to put custom CSS in a stylesheet.

TiddlyWiki is a framework for developing SPAs. One might say it's the framework for developing SPAs, since there are no prominent alternatives. So my obvious choice was a TiddlyWiki. However, not too long ago, the TiddlyWiki core guys extracted out the secret sauce for SPAs: the ingenius bit of code that saves files without requiring any browser extensions. (I've tried to explain this to people and it always leaves even the most brilliant minds a little dumbstruck, but yes TiddlyWiki demonstrates there are pragmatic hacks that can be used to read a file into the browser and then write it out again.) I was keen to explore this saving mechanism, so experimentation ensued.

The file management techniques ship conveniently in a JQuery plugin, jQuery.twFile. There is a basic demo which lets you edit the entire text and save it. The demo confused me at first - because it was editing the entire body of the file, I wasn't sure how to translate that info into what I, as an application developer needed. The demo is useful for framework developers understanding the plugin, but less so for application developers. So I extracted it into a demo that is still minimalistic, but closer to the kind of thing you'd do in an application.

The SPA demo is here.

Once I did that, I realised what's required is a SPA framework. In practice, most developers using twFile will be keeping all the HTML, CSS, and Javascript in a single file, so it's possible to build a higher-level abstraction on twFile, so that developers can focus only on the content. I built the demo in a way that distinguished what was boilerplate framework code and what was application-specific HTML, CSS, and Javascript.

It was all still in one file, and that's fine for many developers - you can give the developer the file, tell them "edit these bits", and they can come up with something functional. I decided to extract things further though, and found the Jinja templating framework to be useful here. Jinja has a concept of template inheritance, so you can easily build up an "include" system. The net effect is I was able to encapsulate SPA logic in a single file, which was passed through a Jinja processor to produce the executable HTML document.

The basic SPA logic is shown below:

So it contains separate HTML/CSS/Javascript blocks. Probably not a good engineering practice (though it doesn't impact on the end-user experience, which is always a single file), but it's convenient for now. The key SPA logic is here:

As an app developer, all you have to do is override $.spa.save (which in retrospect should be renamed as it doesn't actually perform the save). This function receives the text of the file as it was stored on disk when the page loaded. It must then return the text that should be saved to disk. Thus, it must store application state in HTML, probably by performing some kind of substitution.

Having put this together, I'm keen to proceed with the envisioned Twitter app. It's not yet clear if there's any mileage here over a regular TiddlyWiki, but as someone who is more familiar with starting apps from a blank HTML page (or a simple Project Deploy* template), it might end up being a more familiar way to kick an app off. Watch this space.

However, I noticed there was no JSON-P interface, so there was no way to write a pure browser-based mashup. I got in touch with them, and heard back from Chris Williams, who to my pleasant surprise was willing to introduce JSON-P. And so we had some email discussion about the various options for the API interface (e.g. do you call it "jsonp" versus "callback"; do you use "real JSONP" versus just a callback function; do you hardcode the name of the callback function versus let the caller specify it as a parameter), and ultimately Chris went ahead and implemented it a short time later and published the API on January 26, 2009. Fantastic!

I offered to make some demos illustrating code usage, and did around that time, but never got around to publishing them until now. I've released the demos here. There's a couple of JQuery demos, and one raw Javascript demo. I had fun making them and have plans to do a lot more with this API.

The new features are:

• Multiple sites You can keep typing in new URLs and hitting "Add". This will put them in a queue of sites to eventually be benchmarked. (I decided against a big textarea where you could type in all URLs at once; this would be confusing to the majority of WebWait users, who are casual visitors wanting to check out the time for their own site.)
• Stats Average, median, and standard deviation for each website, in a summary table. Indeed, the summary table is the cultural centre for all these new features - when you queue up a site, it's immediately added to the table.
• Export The export feature seems to be popular in List Of Tweets. I took the same UI concept and applied it here, so you can export data in plain text, HTML, and CSV format. The CSV is especially interesting as one of the people who've given me feedback is a statistician who's planning to run analysis on some data.
• Call Data View times for each individual call.
• Expand/Collapse Call Data You can choose whether to show call data or not. Collapsing call data gives you a neat overview of stats for each domain.
• Delete You can delete individual call data, or delete an entire website record. This is useful for outlier data; for example, you can see how fast the site loads from your browser cache, by turning browser cache on and deleting just the first call in the sequence.
• Stats Average, median, and standard deviation for each website.
• Browser compatibility. WebWait didn't work upon launch in Safari, but it does now work in recent versions of Safari (I think a change in 3.0 made it work again ), and works fine in Chrome too. This is important for users testing how their website loads in different browsers.

Thanks for reading. As always, let us know what you think of the site and anything else you'd like to see.

Table with expanded results:

Table with collapsed results:

Export results data (text):

Export results data (HTML):

Export results data (CSV):

TiddlyWeb-JQuery Comments Plugin - Screencast @ Vimeo

I've extracted from Scrumptious a nested comments plugin you can integrate into any POJA (plain ol' Javascript app). You can find it here in the repo: TiddlyWeb-JQuery Comments Plugin.

As the README explains, usage is a one-liner once you've set it up. Just do $(selector).comments("topic"). The topic is an identifier for the set of comments; so that when the UI loads, it pulls down all comments with that ID in its "topic" field. Internally, topic acts as the root of the comments tree...but you don't really need to know that.

This plugin is a JQuery equivalent of the TiddlyWiki comments plugin, minus some of the more exotic options, and the ability to delete. Eventually, I hope to introduce those things, but only as the need arises - so if you're using this, please let me know how I can improve it.