Using javascript toolkits for smalltalkers
Locked
Using javascript toolkits for smalltalkers
 
|
Hi
Lukas,
I, as a lot of people, are using the
excellent job you made "mapping" Scriptaculous to enjoy javascript
smalltalkishly. As you where able to make such a thing I wanted to ask what is
your opinion about the starting point of such kind of work for other toolkits
for smalltalkers. I mean, I have some years on smalltalk and I'm a newbie in
javascript and I want to have an idea of what to expect of the development
in the formula smalltalk+javascript. I know results are great, but I want to
understand more deeply the "path" to them.
To be honest I'm interested in a
couple of widgets of the dojo javascript toolkit but I don't want to mess
arround until I get it, so if I want to "map" a smalltalkish access to them into
Squeak for instance, which should be my starting point? how the normal cycle of
development should be (I mean debugging things that are not in st debugger,
javascript tutorials that are good to smalltalkers, etc)?
OK, maybe I'm asking for your
article about your experience making Scriptaculous accessible for Seaside. I'm
pretty sure that the description of your experience will encourage others to
make things as good as the one you made,
cheers,
_______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Using javascript toolkits for smalltalkers
|
|
Hi Sebastian,
> I, as a lot of people, are using the excellent job you made "mapping" > Scriptaculous to enjoy javascript smalltalkishly. As you where able to make > such a thing I wanted to ask what is your opinion about the starting point > of such kind of work for other toolkits for smalltalkers. I mean, I have > some years on smalltalk and I'm a newbie in javascript and I want to have an > idea of what to expect of the development in the formula > smalltalk+javascript. I know results are great, but I want to understand > more deeply the "path" to them. first I must say that the Scriptaculous package is not entirely my own work, Avi started it all back in June 2005. In the beginning there was just basic AJAX functionality and some effects. The evolution of Scriptaculous was a highly iterative process. While I tried to add more functionality, and eventually supported all the things available trough JavaScript, I also had to rethink and redesign the the Smalltalk object model several times to accomodate new needs. The most difficult thing was that JavaScript is a prototype based language, even though most libraries (including prototypes (sic!) and script.aculo.us) mostly use it like a class based system. So the first thing to notice is that the Smalltalk object hierarchy does not necessarily reflect the structure of the code on the JavaScript side. For example there were some conflicts in SUAjax and SUAutocompleter, where some Smalltalk objects understand messages they shouldn't. I guess this is not really a problem, and if necessary it could be cleanly solved using some well known technique that should not be mentioned in the Seaside mailing-list ;-) Apart from that the integration was strait forward. Every JavaScript method has a Smalltalk equivalent + some Smalltalk glue code. I added a lot of unit tests to make sure the transformation works as I expected. Also nice is to have a functional test suite that makes sure that the JavaScript code works as expected and, at the same time, serves as an example for users of the library. > To be honest I'm interested in a couple of widgets of the dojo > javascript toolkit but I don't want to mess arround until I get it, so if I > want to "map" a smalltalkish access to them into Squeak for instance, which > should be my starting point? how the normal cycle of development should be > (I mean debugging things that are not in st debugger, javascript tutorials > that are good to smalltalkers, etc)? I would just start with something simple that works and then refine it on the go. I am sure that you can take some ideas from Scriptaculous and maybe even build on top of it reusing its serialization scheme. The JavaScript debugger is FireBug (www.getfirebug.com). Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Using javascript toolkits for smalltalkers
|
|
Lukas,
thanks for writing. Interesting indeed. I've imagined the smalltalk object would not be matching 1:1 the javascript ones but I have no clue of what technique is that for solving conflicts you've mention. It is well know in which domain? Javascript developers? If I understood well scriptaculous smalltalk framework is about objects that once configured they know how to print them as javascript code. This is the serialization you are talking about right? cheers, Sebastian Sastre > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En nombre > de Lukas Renggli > Enviado el: Lunes, 14 de Mayo de 2007 03:20 > Para: Seaside - general discussion > Asunto: Re: [Seaside] Using javascript toolkits for smalltalkers > > Hi Sebastian, > > > I, as a lot of people, are using the excellent job you > made "mapping" > > Scriptaculous to enjoy javascript smalltalkishly. As you > where able to > > make such a thing I wanted to ask what is your opinion about the > > starting point of such kind of work for other toolkits for > > smalltalkers. I mean, I have some years on smalltalk and > I'm a newbie > > in javascript and I want to have an idea of what to expect of the > > development in the formula > > smalltalk+javascript. I know results are great, but I want to > > smalltalk+understand > > more deeply the "path" to them. > > first I must say that the Scriptaculous package is not > entirely my own work, Avi started it all back in June 2005. > In the beginning there was just basic AJAX functionality and > some effects. The evolution of Scriptaculous was a highly > iterative process. While I tried to add more functionality, > and eventually supported all the things available trough > JavaScript, I also had to rethink and redesign the the > Smalltalk object model several times to accomodate new needs. > > The most difficult thing was that JavaScript is a prototype > based language, even though most libraries (including > prototypes (sic!) and > script.aculo.us) mostly use it like a class based system. So > the first thing to notice is that the Smalltalk object > hierarchy does not necessarily reflect the structure of the > code on the JavaScript side. > For example there were some conflicts in SUAjax and > SUAutocompleter, where some Smalltalk objects understand > messages they shouldn't. I guess this is not really a > problem, and if necessary it could be cleanly solved using > some well known technique that should not be mentioned in the > Seaside mailing-list ;-) > > Apart from that the integration was strait forward. Every > JavaScript method has a Smalltalk equivalent + some Smalltalk > glue code. I added a lot of unit tests to make sure the > transformation works as I expected. Also nice is to have a > functional test suite that makes sure that the JavaScript > code works as expected and, at the same time, serves as an > example for users of the library. > > > To be honest I'm interested in a couple of widgets of the dojo > > javascript toolkit but I don't want to mess arround until I > get it, so > > if I want to "map" a smalltalkish access to them into Squeak for > > instance, which should be my starting point? how the normal > cycle of > > development should be (I mean debugging things that are not in st > > debugger, javascript tutorials that are good to smalltalkers, etc)? > > I would just start with something simple that works and then > refine it on the go. I am sure that you can take some ideas > from Scriptaculous and maybe even build on top of it reusing > its serialization scheme. > > The JavaScript debugger is FireBug (www.getfirebug.com). > > Cheers, > Lukas > > -- > Lukas Renggli > http://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 |
Re: Using javascript toolkits for smalltalkers
|
|
> I've imagined the smalltalk object would not be matching 1:1 the
> javascript ones but I have no clue of what technique is that for solving > conflicts you've mention. It is well know in which domain? Javascript > developers? Well, in JavaScript you can copy groups of methods around and introduce them into different classes/prototypes. Most JavaScript frameworks I've seen make use of that to some extend. Unfortunately Smalltalk doesn't have such a thing, unless you use Traits. > If I understood well scriptaculous smalltalk framework is about > objects that once configured they know how to print them as javascript code. > This is the serialization you are talking about right? Exactly. This works well because the life-time of a JavaScript object is only up to the next full page request. In the general case it is not useful to keep the Scriptaculous objects as state in your application. It is just a way to generate the JavaScript programmatically, such as the canvas framework generates XHTML. Diego Gómez made a framework that generates JavaScript code from Smalltalk classes and methods by using a similar technique as the Squeak VM-Maker. Like this you can build a whole object hierarchy in Smalltalk and run it either in the Smalltalk VM or transform the code to JavaScript and run it in the Web Browser. I don't know how well this works integrating existing JavaScript code. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Using javascript toolkits for smalltalkers
|
|
In reply to this post by Lukas Renggli
Lukas Renggli wrote:
> I > guess this is not really a problem, and if necessary it could be > cleanly solved using some well known technique that should not be > mentioned in the Seaside mailing-list ;-) Do you mean traits, or are you talking about something like Self? I wouldn't think either of these should be a curse word on this list. _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Using javascript toolkits for smalltalkers
|
|
2007/5/20, Jason Johnson <[hidden email]>:
> Lukas Renggli wrote: > > I > > guess this is not really a problem, and if necessary it could be > > cleanly solved using some well known technique that should not be > > mentioned in the Seaside mailing-list ;-) > > Do you mean traits, or are you talking about something like Self? I > wouldn't think either of these should be a curse word on this list. Read the: Seaside, Traits, portability Question about WASelectTag class hierarchy... threads/threats. Cheers Philippe > _______________________________________________ > 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 |
Re: Using javascript toolkits for smalltalkers
|
|
Philippe Marschall wrote:
> Read the: > Seaside, Traits, portability > Question about WASelectTag class hierarchy... > threads/threats. Ah right, I get it. Thanks. :) _______________________________________________ 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 |