self request from renderContentOn

Hi,

I don't understand why the following doesn't work:

renderContentOn: html
    html heading: (self request: 'Enter a title')

I've got it working a little more circuitously (using an anchor with a
callback to set an instance variable), but I don't understand the
error that I get with the above:

MessageNotUnderstood: UndefinedObject>>isGet

UndefinedObject(Object)>>doesNotUnderstand: #isGet
self nil
temps
aMessage isGet

...

Anyone got some pointers?

Cheers,

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

See http://onsmalltalk.com/programming/smalltalk/terse-guide-to-seaside/

Specifically points 1 and two from "A few things to keep in mind"

1. Don't put logic in render methods, a render method should be able to be
called many times without adversely affecting the component

2. Don't call components directly from the render methods of other
components, always make sure any calls are inside #callback: blocks, this
bites every newbie

You're violating both.  Try this instead...

renderContentOn: html
    self someHeading
        ifNil:[html anchor
                    callback:[self someHeading:
                        (self request: 'Enter a title')]
                    with: 'Enter a title']
        ifNotNil:[html heading: self someHeading]

self request: calls another component, you cannot do this outside the
context of a callback block unless you are in a WATask which has no UI of
its own.

Ramon Leon
http://onsmalltalk.com

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

Thanks for the tips. I still don't fully get it, though.

> 2. Don't call components directly from the render methods of other
> components, always make sure any calls are inside #callback: blocks, this
> bites every newbie

Is there any way around this restriction? Or is it for exactly this
purpose that tasks were invented? Say it was necessary, for whatever
reason, that control flow was [request user's name] -> [display the
name], with no explicit action required to begin the process -- is
subclassing WATask the best (only?) way to do it?
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 4/25/07, Patrick Collison <[hidden email]> wrote:
> Thanks for the tips. I still don't fully get it, though.
>
> > 2. Don't call components directly from the render methods of other
> > components, always make sure any calls are inside #callback: blocks, this
> > bites every newbie
>
> Is there any way around this restriction? Or is it for exactly this
> purpose that tasks were invented?

Yes, it's for that purpose.

> Say it was necessary, for whatever
> reason, that control flow was [request user's name] -> [display the
> name], with no explicit action required to begin the process -- is
> subclassing WATask the best (only?) way to do it?

Certainly the best way, though probably not the only one :)

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

> > Is there any way around this restriction? Or is it for exactly this
> > purpose that tasks were invented?
>
> Yes, it's for that purpose.

Ok, cool.

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