Generated links (anchor -> callback)

Hi seaside list!

I'm roughly new in developing seaside. Trying out some seaside development.

I'm using:
GemStone/S 64 Bit
2.3.1 Build: gss64_2_3_x_branch-20643
Thu Dec  4 11:33:32 2008

with GemTools 2.3.1

I would like create links on my page - with generated URLS, which have the
value of the index from render time.

I try by using something like this:

initialize
        super initialize.
        self value: 0

renderContentOn: canvas

canvas text: self value.

   1 to: 10 do: [ :index |
       canvas anchor
          callback:[ self value: index  ];
                 with: index.
       html space ].

-> The value is everytime clicking on a link '10' - which I would
understand, if i didn't read the tutorial on the seaside.st site:

-----snip -----
renderContentOn: html
   1 to: 10 do: [ :index |
       html anchor
          callback: [ index inspect ];
          with: index.
       html space ]

It will generate a series of links, labelled from 1 to 10. Because the
action blocks capture the current value of the i variable, each one will
have a distinct callback: clicking on the "1" link will evaluate 1
inspect, on the "2" link will evaluate 2 inspect, and so on. The block
closure is being used to maintain all of the interesting state for the
link.
-----snap-----

Please, can somebody help me out finding my mistake?

Best regards

Mark


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

Mark,

You've tripped over a block bug in GemStone. In GemStone the temp variable in the block (index) is shared across block invocations, so the value that the block was called with is not preserved when the callback is invoked.

There's a workaround, but I'm at the beach and don't have ready access to a stone (and I don't recall the details), so perhaps James Foster (or another GemStoner) can chime in...

Dale

----- "Mark Ross" <[hidden email]> wrote:

| Hi seaside list!
|
| I'm roughly new in developing seaside. Trying out some seaside
| development.
|
| I'm using:
| GemStone/S 64 Bit
| 2.3.1 Build: gss64_2_3_x_branch-20643
| Thu Dec  4 11:33:32 2008
|
| with GemTools 2.3.1
|
| I would like create links on my page - with generated URLS, which have
| the
| value of the index from render time.
|
| I try by using something like this:
|
| initialize
|         super initialize.
|         self value: 0
|
| renderContentOn: canvas
|
| canvas text: self value.
|
|    1 to: 10 do: [ :index |
|        canvas anchor
|           callback:[ self value: index  ];
|                  with: index.
|        html space ].
|
| -> The value is everytime clicking on a link '10' - which I would
| understand, if i didn't read the tutorial on the seaside.st site:
|
| -----snip -----
| renderContentOn: html
|    1 to: 10 do: [ :index |
|        html anchor
|           callback: [ index inspect ];
|           with: index.
|        html space ]
|
| It will generate a series of links, labelled from 1 to 10. Because
| the
| action blocks capture the current value of the i variable, each one
| will
| have a distinct callback: clicking on the "1" link will evaluate 1
| inspect, on the "2" link will evaluate 2 inspect, and so on. The
| block
| closure is being used to maintain all of the interesting state for
| the
| link.
| -----snap-----
|
| Please, can somebody help me out finding my mistake?
|
| Best regards
|
| Mark
|
|
| _______________________________________________
| 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

Hi Mark,

As Dale mentioned, GemStone doesn't quite handle the block the way you  
expect. The workaround is to help the compiler see that this is really  
a new context. I generally do this with a new method:

renderContentOn: canvas

        1 to: 10 do: [:index | self renderIndex: index on: canvas].
%
renderIndex: anInteger on: aCanvas

        aCanvas anchor
                callback: [self value: anInteger];
                with: anInteger.
        aCanvas space.
%

Because the refactoring tends to give smaller, better named methods, I  
generally don't find this GemStone "bug" to be much of a burden.

James

On Jul 5, 2009, at 4:14 PM, Mark Ross wrote:

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

Hm.. this sounds exactly like the lack of full block closures in
Squeak. I was unaware that Gemstone had a similar problem.

Could it not be fixed in Gemstone with an implementation of
#fixCallbackTemps similar to the one in Squeak?

Julian

On Mon, Jul 6, 2009 at 3:44 AM, James Foster<[hidden email]> wrote: _______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Am 2009-07-06 um 09:32 schrieb Julian Fitzell:

> Hm.. this sounds exactly like the lack of full block closures in
> Squeak. I was unaware that Gemstone had a similar problem.
>
> Could it not be fixed in Gemstone with an implementation of
> #fixCallbackTemps similar to the one in Squeak?

That’s what I thought, too. However, as far as I know, the recent
Squeak VM(s) come with full Block closures (recent image with
NewCompiler necessary, too). Would #fixCallbackTemps  be an
empty method there?

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

> That’s what I thought, too. However, as far as I know, the recent
> Squeak VM(s) come with full Block closures (recent image with
> NewCompiler necessary, too). Would #fixCallbackTemps  be an
> empty method there?

Yes, #fixCallbackTemps is a no-op in Smalltalk implementations with
true closures. These are recent Pharo images that have closures, not
Squeak. The NewCompiler provides closures too, but block activations
get significantly slower.

Lukas


>
> So Long,
>         -Tobias

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

Am 2009-07-06 um 10:47 schrieb Lukas Renggli:

>> That’s what I thought, too. However, as far as I know, the recent
>> Squeak VM(s) come with full Block closures (recent image with
>> NewCompiler necessary, too). Would #fixCallbackTemps  be an
>> empty method there?
>
> Yes, #fixCallbackTemps is a no-op in Smalltalk implementations with
> true closures. These are recent Pharo images that have closures, not
> Squeak.

I doubt that last claim, in case you wanted to point out that true  
closures
are not available in Squeak.

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

On Jul 6, 2009, at 10:54 AM, Tobias Pape wrote:

Why do you say that since what lukas is saying is true!
Pharo has full block closure support since a couple of months.

Stef

>
> So Long,
> -Tobias_______________________________________________
> 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

Hello,

Am 2009-07-06 um 11:05 schrieb stephane ducasse:

> Why do you say that since what lukas is saying is true!
> Pharo has full block closure support since a couple of months.

I did _not_ say that Pharo _hasn’t_ block closures.
I _did_ say that Squeak _has_ block closurest, which was what lukas  
seemed to deny.

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

2009/7/6 Tobias Pape <[hidden email]>:
By default Squeak doesn't have block closures. You can load and use
the ClosureCompiler but that comes at a runtime and compietime cost.

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

Julian,

I don't think this is related to fixBlockTemps - We're compliant with the ANSI spec except for this particular bug (and in 3.0 the bug will be fixed).

The problem is that the block has 'lost' the value of the temp variable - the slot is shared across all block invocations, so I don't think there is a simple solution, other than a workaround similar to what James suggested.

Fixing this bug would involve some major surgery on the block implementation, so we've been reluctant to fix it in 2.x.

Dale

----- "Julian Fitzell" <[hidden email]> wrote:

| Hm.. this sounds exactly like the lack of full block closures in
| Squeak. I was unaware that Gemstone had a similar problem.
|
| Could it not be fixed in Gemstone with an implementation of
| #fixCallbackTemps similar to the one in Squeak?
|
| Julian
|
| On Mon, Jul 6, 2009 at 3:44 AM, James Foster<[hidden email]>
| wrote:
| > Hi Mark,
| >
| > As Dale mentioned, GemStone doesn't quite handle the block the way
| you
| > expect. The workaround is to help the compiler see that this is
| really a new
| > context. I generally do this with a new method:
| >
| > renderContentOn: canvas
| >
| >        1 to: 10 do: [:index | self renderIndex: index on: canvas].
| > %
| > renderIndex: anInteger on: aCanvas
| >
| >        aCanvas anchor
| >                callback: [self value: anInteger];
| >                with: anInteger.
| >        aCanvas space.
| > %
| >
| > Because the refactoring tends to give smaller, better named methods,
| I
| > generally don't find this GemStone "bug" to be much of a burden.
| >
| > James
| >
| > On Jul 5, 2009, at 4:14 PM, Mark Ross wrote:
| >
| >> Hi seaside list!
| >>
| >> I'm roughly new in developing seaside. Trying out some seaside
| >> development.
| >>
| >> I'm using:
| >> GemStone/S 64 Bit
| >> 2.3.1 Build: gss64_2_3_x_branch-20643
| >> Thu Dec  4 11:33:32 2008
| >>
| >> with GemTools 2.3.1
| >>
| >> I would like create links on my page - with generated URLS, which
| have the
| >> value of the index from render time.
| >>
| >> I try by using something like this:
| >>
| >> initialize
| >>       super initialize.
| >>       self value: 0
| >>
| >> renderContentOn: canvas
| >>
| >> canvas text: self value.
| >>
| >>  1 to: 10 do: [ :index |
| >>      canvas anchor
| >>         callback:[ self value: index  ];
| >>                with: index.
| >>      html space ].
| >>
| >> -> The value is everytime clicking on a link '10' - which I would
| >> understand, if i didn't read the tutorial on the seaside.st site:
| >>
| >> -----snip -----
| >> renderContentOn: html
| >>  1 to: 10 do: [ :index |
| >>      html anchor
| >>         callback: [ index inspect ];
| >>         with: index.
| >>      html space ]
| >>
| >> It will generate a series of links, labelled from 1 to 10. Because
| the
| >> action blocks capture the current value of the i variable, each one
| will
| >> have a distinct callback: clicking on the "1" link will evaluate 1
| >> inspect, on the "2" link will evaluate 2 inspect, and so on. The
| block
| >> closure is being used to maintain all of the interesting state for
| the
| >> link.
| >> -----snap-----
| >>
| >> Please, can somebody help me out finding my mistake?
| >>
| >> Best regards
| >>
| >> Mark
| >>
| >>
| >> _______________________________________________
| >> 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
| >
| _______________________________________________
| 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

I have a layout structure that looks roughly like this:

Root
    renderContentOn: html
        html render: self content. "MainPage new"

MainPage
    renderContentOn: html
        html render: self map. "Map new"

Map
    renderContentOn: html
        html render: self content. "Area new"

Area
    renderContentOn: html
        "stuff"

I also have an announcement on 'Map' that changes the content to, say, "Province new".

Hitting a link with a callback, ie.: "self session announce: (TOCAnnounceChangeMap on: TOCProvince new)" still renders the original initialized component ("Area new").

Am I correct in deducing that when the page is reloaded it creates a new instance of "Map" and therefore does not render what was saved in the 'content' variable? If so, can I use jQuery to do this with announcements? And, how would that look?

Thanks,
RS

---

Lauren found her dream laptop. Find the PC that’s right for you.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>>>>> "Robert" == Robert Sirois <[hidden email]> writes:

Robert> Am I correct in deducing that when the page is reloaded it creates a
Robert> new instance of "Map" and therefore does not render what was saved in
Robert> the 'content' variable? If so, can I use jQuery to do this with
Robert> announcements? And, how would that look?

In general, you don't want to be creating new children on each render.
The callbacks won't work.

Instead, lazily initialize them as instance vars of the enclosing
component.  And don't forget to announce them in #children!

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Are there any resources (besides the tests and classes) on jQuery specifically for Seaside/Smalltalk out there? I'll admit I'm having a hard time learning these classes for some reason.

Thanks,
RS

---

Windows Live™ SkyDrive™: Get 25 GB of free online storage. Get it on your BlackBerry or iPhone.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I suggest that you read the original JQuery and JQueryUI
documentation. Seaside just wraps around the original Javascript
functionality, apart from the syntax there is no big difference. The
original documentation is also linked from the functional tests, as
you might have noticed.

Lukas

2009/7/7 Robert Sirois <[hidden email]>:


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

When I go to serialize a form element, can I do that with a component method, or does everything have to be written to iVars first?

RS

---

Bing™ brings you health information from trusted sources. Try it now.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Normally you combine the serialization with an ajax request that
triggers the callbacks of the form fields, have a look at
JQFormFunctionalTest for examples.

Cheers,
Lukas

2009/7/10 Robert Sirois <[hidden email]>:


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

Blah.. I've looked at those tests for hours. They drive me crazy heh. I only kind of understand what they are doing, but the way those tests work and the stuff I'm trying to do is somewhat dissimilar.

I have this:

    onClick: (html jQuery ajax script: [:script |
        script add: (script jQuery: (self clickFunctionNext: html))
    ]
    );

which goes ahead and runs a method, returning some jQuery that shows and hides elements, as well as updating some class instance variables.

The problem I am having is doing radio buttons, check boxes, etc. for form serialization/validation. I'm not sure how: "find:':input'" works. Does it just go through and pick every input item on the page and serialize it?

RS

---

Windows Live™ Hotmail®: Spread the word when you add celeb photos to your e-mails. Check it out.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> The problem I am having is doing radio buttons, check boxes, etc. for form
> serialization/validation. I'm not sure how: "find:':input'" works. Does it
> just go through and pick every input item on the page and serialize it?

Have a look at some of the JQuery documentation and tutorials at:

    http://docs.jquery.com/Main_Page
    http://docs.jquery.com/Tutorials

For example:

#find: searches for descendent elements that match the specified expression:

    http://docs.jquery.com/Traversing/find#expr

':input' matches all input, textarea, select and button elements:

     http://docs.jquery.com/Selectors/input

>     onClick: (html jQuery ajax script: [:script |
>         script add: (script jQuery: (self clickFunctionNext: html))
>     ]
>     );

To serialize all form elements on the complete page whenever this
onClick handler is triggered you could write the following:

onClick: (html jQuery ajax
    serialize: (html jQuery: ':input');
    script: [:script | script add: (script jQuery: (self
clickFunctionNext: html)) ])

Cheers,
Lukas

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

Hi James,
Sorry for replying a month later - I had a bad accident with my
push-bike.

Thanks for the hint - this seems to be a very convenient and in a
propgramming manner clear way to implement the links :)

Best regards

Mark



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