[Seaside] Strategies for bulky renders/updates

[radoslav hodnicak]

Yes Johan, I've been thinking along similar lines, with the exception
that what I really want to do is to register one seaside callback and
one javascript event handler on the parent object. For example, if you
have a table/list with 500 cells, you don't attach an event handler to
each cell, but one to the table itself, or to a container above it.
This will speed up page generation/rendering a lot. The handler will
then look at the id/class of the cell that generated the event and
figure out what to do/send to seaside.

rado

On Sun, Mar 13, 2011 at 1:56 PM, Johan Brichau <johan at inceptive.be> wrote:
> 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
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>