Un-calling components

In our application, we have sidebar and main content components that
are rendered side-by-side. A kinda awkward issue arises when the main
component #call's another -- if the user selects a link in the
sidebar, any changes the sidebar makes to the view state of the main
component aren't seen by the user (the main component is still
decorated, and so the #call'ed component is rendered).

To solve it, we added a decoration to the sidebar component, with the
following method:

processChildCallbacks: aStream
        "If the user clicks on a link in the sidebar, un-#call the main
content component if it has been #call'ed"
        (aStream callbacks contents anySatisfy: [:callback |
                (aStream request fields includesKey: callback key)
                        and: [callback owner = self owner]])
                ifTrue: [
                        | dec |
                        dec := self owner parent decoration.
                        dec isDecoration ifTrue: [dec remove]].
        ^ super processChildCallbacks: aStream

We also had to add #callbacks and #request methods to
WACallbackStream. (Note that we don't want the callee to #answer: --
we just ignore the fact that it was ever called in the first place.)

I'm curious as to whether there's a better way of doing what we're
trying to accomplish? Or has anyone else ever needed something along
these lines?
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I believe you can simply tell any component #home to remove all decorations.
Your sidebar could just do its thing and then call main home.  Maybe I
misunderstand your intentions?

Ramon Leon
http://onsmalltalk.com

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

On 22/08/07, Ramon Leon <[hidden email]> wrote:
> I believe you can simply tell any component #home to remove all decorations.
> Your sidebar could just do its thing and then call main home.  Maybe I
> misunderstand your intentions?

Ah, thanks, I hadn't discovered #home. I don't think this makes the
first part of the method redundant, though -- we only remove the
delegates if the user actually clicked a link in the sidebar. Maybe
there's also a clean way of doing this?
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Well, it depends on if your sidebar has direct access to the main component
or not.  If so, then just directly

SideBar>>renderContentOn: html
    html anchor on: #someAction of: self

SideBar>>someAction
    self blahBlah.
    self mainComponent home.

If not, say they're both siblings of a parent, I'd use an Announcement and
rig up the an announcer in the session and have the root component register
for the announcement.

Root>>initialize
    super initialize.
    self session announcer
        on: RefreshHome
        do: [:ann | self mainComponent home]

SideBar>>renderContentOn: html
    html anchor on: #someAction of: self

SideBar>>someAction
    self blahBlah.
    self session announce: RefreshHome new.

Keeps everything nicely decoupled and lets you cause any action in any
component from anywhere in the system.

Ramon Leon
http://onsmalltalk.com

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

On 22/08/07, Ramon Leon <[hidden email]> wrote:
> Well, it depends on if your sidebar has direct access to the main component
> or not.
>
> If not, say they're both siblings of a parent, I'd use an Announcement and
> rig up the an announcer in the session and have the root component register
> for the announcement.
>
> Keeps everything nicely decoupled and lets you cause any action in any
> component from anywhere in the system.

Thanks for the examples. We considered doing something along the lines
of your first suggestion, but it becomes awkward when every callback
defined in the sidebar needs to explicitly clean up the main
component, whereas the decoration ensures it'll happen automatically.
It never occurred to me to use announcements, but I don't think they
solve this issue.

When modified to use #home, though, I guess the decoration is actually
pretty reasonable.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside