PagedDataGrid

Hi Nicolas!

This widget looks extremely interesting. Is there any usage example for it?

Berto


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Le vendredi 13 novembre 2009 à 11:47 +0200, Bèrto ëd Sèra a écrit :
> Hi Nicolas!
>
> This widget looks extremely interesting. Is there any usage example for it?

Hi Berto,

This widget was contributed by Eli Green. There is no example yet, but
if you can provide one, that would be great :D

He explained a bit how to use it in his post, but I changed a few things
since:

http://lists.gnu.org/archive/html/help-smalltalk/2009-10/msg00041.html
>
> Berto
>
>
> _______________________________________________
> help-smalltalk mailing list
> [hidden email]
> http://lists.gnu.org/mailman/listinfo/help-smalltalk

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Friday, November 13, 2009, at 02:48PM, "Nicolas Petton" <[hidden email]> wrote:
I'm still lurking if there are any questions.

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.

This change would not involve changing the example in any way.



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Le vendredi 13 novembre 2009 à 15:32 +0100, Eli Green a écrit :
>
> 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.

Nop, I completely agree with you.

Cheers!

Nico

_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

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.

Namely I need to:
1)  "drop" results from the search, so that you can pick what is
interesting for you and clear the rest
2) "drag and drop" elements of the list to rearrange the order inside
the list (this is where I'll need jQuery)

In practice, when the system is finished it will allow you to
1) search for material,
2) select stuff to "save" from individual searches
3) arrange individual searches in named "directories" inside the history widget
4) save/load/export/import these directories (this will be available
to registered users only)

The system is mainly going to be used by translators, so the set of
"useful stuff" mainly depends on the sort of things they are doing.
This way can build a "knowledge base" and use it when needed.

Berto



--
==============================
Constitution du 24 juin 1793 - Article 35. - Quand le gouvernement
viole les droits du peuple, l'insurrection est, pour le peuple et pour
chaque portion du peuple, le plus sacré des droits et le plus
indispensable des devoirs.


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

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

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.



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk