Callback error into GLASS based Seaside3.0

Hi,

        i have a problem with callback: into GLASS.

        For test it i update the WACounter with:


A) renderContentOn: html

        html heading: count.
        html anchor
                callback: [ self increase ];
                with: '++'.
        html space.
        html anchor
                callback: [ self decrease ];
                with: '--'.
               
        self renderBatchOn: html


B) renderBatchOn: html

        " rendering button or anchor for...... "
       
html form: [
                1 to: 10 do: [ :index |
                       
                                html "submitButton" anchor
                                        callback: [ count:= count + index];
                                        text: (  '+',  index asString ).
                                html space.
                                                ].
                ]


Now when i click on a specific anchor the counter is update always of +10.


The same code into Pharo image work fine.

Thanks,

        Dario

Dario,

You are running into a bug in the way that GemStone deals with block
temporaries. This bug will probably not be fixed in 2.x, but should be
fixed in 3.0.

If you compare WALotsaLinksFunctionalTest and
WALotsaLinksGemStoneFunctionalTest, you will see that you need to use a
method to return a block for each value of the index.

In you example you'd do something like this

renderBatchOn: html
   html form: [
     1 to: 10 do: [ :index |
       html "submitButton" anchor
         callback: (self callbackBlockFor: index);
         text: (  '+',  index asString ).
       html space.
     ].

callbackBlockFor: index
   ^[ count:= count + index]

Dale

Dario Trussardi wrote:

Thanks Dale,

if there is , where i can found  description for some other 'trick' into GLASS ?

        Dario

Dario Trussardi wrote:
> Thanks Dale,
>
> if there is , where i can found  description for some other 'trick' into GLASS ?

I'm not exactly sure what 'trick' you are referring too. You can look at
the glassdb issue list to see the reported bugs (this particular bug was
reported internally and didn't make it into glassdb).

As far as I know this is the only place where we (knowingly) depart from
ANSI behavior and don't intend to fix the problem in 2.x

Dale