This might be trivial but it gives me headache:
In my application I have simple layout: table with one vertical strip with component called 'helper' and the rest with comp. 'body'. This helper is first set to LoginClass which handles login process and when it succeeds it does: self jumpToPage: MenuClass new. Then there's menu that in fact control the body component and provides logout action which in turn does self: jumpToPage: LoginClass new. Everything works great.
Now I want to synchronize the body. That is when helper swaps then body needs go to home, like by code: self children at 'body' jumpToPage: MainClass new. What I'm thinking about now is do everything what IAComponent>>jumpToPage: does except that continuation. Is this safe?
On Sun, 24 Mar 2002, Kamil Kukura wrote:
Now I want to synchronize the body. That is when helper swaps then body needs go to home, like by code: self children at 'body' jumpToPage: MainClass new. What I'm thinking about now is do everything what IAComponent>>jumpToPage: does except that continuation. Is this safe?
I'm not entirely sure what you're asking. I think what you're saying is that you have a structure like this:
Top ----------- | | | | Menu Body
And you want an action in the menu to control the body, right? In which case something like
(parent children at: 'body') jumpToPage: ...
would work, and yes, would be safe. But I don't have any idea what you mean by "everything what IAComponent>>jumpToPage: does except that continuation". Can you elaborate?
By the way, a useful pattern for menus/navbars might be to give them a "target" instance variable, and to bind it from the parent, ie,
addBindingsTo: template (template elementNamed: 'menu') set: #target toPath: 'children.body'
And then the code in the menu can simply look like
target jumpToPage: ...
and the navbar can be more reusable. Hmm, you may run into problems with the order in which subcomponents get created, here...
Anyway, does any of this answer your question?
Avi
Top
| | | | Menu Body
And you want an action in the menu to control the body, right? In which case something like
(parent children at: 'body') jumpToPage: ...
would work, and yes, would be safe.
Yes and that works for me perfectly. Now in this moment, let's say we want to change menu to something different like special sub-menu. So one could write:
(parent children at: 'body') jumpToPage: ... self jumpToPage: ...
But the second jump won't be reached.
On Mon, 25 Mar 2002, Kamil Kukura wrote:
(parent children at: 'body') jumpToPage: ... self jumpToPage: ...
But the second jump won't be reached.
Oh, I see. Now I understand what you mean by "without the continuation". So what you want is
parent children at: 'body' put: ... self jumpToPage: ...
except with the extra setup that IAComponent>>jumpToPage: does. So perhaps we should factor that logic out into childAt:put:, eg
IAPage>>childAt: aKey put: aComponent
aComponent parent: self; id: aKey; session: session. ^ children at: aKey put: aComponent.
IAComponent>>jumpToPage: aPage
parent ifNil: [super jumpToPage: page] ifNotNil: [parent childAt: id put: page. super jumpToPage: self root]
And then your code would become:
parent childAt: 'body' put: ... self jumpToPage: ...
That's what you were thinking, right? Seems fine to me. I guess the only thing is that if you're switching every component on the page at once, why isn't this just
parent jumpToPage: LoggedOutClass
or some such? But I don't see offhand why the facility shouldn't exist for those that really want it.
Avi
Oh, I see. Now I understand what you mean by "without the continuation". So what you want is
parent children at: 'body' put: ... self jumpToPage: ...
except with the extra setup that IAComponent>>jumpToPage: does. So perhaps we should factor that logic out into childAt:put:, eg
IAPage>>childAt: aKey put: aComponent
aComponent parent: self; id: aKey; session: session. ^ children at: aKey put: aComponent.
OK, I got it. I've built close to it a method called turnToPage: which is all of jumpToPage: except sending session the continueWithPage: aPage message. It works okay, but, could you explain what makes it different?. That is, what IASession>>continueWithPage: self root does? I didn't explore it so deep so I only guess it handles #aboutToView logic and other things.
TIA,
On Tue, 26 Mar 2002, Kamil Kukura wrote:
OK, I got it. I've built close to it a method called turnToPage: which is all of jumpToPage: except sending session the continueWithPage: aPage message. It works okay, but, could you explain what makes it different?. That is, what IASession>>continueWithPage: self root does? I didn't explore it so deep so I only guess it handles #aboutToView logic and other things.
No, the crucial line is this one: "currentContinuation value: page". This is basically a non-local return to IASession>>act: - it breaks out of the current thread of execution and returns the nextPage, which the session then displays. That's why nothing after a jumpToPage: ever gets called. When you use callPage:, the current context is saved (with callCC) before doing the jump, so it can be resumed later on.
seaside@lists.squeakfoundation.org
-
Avi Bryant -
Kamil Kukura