dw_dev | Entries tagged with jquery

I'm in the process of updating /customize/ to move it away from BML and a million widgets, and I've got most of the HTML-y stuff done, but I'm having trouble with the Javascript. The biggest part of this is redoing the AJAX queries, which were previously done in widget-specific ways and passed through a bunch of the Widget class handlers. Working off jQuery, I've gotten as far as getting it to submit a POST request which reaches the controller - but the param formatting is all wrong and missing a bunch of the parameters sent with a TT form POST request. Do we have methods for creating proper POST requests from AJAX?

We've just upgraded to the latest jQuery / jQuery UI version. I'd eventually like to settle us on jQuery 1.9 which according to their road map is the final one with support for older browsers, and will retain compatibility with 2.0 (which is lighter, by dropping said support for older browsers).

I've updated our own code as much as i could, to use the newer APIs, in some cases replacing our implementation with newly added functionality built into the library. I've also switched the tooltips from tooltip.js, to jquery ui's tooltips because the API fits everything else we use better and, more importantly, it's got people working on it who are focused on accessibility issues (so ARIA support, plus whatever else might be added in the future)

This gets rid of a schroedenbug with the contextualhover menu sometimes disappearing as soon as it appears at the risk of introducing new bugs. It overall seems to behave better, and was easier to debug, but do keep an eye out for weird behavior and let us know ASAP.

The contextualhover menu appearance has been changed; we have a bug open for actual further styling.

The light-colored theme for widgets has been tweaked just a tiny bit here and there. Most noticeable will probably be that dialog boxes/overlays now have a font size that matches the rest of the page, instead of being larger.

This isn't live on dreamwidth.org, but is on the develop branch, so you can poke at it. We'll push it live by next code push. If there aren't any major issues, we can take the jquery on journals out of beta shortly thereafter.

foxfirefey

Bug 3532, the jQuerify journals bug, is moving towards completion. On the next code push, there will be a post to

dw_beta for any remaining issues people are having. They'll be fixed and/or filed, depending on urgency, so that we can then turn on the jQuery for everyone, while still giving people a chance to turn the jQuery off. I imagine once all the issues are taken care of, the old journal Javascript will be deprecated and then removed.

For development, this means patches for old journal Javascript will no longer be accepted. If you see a bug open for old journal JS, it can be closed. (Don't do that if it's something that involves doing JS for the new JQuery version, though.)

( Extra info on: Why JQuery-izing? )

brainwane

I'm helping run a hackathon in San Francisco in two months, and wanted to let Dreamwidth developers know about it in case you want to come!

Developers in the Bay Area and Silicon Valley, you can create cool hacks with and on Wikipedia. Our first San Francisco hackathon is happening Jan. 20-22, and we'll be there teaching you about MediaWiki (our software), about our API and about our framework for JavaScript feature development. Learn to reuse Wikipedia content in your own apps, create new functionality for every Wikipedia user around the world, or just tailor your own experience.

We're going to create a registration form really soon but I wanted to tell you about this so you can put it on your calendar.

I figure you folks have better ideas for Wikipedia integration than I do (I didn't see any in Bugzilla but maybe they aren't there yet?). I know there's a WordPress plugin, PhotoCommons, that makes it easy for bloggers to browse Wikimedia Commons for freely licensed images to dress up their posts. Maybe replicating that functionality in Dreamwidth would be cool? I've added it to the Suggestions queue.

Of course you don't need to come to the event to work on MediaWiki or on integration with Wikimedia sites -- our site has an intro tutorial and we are on IRC at #mediawiki on FreeNode and so on. But if you came to the event, that would be cool too. Open data!

One background issue that keeps cropping up is that with our current JS code, we need to explicitly initialize handlers for any new content that's loaded on the page. That's why, for example, AJAXified polls and the cut tag expander wouldn't play nice at first. We had to tell the cut tag expander to explicitly initialize the JS for any polls in the newly loaded cut tag content.

As you can imagine (Bob) this isn't very fun. Inevitably, we end up forgetting edge cases, which we only turn up after a user has run into the issue and reported it. (We probably have three or four outstanding bugs that have to do with how we haven't called the init function on this page, or after doing that action, and well it's a pain.)

So a thought: I propose we start using jQuery's .live() function in conjunction with a custom event.

( cut for examples and discussion of efficiency )

ETA:
It looks like .delegate() is a better alternative to .live() (thanks

jproulx!

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.

( thoughts on standardizing jQuery implementation )

foxfirefey

Sometimes there are acts of

fu and the next thing you know you have a JavaScript testing framework integrated into our codebase, so as we make the transition to jQuery we can testify as well.

I've been thinking about updating to jQuery 1.4.2, and adding jQuery UI. The new update page will definitely need both, but I'd like to update us earlier, so that we can test all the pages which use jQuery before we start introducing new code that uses it. (I think there are what, like five of them? *g*)

Right now we're using jQuery 1.3.2. Here are the jQuery 1.4 release notes. Nested parameter serialization looks incompatible with what we use, but it's easy enough to turn back into traditional mode. We may also need to double-check our JSON output in the future, to make sure that it passes jQuery's stricter JSON parsing. None of the files that use jQuery have JSON though.

So, does anyone know any reason to avoid the upgrade? Speak now :)

S	M	T	W	T	F	S
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Dreamwidth Development

Entries tagged with jquery

Creating AJAX post parameters for TT Controller?

jQuery version update

jQuerify journals status

San Francisco Wikipedia hackathon, Jan. 20-22, and Wikimedia integration ideas for DW

"updatedcontent" custom event + $("*").live()

New JS implementation on Journals // jQuery Code Guidelines

Notice: stub documentation for JS testing framework

Upgrading to jQuery 1.4.2, adding jQuery UI 1.8.2

Profile

June 2025

Syndicate

Most Popular Tags

Page Summary

Active Entries

Style Credit

Expand Cut Tags