non-blocking call:

Hi,

call: should be blocking, right? Does it block under
any circumstances? I have a component where the call:
is non-blocking. It just executes the statement after
the call: immediately.

I'm using Seaside 2.7b1

Do I understand something wrong?

thanks,

Norbert

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

2007/7/8, Norbert Hartl <[hidden email]>:
> Hi,
>
> call: should be blocking, right?

Yes.

> Does it block under
> any circumstances?

No.

> I have a component where the call:
> is non-blocking. It just executes the statement after
> the call: immediately.

One place where it doesn't block (and doesn't work) is in #initialRequest:

> I'm using Seaside 2.7b1
>
> Do I understand something wrong?

We need more info and code.

Philippe

> thanks,
>
> Norbert
>
> _______________________________________________
> 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

On Sun, 2007-07-08 at 20:39 +0200, Philippe Marschall wrote: Ok, that's the point. It is code invoked from initialRequest:

Good to know. So this is only working inside the render loop, right?
So I have to find a way to setup the components in initialRequest:
and let them be display inside the render loop.

thanks,

Norbert

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

2007/7/8, Norbert Hartl <[hidden email]>:
Yes.

> So I have to find a way to setup the components in initialRequest:
> and let them be display inside the render loop.

The usual trick is to use a WATask and do the #call: there in #go. You
have just found one of the weaker points of Seaside REST support. This
might be something for 2.9.

Philippe

> thanks,
>
> Norbert
>
> _______________________________________________
> 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

> > Good to know. So this is only working inside the render loop, right?
>
> Yes.

I would rather say from within callbacks or WATask>>#go (which is
internally implemented as a callback).

> > So I have to find a way to setup the components in initialRequest:
> > and let them be display inside the render loop.

The question is, if you really want it to block in #initialRequest:?
That could have very strange side-effects where some components
already received #initialRequest: while others didn't.

> The usual trick is to use a WATask and do the #call: there in #go. You
> have just found one of the weaker points of Seaside REST support. This
> might be something for 2.9.

I don't see a problem there. Use #show: in these cases, to make the
non-blocking behavior explicit.

Lukas

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

On Sun, 2007-07-08 at 21:58 +0200, Lukas Renggli wrote:
> > > Good to know. So this is only working inside the render loop, right?
> >
> > Yes.
>
> I would rather say from within callbacks or WATask>>#go (which is
> internally implemented as a callback).
>
For me the action stays the same. I'll have to setup things right
in initialRequest: and let them do everything while being rendered.
I see no difference here between WAComponent and WATask if you
depend on blocking behaviour.

> > > So I have to find a way to setup the components in initialRequest:
> > > and let them be display inside the render loop.
>

> The question is, if you really want it to block in #initialRequest:?
> That could have very strange side-effects where some components
> already received #initialRequest: while others didn't.
>
Yes, I total agree. I've just never thought of it before discovering
this :) My "Actions" are litlle state machines anyway. So no problem
just another set up. Or rely on WATask. I'll have to think about
it.

> > The usual trick is to use a WATask and do the #call: there in #go. You
> > have just found one of the weaker points of Seaside REST support. This
> > might be something for 2.9.
>
> I don't see a problem there. Use #show: in these cases, to make the
> non-blocking behavior explicit.
>
But I want to have a blocking behaviour. I should thought of WATask
before.

thanks,

Norbert

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

On Sun, 2007-07-08 at 21:58 +0200, Lukas Renggli wrote: Now I got it. It is even better than before. I have a WATask which
delegates the action to my Action classes. I do a show: aTask in
initialRequest: and in go the delegation occurrs. And it seems it
solves also one or two of my other problems.

thanks to both of you. You do a great job!

Norbert

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