First things first: I made some updates in the prototype. It now works as expected, allowing you to make a page a child of another page which doesn’t have children yet.
I also show in it what I think is the best way of handling pagination. The idea is to display an item from the main hierarchy before and another one after the items that belongs to the current page, in the ordering view. If the before/after main hierarchy item has children, all of its children should be displayed as well. In the demo, my before and after main hierarchy items are child less, therefore the “items bellow this” and “items above this” markers show up after one item, but that would vary. I did a lot thinking into this and think this is the only (and simpler) way you can move main items from one page into the other, without having “dark spots” (elements that are “stuck” in a page).
In trying to understand what was making nesting not working in the prototype, I had to dissect the Interface plugin code for the Draggables, Dropables and Sortables. I found the code pretty cluttered and hard to understand, filled up with variables with names such as “oC”, “oD”, “a”. In fact, almost no variables have meaningful, unabridged names. I had to do a lot of debugging, using Firebug. The code is very coupled as well as, for instance, you have calls to the Sortables plugin being made from the Draggable and Dropable (you would expect the Draggables and Dropables, as lower level elements, to be unaware of the Sortables existance). I didn’t like the code, but at least I understand it now.
Meanwhile, I found out the the jQuery team (John Resig, the creator, included) are creating an official, brand new set of UI plugins for jQuery. It is called jQuery UI. I wonder why they decided to skip Interface all together. It was not released yet, but already have working Draggables, Dropables and Sortables. I checked it out from SVN, looked at its code and tested it. The code is a great step foward from what I saw in Interface. Much cleaner, commented, well organized and easy to understand. Impressively, it also looks like they managed to keep it a lot smaller (30kB against 46kB of Interface’s). The coupling problem I mentioned doesn’t exist, as they created a generic callback in the Dragabble (called dropBehaviour), that the Sortable implements. That way, I could, for instance, create a brand new Sortable-like plugin, without having to modify Draggable’s or Dropable’s code. They seem to be tackling the “Sortable with Hierachy” problem as well, and have some partially working demos for it, in their test files.
Regarding the server side implementation, I am leaning towards passing the javascript a JSON representation of the page list, instead of generating the whole UL list in the server side. I think it will make things much more reusable, in both ways (reusing the javacript and the server side script). It will also download a lot faster for the client. I was thinking of using a JSON like this:
{
"columns":["Title(ID)", "Owner", "Updated"],
"items":
[
{
"id":1,
"info":["My Title(1)", "My Owner", "My Date"],
"children":
[
{
"id":2,
"info":["My Title(2)", "My Owner", "My Date"],
},
{
"id":3,
"info":["My Title(3)", "My Owner", "My Date"],
}
]
},
]
}
In this example we have a parent page which has two children. It doesn’t look so good because I can’t indent the code to display it here. I already implemented it on the prototype, so now, instead of loading the page list from an file with HTML and just displaying it, it loads a file with JSON and processes it to create the HTML on the fly. The JSON file for the prototype can be seen here: list_demo_json.js The JSON file has 2kB, versus 6kB for the HTML with the exact same data.
bits in a short bit 
