dw_dev | New JS implementation on Journals // jQuery Code Guidelines (Reply)

We just released a beta-test of the jQuery implementation on journals. You can turn it on by going to the Dreamwidth Beta page.

You can test even if you're not a dev-type, but please don't spread this link around too widely just yet. There's still a lot left unimplemented (most notably quick reply), and until the most widely-used user-facing bits are done, it's going to seem pretty broken.

(I'd rather not have random people who don't see the warning in this entry come away with the impression that we all just broke / are planning to break Dreamwidth).

When things are ready to go public, we will be setting up a public beta procedure, and post in the appropriate locations. For now, please if you go turn on beta, expect only comment moderation and deletion to work :)

You'll probably want to save the link so you can go turn it off at will.

For developers, I've put up on the wiki some instructions for putting future features in beta.

There's a lot of ways to set up code in jQuery; here are some things that have been working for me. Putting up for discussion; I'd like to start setting up guidelines to make it easier to get started quickly, soon.

All jQuery library files to go into dw-free/htdocs/js/jquery

Any third-party plugins to go into htdocs/js/jquery.$pluginname.js

All our own plugins named in this manner: htdocs/js/jquery.$pluginname.js

Use the jQuery widget factory whenever you need to keep track of state per-element. This is a simple framework which lets you have a single instance of the widget per element it's been applied to, which makes it much easier to keep track of state.

Understanding jQuery UI widgets: A tutorial is an really helpful tutorial. Tips for Developing jQuery UI 1.8 Widgets is also useful once you're familiar with the basics.

Always enclose the jQuery widgets, etc, in a function wrapper to sandbox them from globals

No inline JS -- we'd be forced to do this anyway, once we are using a function wrapper to sandbox, because the functions wouldn't be in a global namespace, and so we couldn't refer to them in the onclick handler. Much more maintainable too, since you can just look up the JS file to fix things, instead of having to dig into dozens of .bml and .pm files for any missing fragments of old behavior

Never use globals. If you're using something like LJ_cmtinfo, pass it in as an argument. This makes for less surprises and makes it much easier to test your code

Use this.element._trigger("customevent") in your plugins as much as you need, for flexibility. The fired event can be caught and handled using $("some-selector").bind("pluginnamecustomevent").

use existing plugins; look up third-party stuff too (but make sure license says it's okay to use -- if you're not sure ping denise.

write tests -- they seem like extra work, but they can help simplify things immensely by letting you check all behavior with a single page load, instead of clicking through a checklist, and forcing you to look at your code in a different way when you're trying to use it in a test (another post on that soon...)

Current existing plugins for reuse:

htdocs/js/tooltip.js

htdocs/js/jquery.ajaxtip.js - handles displaying a "busy" image, and updating the tooltip contents + class once we get a result. You can also provide preliminary content. Draft example of usage

(I'd actually love it if we could find something pre-written that does the tooltip+ajax+dynamic positioning+inserts it after an element instead of at the end of a document for accessibility reasons, but so far I haven't found anything that satisfies all my requirements)

An example of what all of that would look like is jQuery Template.

Actual working file: jquery.commentmanage.js
Tests for actual working file: views/dev/tests/commentmanage.js. Scroll down past the setup lines.

New JS implementation on Journals // jQuery Code Guidelines

Post a comment in response: