Strategies for bulky renders/updates

> I've been using seaside with jquery to create quite interactive
> interfaces, using the simplest approach of "everything has its own
> callback". This works well if the dataset you're working with is
> small, but I'm now venturing into territories where it takes seconds
> to receive+render a page, which isn't acceptable.
>
> For an example of what I'm talking about imagine a page showing a list
> of emails. Every line (email) has a clickable sender, subject, date,
> and a bunch of more actions and icons etc. If you're creating
> anchors/click actions for each field separately, that's easily
> hundreds or thousands of callbacks per page, each needing to be
> generated on the server and sent over the wire. So clearly I need to
> instead write client side javascript that will figure out what the
> user clicked and do a parametrized request. Which I can do, but I'm
> wondering if someone has figured out a clever way how to map the
> information on the page to smalltalk objects on the server (other than
> using callback registry). Same goes for bulk actions involving
> multiple items ("delete selected" and the like).

> I've been using seaside with jquery to create quite interactive
> interfaces, using the simplest approach of "everything has its own
> callback". This works well if the dataset you're working with is
> small, but I'm now venturing into territories where it takes seconds
> to receive+render a page, which isn't acceptable.
>
> For an example of what I'm talking about imagine a page showing a list
> of emails. Every line (email) has a clickable sender, subject, date,
> and a bunch of more actions and icons etc. If you're creating
> anchors/click actions for each field separately, that's easily
> hundreds or thousands of callbacks per page, each needing to be
> generated on the server and sent over the wire. So clearly I need to
> instead write client side javascript that will figure out what the
> user clicked and do a parametrized request. Which I can do, but I'm
> wondering if someone has figured out a clever way how to map the
> information on the page to smalltalk objects on the server (other than
> using callback registry). Same goes for bulk actions involving
> multiple items ("delete selected" and the like).

> I've been using seaside with jquery to create quite interactive
> interfaces, using the simplest approach of "everything has its own
> callback". This works well if the dataset you're working with is
> small, but I'm now venturing into territories where it takes seconds
> to receive+render a page, which isn't acceptable.
>
> For an example of what I'm talking about imagine a page showing a list
> of emails. Every line (email) has a clickable sender, subject, date,
> and a bunch of more actions and icons etc. If you're creating
> anchors/click actions for each field separately, that's easily
> hundreds or thousands of callbacks per page, each needing to be
> generated on the server and sent over the wire. So clearly I need to
> instead write client side javascript that will figure out what the
> user clicked and do a parametrized request. Which I can do, but I'm
> wondering if someone has figured out a clever way how to map the
> information on the page to smalltalk objects on the server (other than
> using callback registry). Same goes for bulk actions involving
> multiple items ("delete selected" and the like).
>
> rado
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> We have encountered a similar issue when generating lists of thousands of elements that each needed interactivity client-side. However, the issue was more related to having a jQuery editable for each of those html elements, which took seconds to register on each element separately. But the issue is identical in the sense that we needed to revert to a single Seaside callback that is triggered by a Javascript function.
>
> The solution boils down to the following:
> - have a unique identifier for each of the objects that allows a mapping from the identifier back to the object (e.g. we have unique keys for all objects in our db)
> - define a single seaside callback for the click event inside a javascript function
> - define the click event on the applicable html entities to use the above javascript function (e.g. using jQuery).
>
> The first item depends on how your application works. In the snippets below, I assume that <yourObjectRegistry> is a dictionary that allows a mapping from id to the object. These snippets illustrate how to achieve the second and third item.
>
> * Assign the seaside callback to a javascript function upon page load:
>
>        html document addLoadScript:
>                ((html jQuery ajax
>                                callback: [:id | (yourObjectRegistry at: id) doYourAction ]
>                                value: (JSStream on: 'id')) asFunction: #(id))
>                        assignTo: 'clickAction'
>
> * Register the click events on each applicable html element such that they call the previously defined javascript function:
>
>        html listItem
>                onClick: (JSStream on: 'clickAction($(this).id)');
>                with: [ ... ]
>
>
> I hope this helps you out. But I'm not sure if that will really improve page rendering speed or size. The size of the callback url is not that much different from the size of the onClick event script.
> In our case, by doing the above, we did not need to include the triggering of a jQuery editable for each generated html element. That resulted in a 10 times page rendering speedup because the load script was not registering the +1000 editables anymore.
> But let us know how it went!
>
> Johan
>
> On 13 Mar 2011, at 03:21, radoslav hodnicak wrote:
>
>> I've been using seaside with jquery to create quite interactive
>> interfaces, using the simplest approach of "everything has its own
>> callback". This works well if the dataset you're working with is
>> small, but I'm now venturing into territories where it takes seconds
>> to receive+render a page, which isn't acceptable.
>>
>> For an example of what I'm talking about imagine a page showing a list
>> of emails. Every line (email) has a clickable sender, subject, date,
>> and a bunch of more actions and icons etc. If you're creating
>> anchors/click actions for each field separately, that's easily
>> hundreds or thousands of callbacks per page, each needing to be
>> generated on the server and sent over the wire. So clearly I need to
>> instead write client side javascript that will figure out what the
>> user clicked and do a parametrized request. Which I can do, but I'm
>> wondering if someone has figured out a clever way how to map the
>> information on the page to smalltalk objects on the server (other than
>> using callback registry). Same goes for bulk actions involving
>> multiple items ("delete selected" and the like).
>>
>> rado
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> Johan Brichau wrote:
>>
>> * Register the click events on each applicable html element such that they
>> call the previously defined javascript function:
>>
>>        html listItem           onClick: (JSStream on:
>> 'clickAction($(this).id)');
>>                with: [ ... ]
>>
>
> A was thinking about the same problem just today. A potential problem is
> that it leaks IDs into HTML. One could easily guess a valid ID which maps to
> a database object which he normally wouldn't have access to. Hm... unless
> you take special care to obfuscate the ID.

> Johan Brichau wrote:
>>
>> * Register the click events on each applicable html element such that they
>> call the previously defined javascript function:
>>
>>        html listItem           onClick: (JSStream on:
>> 'clickAction($(this).id)');
>>                with: [ ... ]
>>
>
> A was thinking about the same problem just today. A potential problem is
> that it leaks IDs into HTML. One could easily guess a valid ID which maps to
> a database object which he normally wouldn't have access to. Hm... unless
> you take special care to obfuscate the ID.
>
>
>
> --
> Milan Mimica
> http://sparklet.sf.net
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>