SeasideAsync and Scriptaculous
Locked
 
|
There are many differences between SeasideAsync and Scriptaculous.
Speaking with the Scriptaculous semantics, SeasideAsync only supports ajax things (i.e. updaters, requests, evaluators and periodicals) while Scriptaculous can do a lot more things like effects, triggers, drag/ drop. Also there are many differences in how the ajax things are done by SeasideAsync and Scriptaculous. For the ajax things, SeasideAsync has two concepts : live requests and event trackers, Scriptaculous has four (i.e. updaters, requests, evaluators and periodicals). A Scriptaculous updater results in a callback block being evaluated on the server like this onClick: ( html updater id: 'counter'; callback: [ :h | h render: count ] ) This callback generates an HTTP response containing some text data. It can be just plain data or it can be an fragment of XHTML. This text data replaces the contents of some html element in the page which has been explicitely designated by the Scriptaculous updater using the #id: message html span id: 'counter'; with: count. This means that a Scriptaculous updater can only update one html element at a time. If you need to update multiple html elements in a page, then you need to stack multiple updaters like this onClick: ( html updater ...); onClick: ( html updater ...); On the opposite, SeasideAsync can update multiple html elements in one callback, like this. onClickCallback: [ :e :h | h span id: 'counter1'; with: count1. h span id: 'counter2'; with: count2]. This callback generates an HTTP response containing a well-formed XML document. This XML document is parsed and the contents of each xml element found with an id= attribute is used for replacing the matching html element in the page (matching means same id= attribute value). If the XML document produced by the live callback happens to contain some script elements, these scripts are always evaluated (unlike Scriptaculous that requires sending #evalScripts: true to the updater). If nothing useful can be done with the XML document, i.e. no replacement and no script evaluation, this is considered as an application bug and a javascript alert occurs showing the contents of the XML document. Another difference between the Scriptaculous updater callback and the SeasideAsync callback. The Scriptaculous callback takes only one argument, the canvas where to write the response. The SeasideAsync takes two arguments, an event object and the canvas where to write the response. The event object is an instance of WALiveEvent and describes the actual event that triggered the live callback. It holds information about when the ajax occured in the client, what type of event, what html element triggered the event, what type of element, the value of the html element... The above applies only to SeasideAsync event tracking callbacks (#onEvent:callback:) For live requests (#liveCallback:), the callback block takes also two argument, but the first argument is the value of the html element (extracted from the event object as a matter of fact). HTH Michel. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: SeasideAsync and Scriptaculous
|
|
Some corrections ...
> Also there are many differences in how the ajax things are done by > SeasideAsync and Scriptaculous. For the ajax things, SeasideAsync > has two concepts : live requests and event trackers, Scriptaculous > has four (i.e. updaters, requests, evaluators and periodicals). In fact periodicals are not a new concept, they are just updater that get executed periodically. In fact, I plan to deprecate the periodical updater, and use a periodical decoration that can then be used with any Javascript object. This is also the direction that the JavaScript library is going and the latest PeriodicalUpdater is implemented with. > This means that a Scriptaculous updater can only update one > html element at a time. If you need to update multiple html elements > in a page, then you need to stack multiple updaters like this > > onClick: ( html updater ...); > onClick: ( html updater ...); No one would want to write it like this, it is very inefficient as it creates multiple requests. This is why there is the evaluator: onClick: (html evaluator callback: [ :script | script element id: 'counter1'; render: count1. script element id: 'counter2'; render: count2 ]) Note that you can do also a lot of other things, besides just updating the contents of a tag. - replacing/removing the tag - inserting contents above or below the tag - inserting contents at the top or bottom within the tag - adding/removing a css class from a tag - toggle the visibility, scroll to the element - apply all kinds of effects on the element > This callback generates an HTTP response containing a well-formed > XML document. This XML document is parsed and the contents of each > xml element found with an id= attribute is used for replacing the > matching The generated HTTP response of the above code is a well formed text/javascirpt document, that gets executed in the context of the Web page. > If the XML document produced by the live callback happens to contain > some script elements, these scripts are always evaluated (unlike > Scriptaculous that requires sending #evalScripts: true to the updater). That can be changed on the Smalltalk side, it is just the default behavior of the JavaScript libraries. > Another difference between the Scriptaculous updater callback and the > SeasideAsync callback. The Scriptaculous callback takes only one > argument, > the canvas where to write the response. The SeasideAsync takes two > arguments, > an event object and the canvas where to write the response. The event > object is > an instance of WALiveEvent and describes the actual event that > triggered the > live callback. It holds information about when the ajax occured in > the client, > what type of event, what html element triggered the event, what type > of element, > the value of the html element... There is an unlimited number of parameters that can be serialized at once, that's what the callback and trigger-protocol is for. It allows to transfer any JavaScript/DOM/Browser state (not just the current event) to the client. There are convenience methods that automatically map DOM elements to Smalltalk object, so you can get much fancier things than just a string ... real Smalltalk objects. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: SeasideAsync and Scriptaculous
|
|
Lukas Renggli a écrit :
> Some corrections ... Wow, that's powerful... I have a lot more to learn. Thanks for all this info. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: SeasideAsync and Scriptaculous
|
|
In reply to this post by Michel Bany-3
Indeed, thanks for taking the time, Lukas. This is some good stuff. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |