[Seaside] Seaside, AJAX, and Iliad

[Tony Fleig]

Comments injected below...

On Thu, Dec 2, 2010 at 4:38 AM, Esteban Lorenzano <estebanlm at gmail.com> wrote:
>> Here's what I found:
>>
>> 1. Documentation for Iliad is lacking (but so is documentation for Reef.)
>
> yep, that's true... I'm slooooowly working on that :)

Its a good thing that Smalltalk is so readable, because most Smalltalk
projects suffer from this problem.

>
>>
>> 2. 62 lines of code were required for the Reef implementation and 59
>> for Iliad (counted in the file-outs attached.)
>
> I don't think this is relevant at all, in fact... the example implementation is verbose on purpose, to show some details (and to construct a base for future tutorials)

I agree. Maybe I should have said that the amount of programming time
required or that the degree of difficulty was about equal between the
two instead of counting the lines of code.

>
>>
>> 3. Iliad's onKeyPress method does not return the last key pressed so I
>> used onKeyUp instead. This may be a bug in Iliad.
>>
>> 4. Here are Firebug statistics for a search returning 2 class names
>> (when the "u" in "Fu" is entered):
>>
>>  Reef:    4 requests returning a total of 684 bytes completed in 99 ms
>>  Iliad:   1 request returning 117 bytes completed in 17 ms
>>
>> In Reef, the first request causes the server to return Javascript
>> which is executed by the client and results in a second request to the
>> server fetching the HTML to be displayed. This actually happens twice,
>> with the first request returning an empty response. I don't know why
>> this is -- this may be a bug in Reef.
>
> Yes... that's a bug, I'm working on that now, thanks for pointing.
> But event correcting this, now you will need at least 2 requests (due to the architecture)... I'm working on optimizations, but as time is very sparced, it will take awhile until a fix this.
>
>>
>> Here are the first, third and fourth responses returned by the Reef
>> implementation (the second response was empty):
>>
>> <script type="text/javascript">/*<![CDATA[*/$.ajax({"url":"/ReefSimpleTutorial","data":["_s=PLLSmZdjxS49iq-7","_k=yrYmIWJloPEuTsPR","11",$("#idRETextField1025769472").serialize()].join("&"),"success":function(){$("#dispatcherArea").load("/ReefSimpleTutorial",["_s=PLLSmZdjxS49iq-7","_k=yrYmIWJloPEuTsPR","12"].join("&"))}})/*]]>*/</script>
>>
>> <script type="text/javascript">/*<![CDATA[*/$("#idREPanel139984896").load("/ReefSimpleTutorial",["_s=PLLSmZdjxS49iq-7","_k=yrYmIWJloPEuTsPR","13"].join("&"))/*]]>*/</script>
>>
>> <div id="idREPanel127926272"><span
>> id="idREText268435456">FullscreenMorph</span></div><div
>> id="idREPanel677642240"><span
>> id="idREText774373376">FuzzyLabelMorph</span></div>
>
> Yep, but that's all up to the example... If I change this:
>
>                resultsPanel
>                        addAll: (Smalltalk classNames
>                                select: [ :each | each beginsWith: text ]
>                                thenCollect: [ :each |
>                                        REPanel new
>                                                add: each;
>                                                yourself ]);
>                        refresh ]
>
> for this:
>
>                resultsPanel
>                        addAll: (Smalltalk classNames select: [ :each | each beginsWith: text ]);
>                        refresh ]
>
> (which, btw, reduces the "amount of lines needed" by 4), I have:
>
> <span id="idREText769654784">FullscreenMorph</span><span id="idREText770179072">FuzzyLabelMorph</span>
>
> as the answer of the request, which is a lot less.
>
>>
>>
>> In Iliad, the single request to the server returns a JSON object
>> containing the HTML to be displayed. here's what it looks like:
>>
>> {"head": [], "widgets": {"55535": "<div
>> class=\"55535\"><div>FullscreenMorph</div><div>FuzzyLabelMorph</div></div>"}}
>>
>> The Iliad response is certainly simpler and easier to comprehend.
>>
>> Quadrupling (or at best doubling) the number of server requests for a
>> given user input can result in a dramatic percieved performance
>> difference. In my experience, the number of requests is a more
>> important determiner of the time required to complete an action than
>> is the number of bytes transferred unless a quite large amount of data
>> is being returned from the server.
>
> Yes, that's true... I'm working on a way to reduce the amount of request sent. But, in any case, what reef is is a "general purpose" updater for html, and that approach has it's drawbacks... anyway , I'm working on some ideas to avoid this.
>
>
> Cheers,
> Esteban_______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>