[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-smalltalk] PagedDataGrid
From: |
Eli Green |
Subject: |
Re: [Help-smalltalk] PagedDataGrid |
Date: |
Sat, 14 Nov 2009 11:19:43 +0100 |
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.