autocomplete

have you successfully used an autocomplete from amber?

When I execute this:

I get chrome using 99% CPU to no end

That code is part of what's needed to get it working.

Js example here:

http://jqueryui.com/demos/autocomplete/#remote-jsonp

any idea?

sebastian

Hi,
 

This implementation replaces HashedCollection literals with the new syntax,
but it's certainly possible to have both side by side. Although I don't know what
HashedCollections offer that js objects don't. On the other hand, there is a
need to create "pure" js objects as Sebastian's example shows.
I didn't notice any side effects yet. Amber works great :)

cheers, Balázs

p.s: The ajax call above could be rewritten like this:

jQuery ajax: #{
    url: 'http://ws.geonames.org/searchJSON'.
    dataType: 'jsonp'.
    data: #{
        featureClass: 'P'.
        style: 'full'.
        maxRows: 12.
        'name_startsWith': 'foz'}.
    success: [:d | console log: d ] }

ok.

I've merged your stuff with Nicolas edge version.

It's looking really good!

you guys rock!

Em segunda-feira, 28 de maio de 2012 13h31min01s UTC-3, Balázs escreveu:

Hi,
 

Did you try to fully replace HashedCollection literals with your
implementation? Any side effect?

This implementation replaces HashedCollection literals with the new syntax,
but it's certainly possible to have both side by side. Although I don't know what
HashedCollections offer that js objects don't. On the other hand, there is a
need to create "pure" js objects as Sebastian's example shows.
I didn't notice any side effects yet. Amber works great :)

cheers, Balázs

p.s: The ajax call above could be rewritten like this:

jQuery ajax: #{
    url: 'http://ws.geonames.org/searchJSON'.
    dataType: 'jsonp'.
    data: #{
        featureClass: 'P'.
        style: 'full'.
        maxRows: 12.
        'name_startsWith': 'foz'}.
    success: [:d | console log: d ] }

You're right. I tried the example with the latest amber from the repo, and it works,
and indeed HashedCollection has only its keys as enumerable properties, and
other smalltalk objects only their inst vars. I guess this is the relevant code:
https://github.com/NicolasPetton/amber/blob/master/js/boot.js#L145

That means that the main reason for my change is gone. There are two other
aspects to consider:

1) Syntax:

   #{ a: 1 }
   #{ 'a' -> 1 }

I think pros for the new syntax is, that it's "lighter" and resembles the js object literal syntax.

Pros for the old syntax is that it's a bit more flexible. You can write:
   k := 'foo'. #{ k -> 1 }
or even
   a := 'foo' -> 1. #{ a }

2) Performance:

n := 100000.
{
    [ #{ 'a' -> 1. 'b' -> 1. 'c' -> 1 } ].
    [ HashedCollection new at: 'a' put: 1; at: 'b' put: 1; at: 'c' put: 1; yourself ].
    [ #{ a: 1. b: 1. c: 1 } ].
    [ ] } collect: [ :each | [ n timesRepeat: each ] timeToRun ]  " #(3705 894 130 157) "

Clearly there is some optimisation to be done with the old implementation.

I like the new syntax more, and I think we should contemplate about the relation
between HashedCollection and JSObjectProxy a bit. What do you think?

cheers, Balázs

a) the interface is not well defined for st and could be wrapped (for instance calling "ajax" function should really be a matter of creating an ajax object which you set the properties on via cascade and then a send message) 

AjaxWrapper new

 Hi!

I think it's not probable that other smalltalks will consider this syntax change.

Because as Bert writes [1]:

I see no reason for trying to partly mimic JSON in Squeak.

For one, you can always use

{#foo -> 1. #bar -> 42} as: Dictionary.

and because as shaunxcode writes:

but the more I get into the amber/smalltalk mindset the more I do not miss the ability to rapidly define/pass along anonymous objects.

You don't use dictionaries this way in smalltalk (*), so I
don't think the dynamic dictionary syntax will catch on
in other dialects.

On the other hand I don't agree with shaunxcode, we shouldn't write wrapper code
for all the js libraries out there, the more seamless the integration is, the faster
you can start using them. (**).

All in all, I don't think that the syntax for defining js objects will have any effect
on portability, but it's essential for good interfacing with the js world. IMHO
{ 'a' -> 1 } is a few more keystrokes, and clutter on the screen compared to
{ a: 1 }, but probably I will go with the official version.

cheers, Balázs

[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-May/164039.html

(*) When I do, I'm generating javascript code/interfacing javascript libs.
I usually write code that goes something like this:

jQuery ajax: [ :ajax |
    ajax
        url: 'http://ws.geonames.org/searchJSON';
        dataType: 'jsonp';
        data: [ :data |
            data
                featureClass: 'P';
                style: 'full';
                maxRows: 12;
                at: 'name_startsWith' put: 'foz' ];
        success: [ :d | console log: d ] asJsFunction ]

where the ajax block arg is a JSObject containing an OrderedCollection
of key-value pairs, with an appropriately implemented dnu, which
fills the collection, and creates new JSObjects upon receiving blocks.
The benefit of this pattern that you can do calculations, and fill the objects
conditionally in the blocks.

(**) I try to use amber with dojo, and have code like this:

Application >> initializeLayout

    self
        require: #('dijit/layout/BorderContainer')
        do: [ :dBorderContainer |
            layout := dBorderContainer newValue: #{
                id: 'appLayout'.
                design: 'sidebar'.
                gutters: true.
                liveSplitters: true }.
            self
                initializeCenterPane;
                initializeSidebar.
            document body appendChild: layout domNode.
            layout startup ]