Demo of the AJAX table swap

June 29, 2007

As promised, I am posting a static demo of the legacy page list being replaced, via AJAX, by its sortable version.  It can be seen here. With this approach, we won’t have to mess too much with the WordPress core and will have a very similar functionality to the one proposed before.

Summarizing,  we will have an AJAX call fetch the sortable version of the list (made with ULs and DIVs) when the user presses “Edit Page Order”. Alternatively, we could send this list already in the initial page fetch, and keep it stored in a variable, until the user pressed the button. We now need a “Cancel” button, because the user may want to return to the default view of the list without committing the page ordering changes. In the previous version we didn’t need the “Cancel” button, because everything that could be done with the page list could also be done when “drag” was enabled.

The look of the whole thing is still very rough. I think the sortable version shouldn’t have the “actions” column, and probably won’t need the “drag handle”, making the whole item draggable. They were essential in the previous version, but for this one, as the only function the sortable list will have is sorting, those things are pointless.

The sortable page list should probably have a more distinct appearance, making it easier to tell from the default page list. Also, the “standard” AJAX animations, informing the user something is being loaded, should also be included.

Another approach I have been thinking of, way more radical, would be generating the sortable version of the list from the legacy one, in realtime, using javascript, by interpreting the legacy list. It wouldn’t be very hard, as jQuery makes it very easy to search for things in HTML. The advantage would be not needing to mess with the page list php code at all and not having to load anything via AJAX (it would be faster for the user). But I think it would couple the code too much, and future changes in the table could break it. Even if that wasn’t the case, it feels too quick and dirty to me.

There are still some bugs in the sortable list (adding a page as a child of another who has no children yet is not working). Also, other ugly things are not treated (eg. the user could click twice in the Edit, before the list is loaded). But this is still a prototype. 😉

In the next two weeks, before “Mid-Term”, I should dedicate 24 hours a day to the project (with some occasional time for the bathroom and some junk food), so expect things to go much faster from now on. Unfortunately, here in Brazil it is winter and our vacations and shorter. Mine are only starting now and my college is very demanding, specially in the last weeks of the semester.



  1. Looks good. I don’t think any of the other “columns” are needed dragging list – just the page name. It’s probably more complicated than it’s worth to include other columns; fixed widths don’t work well with internationalization. For example “Actions” in Swahili may be way more than 13em.

    How do you propose to handle children pagination?

  2. I can’t wait to see it in action, that’s exactly what I’m looking for !

  3. Mike: I did come up with an idea to handle pagination. It is still a lot worse than just not using pagination, because if the user wants to make a lot of “cross page” order changes he will be slowed down considerably. I am still battling with understanding the iDrag, iDrop, and iSortable code, but will post a demo of it in the next couple of days.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: