Smalltalk › Frameworks & Tools › Seaside › Seaside General

Seaside, AJAX, and Iliad

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

tfleig

Seaside, AJAX, and Iliad

Hi,

I'm relatively new to Seaside and I am re-entering the Smalltalk world after many years.

I have reached the following conclusions regarding the Iliad and Seaside frameworks -- admittedly without a truly thorough investigation.

Seaside is robust and mature and well-documented but was originally developed without AJAX features in mind. The AJAX features in Seaside, while viable, feel like an afterthought compared to the built-in AJAXification in Iliad. Per-widget in-place update using markDirty is dirt-simple in Iliad and is assumed to be the default method of updating. The corresponding functionality in Seaside is comparatively complex to use and to me, confusing.

Seaside's wonderful back-button management with continuations breaks when AJAX is used. Iliad has a "different" back-button approach (which is not clearly defined anywhere that I could find).

Is there any chance that Seaside could acquire markDirty functionality and "automatic" AJAX callbacks like Iliad? I really like Seaside's completeness and well-documented features, but I find myself drawn to Iliad instead because for Web-2.0-style apps the out-of-the-box (default) user experience is so much better.

Am I off-base here? Have I missed something important in my analysis?

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli

Re: Seaside, AJAX, and Iliad

> Seaside's wonderful back-button management with continuations breaks when
> AJAX is used. Iliad has a "different" back-button approach (which is not
> clearly defined anywhere that I could find).
> Is there any chance that Seaside could acquire markDirty functionality and
> "automatic" AJAX callbacks like Iliad? I really like Seaside's completeness
> and well-documented features, but I find myself drawn to Iliad instead
> because for Web-2.0-style apps the out-of-the-box (default) user experience
> is so much better.
> Am I off-base here? Have I missed something important in my analysis?

Well, Seaside 3.0 has the JQAjaxifierLibrary built in, see

http://www.lukas-renggli.ch/blog/ajaxification
http://www.lukas-renggli.ch/blog/ajaxification-faq

I have been using successfully using this approach in various
industrial applications since 2007 with PrototypeJS and later with
JQuery. Albeit it has not gained much popularity in the wider Seaside
community, I personally find it very elegant for the following
reasons:

1. You develop a normal application, you get an AJAX application for free.

2. You do not need to mark components as dirty.

3. You keep the full flexibility of how you structure your HTML.

4. You keep the full flexibility of doing custom AJAX actions if
necessary (e.g. to optimize certain updates).

Lukas

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Bernat Romagosa

Re: Seaside, AJAX, and Iliad

Hi,

Maybe I missunderstood, but I just added JQAjaxifierLibrary to an old app I built and nothing changed at all, all requests still render the full page. Am I missing some step?

Just in case it matters, my app had the following libraries already loaded:

JQDeploymentLibrary

JQUiDeploymentLibrary

PTDeploymentLibrary

SUDeploymentLibrary

Bernat Romagosa.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Robert Sirois

RE: Seaside, AJAX, and Iliad

You can't use Prototype and jQuery simulateously.

RS

From: [hidden email]
Date: Wed, 1 Dec 2010 20:11:01 +0100
Subject: Re: [Seaside] Seaside, AJAX, and Iliad
To: [hidden email]

Hi,

Maybe I missunderstood, but I just added JQAjaxifierLibrary to an old app I built and nothing changed at all, all requests still render the full page. Am I missing some step?

Just in case it matters, my app had the following libraries already loaded:

JQDeploymentLibrary

JQUiDeploymentLibrary

PTDeploymentLibrary

SUDeploymentLibrary

Bernat Romagosa.

_______________________________________________ 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

Bernat Romagosa

Re: Seaside, AJAX, and Iliad

I disagree, I've been using jQuery and Prototype together successfully. You just have to modify JQuery class>>initialize to have JQuery class>>functionName return something different than '$'. This was pointed to me by Lukas a couple months ago.

I found out that adding JQAjaxifierLibrary did change the app's behaviour, but the only noticeable thing (to me) is that the ? in the address bar turned into an #, the speed remains the same and pages are still fully rendered.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

tfleig

Re: Seaside, AJAX, and Iliad

In reply to this post by Lukas Renggli

Wow I'm glad I asked. I'll give JQAjaxifierLibrary a try.

Thanks a lot.

On Wed, Dec 1, 2010 at 10:41 AM, Lukas Renggli <[hidden email]> wrote:

> Seaside's wonderful back-button management with continuations breaks when
> AJAX is used. Iliad has a "different" back-button approach (which is not
> clearly defined anywhere that I could find).
> Is there any chance that Seaside could acquire markDirty functionality and
> "automatic" AJAX callbacks like Iliad? I really like Seaside's completeness
> and well-documented features, but I find myself drawn to Iliad instead
> because for Web-2.0-style apps the out-of-the-box (default) user experience
> is so much better.
> Am I off-base here? Have I missed something important in my analysis?

Well, Seaside 3.0 has the JQAjaxifierLibrary built in, see

http://www.lukas-renggli.ch/blog/ajaxification
http://www.lukas-renggli.ch/blog/ajaxification-faq

I have been using successfully using this approach in various
industrial applications since 2007 with PrototypeJS and later with
JQuery. Albeit it has not gained much popularity in the wider Seaside
community, I personally find it very elegant for the following
reasons:

1. You develop a normal application, you get an AJAX application for free.

2. You do not need to mark components as dirty.

3. You keep the full flexibility of how you structure your HTML.

4. You keep the full flexibility of doing custom AJAX actions if
necessary (e.g. to optimize certain updates).

Lukas

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
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

tfleig

Re: Seaside, AJAX, and Iliad

Ok, I tried JQAjaxifierLibrary on a few of my test apps and here's what i saw:

1. It definitely improves the user experience by doing what appears to be in-place updating -- no flicker as the page reloads.

2. As advertised, it required no changes to my code and my existing AJAX callbacks continued to work without modification.

3. I compared the Iliad multi-counter example with the Seaside multi-counter example after adding JQAjaxifierLibrary to it. The ajaxified Seaside multicounter updates were noticably smoother than in the un-ajaxified version.

With a local server, the Iliad multicounter accomplishes the update in about one-half the time required by the Seaside version (about 10ms vs 20ms on my hardware). The Iliad response content length was 322 bytes while the Seaside response was 2603 bytes. (The toolbar was 893 of those bytes so the size for comparison should be 1710 bytes or about 5X the Iliad response.) The Iliad response contained an update for the changed counter only (and some overhead) while the Seaside response contained the entire page.

I think the major difference here is that the Iliad implementation, while requiring the programmer to manually mark widgets dirty, only updates the changed widgets, while ajaxified Seaside continues to render the entire page (albeit in a background request.)

In practice, I could observe no difference between the two -- I can't tell the difference between 10 and 20 ms -- so for relatively small updates this difference is probably not interesting. I would think for a page composed of many complex components though, the difference could conceivably be significant both in server processing load and transfer time when only one component of many is updated.

Regards,

On Wed, Dec 1, 2010 at 11:45 AM, Tony Fleig <[hidden email]> wrote:

Wow I'm glad I asked. I'll give JQAjaxifierLibrary a try.

Thanks a lot.
TF

On Wed, Dec 1, 2010 at 10:41 AM, Lukas Renggli <[hidden email]> wrote:

> Seaside's wonderful back-button management with continuations breaks when
> AJAX is used. Iliad has a "different" back-button approach (which is not
> clearly defined anywhere that I could find).
> Is there any chance that Seaside could acquire markDirty functionality and
> "automatic" AJAX callbacks like Iliad? I really like Seaside's completeness
> and well-documented features, but I find myself drawn to Iliad instead
> because for Web-2.0-style apps the out-of-the-box (default) user experience
> is so much better.
> Am I off-base here? Have I missed something important in my analysis?

Well, Seaside 3.0 has the JQAjaxifierLibrary built in, see

http://www.lukas-renggli.ch/blog/ajaxification
http://www.lukas-renggli.ch/blog/ajaxification-faq

I have been using successfully using this approach in various
industrial applications since 2007 with PrototypeJS and later with
JQuery. Albeit it has not gained much popularity in the wider Seaside
community, I personally find it very elegant for the following
reasons:

1. You develop a normal application, you get an AJAX application for free.

2. You do not need to mark components as dirty.

3. You keep the full flexibility of how you structure your HTML.

4. You keep the full flexibility of doing custom AJAX actions if
necessary (e.g. to optimize certain updates).

Lukas

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
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

Lukas Renggli

Re: Seaside, AJAX, and Iliad

Also note that there is Reef an extension to Seaside by Esteban
Lorenzano, that provides the kind of update mechanism you ask for. He
presented it last ESUG in Barcelona and it was really impressive:

http://www.smallworks.com.ar/en/community/Reef

Lukas

On 1 December 2010 18:37, Tony Fleig <[hidden email]> wrote:

> Ok, I tried JQAjaxifierLibrary on a few of my test apps and here's what i
> saw:
> 1. It definitely improves the user experience by doing what appears to be
> in-place updating -- no flicker as the page reloads.
> 2. As advertised, it required no changes to my code and my existing AJAX
> callbacks continued to work without modification.
> 3. I compared the Iliad multi-counter example with the Seaside multi-counter
> example after adding JQAjaxifierLibrary to it. The ajaxified Seaside
> multicounter updates were noticably smoother than in the un-ajaxified
> version.
> With a local server, the Iliad multicounter accomplishes the update in about
> one-half the time required by the Seaside version (about 10ms vs 20ms on my
> hardware). The Iliad response content length was 322 bytes while the Seaside
> response was 2603 bytes. (The toolbar was 893 of those bytes so the size for
> comparison should be 1710 bytes or about 5X the Iliad response.) The Iliad
> response contained an update for the changed counter only (and some
> overhead) while the Seaside response contained the entire page.
> I think the major difference here is that the Iliad implementation, while
> requiring the programmer to manually mark widgets dirty, only updates the
> changed widgets, while ajaxified Seaside continues to render the entire page
> (albeit in a background request.)
> In practice, I could observe no difference between the two -- I can't tell
> the difference between 10 and 20 ms -- so for relatively small updates this
> difference is probably not interesting. I would think for a page composed of
> many complex components though, the difference could conceivably be
> significant both in server processing load and transfer time when only one
> component of many is updated.
> Regards,
> TF
>
> On Wed, Dec 1, 2010 at 11:45 AM, Tony Fleig <[hidden email]> wrote:
>>
>> Wow I'm glad I asked. I'll give JQAjaxifierLibrary a try.
>> Thanks a lot.
>> TF
>>
>> On Wed, Dec 1, 2010 at 10:41 AM, Lukas Renggli <[hidden email]> wrote:
>>>
>>> > Seaside's wonderful back-button management with continuations breaks
>>> > when
>>> > AJAX is used. Iliad has a "different" back-button approach (which is
>>> > not
>>> > clearly defined anywhere that I could find).
>>> > Is there any chance that Seaside could acquire markDirty functionality
>>> > and
>>> > "automatic" AJAX callbacks like Iliad? I really like Seaside's
>>> > completeness
>>> > and well-documented features, but I find myself drawn to Iliad instead
>>> > because for Web-2.0-style apps the out-of-the-box (default) user
>>> > experience
>>> > is so much better.
>>> > Am I off-base here? Have I missed something important in my analysis?
>>>
>>> Well, Seaside 3.0 has the JQAjaxifierLibrary built in, see
>>>
>>> http://www.lukas-renggli.ch/blog/ajaxification
>>> http://www.lukas-renggli.ch/blog/ajaxification-faq
>>>
>>> I have been using successfully using this approach in various
>>> industrial applications since 2007 with PrototypeJS and later with
>>> JQuery. Albeit it has not gained much popularity in the wider Seaside
>>> community, I personally find it very elegant for the following
>>> reasons:
>>>
>>> 1. You develop a normal application, you get an AJAX application for
>>> free.
>>>
>>> 2. You do not need to mark components as dirty.
>>>
>>> 3. You keep the full flexibility of how you structure your HTML.
>>>
>>> 4. You keep the full flexibility of doing custom AJAX actions if
>>> necessary (e.g. to optimize certain updates).
>>>
>>> Lukas
>>>
>>> --
>>> Lukas Renggli
>>> www.lukas-renggli.ch
>>> _______________________________________________
>>> 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
>
>

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Carlos Crosetti-3

Re: Seaside, AJAX, and Iliad

In reply to this post by Bernat Romagosa

please send the URL to Prototype... thanks!

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Wednesday, December 01, 2010 4:32 PM

Subject: Re: [Seaside] Seaside, AJAX, and Iliad

I disagree, I've been using jQuery and Prototype together successfully. You just have to modify JQuery class>>initialize to have JQuery class>>functionName return something different than '$'. This was pointed to me by Lukas a couple months ago.

I found out that adding JQAjaxifierLibrary did change the app's behaviour, but the only noticeable thing (to me) is that the ? in the address bar turned into an #, the speed remains the same and pages are still fully rendered.

_______________________________________________
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

tfleig

Re: Seaside, AJAX, and Iliad

In reply to this post by Lukas Renggli

I loaded the Reef extension and built the example search application
from the Reef tutorial. Then I built the same application in Iliad for
comparison. I tried to use the same application architecture as much
as possible -- Seaside and Iliad are actually quite similar so the
applications map very closely.

The example application presents a text input box. As the user enters
characters into the text box, a list of the Smalltalk class names
beginning with the letters entered appear below the text box. Thus,
when "F" is entered, all class names beginning with F appear. If a "u"
is then entered, the list shrinks to the class names "FullScreenMorph"
and "FuzzyLabelMorph".

Here's what I found:

1. Documentation for Iliad is lacking (but so is documentation for Reef.)

2. 62 lines of code were required for the Reef implementation and 59
for Iliad (counted in the file-outs attached.)

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.

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>

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.

I think I will attempt conversion of one of my more ambitious Seaside
applications to Iliad and see how that works out. I would expect most
if not all of my Ajax-related code to disappear in the Iliad version.
I curious to see what deficiencies in Iliad I uncover at the same
time...

TF
On Wed, Dec 1, 2010 at 1:57 PM, Lukas Renggli <[hidden email]> wrote:

>
> Also note that there is Reef an extension to Seaside by Esteban
> Lorenzano, that provides the kind of update mechanism you ask for. He
> presented it last ESUG in Barcelona and it was really impressive:
>
> http://www.smallworks.com.ar/en/community/Reef
>
> Lukas
>
> On 1 December 2010 18:37, Tony Fleig <[hidden email]> wrote:
> > Ok, I tried JQAjaxifierLibrary on a few of my test apps and here's what i
> > saw:
> > 1. It definitely improves the user experience by doing what appears to be
> > in-place updating -- no flicker as the page reloads.
> > 2. As advertised, it required no changes to my code and my existing AJAX
> > callbacks continued to work without modification.
> > 3. I compared the Iliad multi-counter example with the Seaside multi-counter
> > example after adding JQAjaxifierLibrary to it. The ajaxified Seaside
> > multicounter updates were noticably smoother than in the un-ajaxified
> > version.
> > With a local server, the Iliad multicounter accomplishes the update in about
> > one-half the time required by the Seaside version (about 10ms vs 20ms on my
> > hardware). The Iliad response content length was 322 bytes while the Seaside
> > response was 2603 bytes. (The toolbar was 893 of those bytes so the size for
> > comparison should be 1710 bytes or about 5X the Iliad response.) The Iliad
> > response contained an update for the changed counter only (and some
> > overhead) while the Seaside response contained the entire page.
> > I think the major difference here is that the Iliad implementation, while
> > requiring the programmer to manually mark widgets dirty, only updates the
> > changed widgets, while ajaxified Seaside continues to render the entire page
> > (albeit in a background request.)
> > In practice, I could observe no difference between the two -- I can't tell
> > the difference between 10 and 20 ms -- so for relatively small updates this
> > difference is probably not interesting. I would think for a page composed of
> > many complex components though, the difference could conceivably be
> > significant both in server processing load and transfer time when only one
> > component of many is updated.
> > Regards,
> > TF
> >
> > On Wed, Dec 1, 2010 at 11:45 AM, Tony Fleig <[hidden email]> wrote:
> >>
> >> Wow I'm glad I asked. I'll give JQAjaxifierLibrary a try.
> >> Thanks a lot.
> >> TF
> >>
> >> On Wed, Dec 1, 2010 at 10:41 AM, Lukas Renggli <[hidden email]> wrote:
> >>>
> >>> > Seaside's wonderful back-button management with continuations breaks
> >>> > when
> >>> > AJAX is used. Iliad has a "different" back-button approach (which is
> >>> > not
> >>> > clearly defined anywhere that I could find).
> >>> > Is there any chance that Seaside could acquire markDirty functionality
> >>> > and
> >>> > "automatic" AJAX callbacks like Iliad? I really like Seaside's
> >>> > completeness
> >>> > and well-documented features, but I find myself drawn to Iliad instead
> >>> > because for Web-2.0-style apps the out-of-the-box (default) user
> >>> > experience
> >>> > is so much better.
> >>> > Am I off-base here? Have I missed something important in my analysis?
> >>>
> >>> Well, Seaside 3.0 has the JQAjaxifierLibrary built in, see
> >>>
> >>> http://www.lukas-renggli.ch/blog/ajaxification
> >>> http://www.lukas-renggli.ch/blog/ajaxification-faq
> >>>
> >>> I have been using successfully using this approach in various
> >>> industrial applications since 2007 with PrototypeJS and later with
> >>> JQuery. Albeit it has not gained much popularity in the wider Seaside
> >>> community, I personally find it very elegant for the following
> >>> reasons:
> >>>
> >>> 1. You develop a normal application, you get an AJAX application for
> >>> free.
> >>>
> >>> 2. You do not need to mark components as dirty.
> >>>
> >>> 3. You keep the full flexibility of how you structure your HTML.
> >>>
> >>> 4. You keep the full flexibility of doing custom AJAX actions if
> >>> necessary (e.g. to optimize certain updates).
> >>>
> >>> Lukas
> >>>
> >>> --
> >>> Lukas Renggli
> >>> www.lukas-renggli.ch
> >>> _______________________________________________
> >>> 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
> >
> >
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
> _______________________________________________
> 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

TF-Reef.st (2K) Download Attachment

TF-Iliad.st (1K) Download Attachment

EstebanLM

Re: Seaside, AJAX, and Iliad

> 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 :)

>
> 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)

>
> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

tfleig

Re: Seaside, AJAX, and Iliad

Comments injected below...

On Thu, Dec 2, 2010 at 4:38 AM, Esteban Lorenzano <[hidden email]> 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
> [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