Re: [Help-smalltalk] PagedDataGrid

[Eli Green]

On Nov 14, 2009, at 06:18, Bèrto ëd Sèra wrote:

> sorry, I hit the wrong reply, as I often do...
> 
> 
> ---------- Forwarded message ----------
> 
> Hi Eli!
> 
>> I've not had a lot of time to play with Iliad since my first contact with it 
>> but I was thinking that each row should be its own
>> widget so that it can be marked dirty separately from the entire table. This 
>> means if you edit an item in a table with a few
>> hundred records, the page update would still be quite small. I don't think 
>> it's necessary to have separate objects at the
>> cell level but I may very well be wrong.
> 
> Makes sense to me, especially since I have a number of needs on these widgets.
> To make sure I get some much needed criticism I'll quote the real app
> at http://www.voxhumanitatis.net/ambaradan
> 
> This is a dictionary (hit "search" no matter with what text and you'll
> get the results for 'Africa", see other msg). Anyway, you do see what
> one gets from a search. A single row in this case is not necessarily a
> widget, as an entity may have more than one textual bit that answers
> the query (see "Central Africa"). Dive will do pretty much what does
> in an inspect, etc.

The current version of the grid could probably use a fair bit of refactoring. 
It was the first piece of Iliad code that I wrote and to really be 
industrial-strength and easy to extend could use a thorough review of the kinds 
of things people might want to customize.

In your case, you could simply subclass it and override the body message to 
have multiple rows for each item. Right now it generates the "tr" before called 
rowForItem: ... maybe it shouldn't. Maybe rowForItem should be rowsForItem and 
people should be responsible for generating all the "tr" tags they want.

> 
> Namely I need to:
> 1)  "drop" results from the search, so that you can pick what is
> interesting for you and clear the rest

In this case, having separate widgets for each row wouldn't help. If the data 
grid wasn't paginated you could cheat a little and just set display:none on the 
row but if it's paginated, it will need to re-render itself. The good thing is 
that if it's paginated, there's probably not that many items onscreen so 
marking the whole table dirty isn't that big a deal.

> 2) "drag and drop" elements of the list to rearrange the order inside
> the list (this is where I'll need jQuery)

This shouldn't require marking the widget dirty at all, as long as you can 
guarantee that the sorting operation has been performed on the server before 
you let the sort finish. I haven't thoroughly investigated how the 
communication between the browser and Iliad is handled but basically you want 
the ajax request to be synchronous and only once the sorting operation has 
completed should you permit sortable()'s "stop" handler to exit:

$('.selector').sortable({
        /* ... */
        stop: function(event, ui) {
                /* do communication here */
                if (!success) {
                        $(this).sortable('cancel');
                }
        }
});

I have no idea exactly how to get the value of "success" - I guess it would 
just be making sure that the server did in fact receive the request and didn't 
raise an exception. You can pass "async: false" to the jQuery.ajax method which 
seems to be what Iliad uses but somebody with a little more Iliad knowledge can 
comment more intelligently on this.