Menu component - communicating with root component

Boris Popov schrieb: true. if the triggering component is a direct child of the interested
component, there's no need for fancy mechanisms.
but as soon as there are intermediate components, this soon gets out of
control
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Mon, Apr 21, 2008 at 6:44 AM, Holger Kleinsorgen
<[hidden email]> wrote:
I'm faced with this problem now.  I want the grandparent component to
respond to the announcement -- would my idea of having a generic
mechanism to bubble the announcements up the component tree be the way
to go - like html dom events.

--

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

Still, we've build what I consider to be a relatively large and complex
application and I don't recall ever thinking that it was getting out of
control. Certainly not to the point of introducing more elements just to
glue announcers and subscribers together. Let's try a more complex
example to see if perhaps I am missing something. Say you have a table
containing rows containing cells and cells announce CellClicked when you
click on them. If, for some reason, you were interested to know about
that happening up in the table, how about something like,

Table>>addRow: row
 rows add: row.
 row
  when: CellClicked
  do: [:ann | self title: ('editing row <1p> cell <2p>'
                                expandMacrosWith: ann row index
                                with: ann cell index)]

Row>>addCell: cell
 cells add: cell.
 cell
  when: CellClicked
  do: [:ann | self announce: (CellClicked row: self cell: ann cell)].

Cell>>renderContentOn: html
 html anchor
  callback: [self announce: (CellClicked cell: self)];
  with: self contents.

You could of course even have a different announcement for each phase,
this is just an example.

-Boris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Holger
Kleinsorgen
Sent: Sunday, April 20, 2008 1:44 PM
To: Seaside - general discussion
Subject: Re: [Seaside] Re: Menu component - communicating with root
component

Boris Popov schrieb: true. if the triggering component is a direct child of the interested
component, there's no need for fancy mechanisms.
but as soon as there are intermediate components, this soon gets out of
control
_______________________________________________
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 example Boris.

Implicit in that is that an announcement can contain more information
than any given announcer may provide. As you extend the containment
hierarchy the announcement can be extended by adding new instVars. Only
those instances that care need to know about them.

This could be done with parent sends but each object traversed needs to
know the protocol
   
    self parent cellClicked: self.
then
    self parent cellClicked: cell inRow: self

If you add another layer of containment and the top level wants to know
about the bottom when then every intervening object needs new protocol
to support the layer. It always felt to us you end up with more protocol
in every possible parent class just to pass state. With the announcement
all of the state is in one object and it feels simpler. If the objects
in the middle just copy all of the state from the announcement they
receive then they don't even have to know about what the child hierarchy
has added, just that they can receive the announcement and how announce
it themselves.

You can't do that with parent send protocol unless you put the state in
some other object - which means you now have an object to hold the same
state as the announcement would anyway, usually in an anonymous way such
as array elements. Using an announcement allows you to name those
elements and pass them in far less brittle way.

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

> I'm faced with this problem now.  I want the grandparent component to
> respond to the announcement -- would my idea of having a generic
> mechanism to bubble the announcements up the component tree be the way
> to go - like html dom events.
>
>  
That was my plan too, and that is what I had used in the past...

however I have also been pondering the communication between siblings
issue. So this Environment idea is interesting.

Keith


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

Ah, that's a very good point, so bottom-to-top you would have something
like,

Cell>>renderContentOn: html
 html anchor
  callback: [self announce: (CellClicked cell: self)];
  with: self contents.

Row>>addCell: cell
 cells add: cell.
 cell
  when: CellClicked
  do: [:ann | self announce: ((ann copy) row: self; yourself)].

Table>>addRow: row
 rows add: row.
 row
  when: CellClicked
  do: [:ann | self announce: ((ann copy) table: self; yourself)].

-Boris

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Steve
Aldred
Sent: Sunday, April 20, 2008 3:14 PM
To: Seaside - general discussion
Subject: Re: [Seaside] Re: Menu component - communicating with root
component

Good example Boris.

Implicit in that is that an announcement can contain more information
than any given announcer may provide. As you extend the containment
hierarchy the announcement can be extended by adding new instVars. Only
those instances that care need to know about them.

This could be done with parent sends but each object traversed needs to
know the protocol
   
    self parent cellClicked: self.
then
    self parent cellClicked: cell inRow: self

If you add another layer of containment and the top level wants to know
about the bottom when then every intervening object needs new protocol
to support the layer. It always felt to us you end up with more protocol

in every possible parent class just to pass state. With the announcement

all of the state is in one object and it feels simpler. If the objects
in the middle just copy all of the state from the announcement they
receive then they don't even have to know about what the child hierarchy

has added, just that they can receive the announcement and how announce
it themselves.

You can't do that with parent send protocol unless you put the state in
some other object - which means you now have an object to hold the same
state as the announcement would anyway, usually in an anonymous way such

as array elements. Using an announcement allows you to name those
elements and pass them in far less brittle way.

cheers
Steve
_______________________________________________
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

Boris Popov schrieb:
> Still, we've build what I consider to be a relatively large and complex
> application and I don't recall ever thinking that it was getting out of
> control. Certainly not to the point of introducing more elements just to
> glue announcers and subscribers together. Let's try a more complex
> example to see if perhaps I am missing something. Say you have a table
> containing rows containing cells and cells announce CellClicked when you
> click on them. If, for some reason, you were interested to know about
> that happening up in the table, how about something like,
>  
the example works, because you have have homogenous components (table
related). If you insert a different kind of component not related to
tables somewhere in the hierarchy, it either has to deal with
"CellClicked" announcements (which is something it shouldnt have to know
about), or the parent (table component) has to subscribe to
grandchildren (row/cell components) directly, bypassing over the
non-table child component.

AFAIK there's no "childComponent
whenAnnouncingSomethingI'veNotSubscribedToDo: [ : ann | self announce:
ann copy ]" mechanism do pass unknown announcements.
In contrast, when handling errors with #on:do:, signals not matching the
specified classes automatically bubble up.

the kind of application I had in mind is highly configurable and
schema/content-driven, with only little hardcoded logic, so wiring
together components is tricky with regard to this problem. also, the
sibling problem had to be solved, so I've carried on with the
environment object approach. But it's definitely no silver bullet, so
the using direct subscriptions probably covers most cases.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>
> Peeking at grandchildren is IMHO even worse than accessing a parent.
> It's the same princicple (traversing the component
> hierarchy), just more
> laborious.
>
+1 here.

That's why I'm using one announcer per component. When you have that
announcements are naturally filtered at the source (exacly as usual events in
any Smalltalk) and everything remains at the same simplicity no matter how many
components, wirings and reactions you have.

Cheers,

Sebastian


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

>
> I'm faced with this problem now.  I want the grandparent component to
> respond to the announcement -- would my idea of having a generic
> mechanism to bubble the announcements up the component tree be the way
> to go - like html dom events.
>

The bubble of events is a poor idea invented for technologies in which, unlike
Smalltalk, you cant make any arbitrary object to have arbitrary events wired and
triggered. Please don’t feel you are limited like that because you don't.

To paliate that limitation they just creatively invented that events should
"bubble" at the price of having to deal with a whole new problem: explicit
filtering of events when a component should not react. Do you see how absurdly
expensive this is?

In the other hand, using Announcements ala events, you have a simple approach
which mimics real life:

Announcement/Event:

        street announce: SemahoreLightWentRed

Driver (reaction) #onRedLight  
        self stopVehicle

Every driver, with a honest license, is expected to have wired that reaction to
the red light event but (wired) only for the semaphore which is just in front of
the vehicle and no others. He/she does not have to be stressed having to filter
all semaphores going red in the neighbourhood not to mention the city and so on
(global things smells).

Which could possible be more simple yet scalable than that?

This model has proven good for decades in N Smalltalk environments. Why innovate
injecting the irrelevant?

Cheers,

Sebastian
PS1: I found relevant the quote I recently saw in Newspeak presentation:
"A programming language is low level when its programs require attention to the
irrelevant", Alan Perlis

PS2:  Bubbling will be like making the cooling system of the car to also receive
the red light of the semaphore in the street. This reminds me to that joke of
what would happen if Microsoft starts making cars...

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

> Every driver, with a honest license, is expected to have wired that reaction to
> the red light event but (wired) only for the semaphore which is just in front of
> the vehicle and no others. He/she does not have to be stressed having to filter
>  
So what about drivers that are parked around the corner, they cant even
see the light physically, yet they get the event!

Does this then mean that every driver has to check every object in the
entire world, for line of sight?

Keith

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

> Now, both parent components catch the event, check to make sure the #sender
> is one of their children or grandchildren with a quick recursive check on
> #children, before deciding to process the announcement.  This way you scope
> the ChangeBody to the correct parent.
>
>  
Ah now I get it! "Quick recursive check".

> Yes and no, yes a global announcer, but you're wrong about the spatial
> information because all components know their children, you can always
> iterate and check this.
>  
That is where I get stuck, that concept is just inconceivable to me I
just cant get my head around it.

Keith
 

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

>
> Peeking at grandchildren is IMHO even worse than accessing a parent.
> It's the same principle (traversing the component
> hierarchy), just more laborious.

Peeking for no purpose other than to do an #includes to scope an
announcement to a particular parent is not IMHO that bad at all.  It creates
no specific coupling that's break the component were it moved or the
hierarchy changed and the point in using Announcement/Events in the first
place is to avoid tight coupling.  If you can avoid it, certainly, do, but
Kieths proposed problem begged for such scoping of a generic event to a
particular parent so two instance of the same component be used on the page
together without interfering with each other.

Ramon Leon
http://onsmalltalk.com

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

> >  
> So what about drivers that are parked around the corner, they
> cant even see the light physically, yet they get the event!
>
> Does this then mean that every driver has to check every
> object in the entire world, for line of sight?
>
> Keith

If you use a global announcer, yes, which is why it isn't always
appropriate.  It's up to you to decide when the convenience outweighs the
cost of having to ignore events.  The alternative is to create more
announcers and then deal with knowing where to register interest.
Ultimately, every object can be its own announcer firing its own events and
interested parties then have to be wired up very intricately to the exact
instances they're interested in which can be quite a pain.  Which way on the
scale you lean, one announcer, many announcers, or every object its own
announcer all depends on particulars only you know.

Ramon Leon
http://onsmalltalk.com

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

> So what about drivers that are parked around the corner, they
> cant even
> see the light physically, yet they get the event!
>
Well.. in which architecture? In my proposal they don't receive the event
because the semaphore announces its light changes only to its own subscribers.
The subscribers at that time will be only those drivers with that semaphore in
sight. Same for the rest of the drivers and semaphores.

> Does this then mean that every driver has to check every
> object in the
> entire world, for line of sight?
>
> Keith
>
I think it's clear that no. They just has to check (subscribe) to whatever the
object has in its own interest. For the driver example the line of sight
straight ahead should be the first priority of its interests (unless driving
backwards and other subtleties like that). So to be subscribed to events of the
first semaphore he/she has in front is mandatory but only while the semaphore is
in front. Once he/she pass the semaphore he/she don’t worry aout it anymore
(unsuscribes events from that semaphore).

I hope to be understandable.

Sebastian

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

2008/4/21 Sebastian Sastre <[hidden email]>:
A scheme described here leads to setting up listeners manually, e.g. instead of:
driver interestedIn: SemaphoreLight
and:
driver noLongerinterestedIn: SemaphoreLight

your scheme means something like:

semaphore interestedBy: driver.
and:
semaphore noLongerInterestedBy: driver.

so, to set-up a wiring you need to have visible both instances of
driver and semaphore in some code to wire them up, which is not always
simple because they can be placed using complex hierarchy like:

street
 |    |
 |   car -- driver
 |
 crossroads -- semaphore

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



--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Well said Igor! And which place for that wiring to happen is better than the one with a bird's eye? That's why parents wire children's events.

An almost literal example:

Parents have the responsibility to know how to react in front of the event of a children complaining about having fever. Children just have to complain.

So.. as you say, if the hierarchy is kind of deep you make a convenience to invoke "from the deeps" the wireable subchildren. That coupling is inevitable and reasonable. What is not reasonable is to aspire to make one object to react to an event (a explicit detailed interest) and at the same time pretend it should not know its origin (the wired sub/children).

In such case different events should be triggered at different levels of the chain. To illustrate: the tire sensor event of a cool car saying "minimum pressure level reached", the wired computer reacting with turining on the alarm "problem in the tires of the car" (another event with different level of detail), wired by the driver who ... and so on

        cheers,

Sebastian Sastre

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

Sebastian Sastre wrote: But from the outset, I said that the Parents are generic containers,
PRPages which components embedded. So they have no idea what their
children are or what events need to be wired for a specifc child.

To use a "Nurturing analog" from "Living the The Life Model" book.

We progress through stages.... Infant -> Child -> Adolescent ->  Adult
-> Parent -> Elder

Lessons we need to learn as we grow up include...

Infants need to be able to learn to receive from their parents.
Children need to learn to articulate their needs.
Adolescents learn to look after themselves.
Parents learn to look after others as well as themselves.
Elders learn to nurture communities in which all of the above happen.

Our "child" components are stuck at the Infant level.

Parents are only able to help children to the extent that a child can
articulate its needs and at the moment I cant see any way of doing that.
without the child knowing who the parent is

regards

Keith

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

... but announcement is exactly there to help a child articulate its
needs whenever they desire something. If you wire a child to only tell
its parents when it's hungry, things aren't going to go so smoothly when
you leave him/her at daycare.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

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

"Keith Hodges" <[hidden email]> wrote in message
news:[hidden email]...

> But from the outset, I said that the Parents are generic containers,
> PRPages which components embedded. So they have no idea what their
> children are or what events need to be wired for a specifc child.

So I would guess in your case the parents do not instantiate (and add) their
own children, but some other configurer (X) does. What would be wrong with:

X>>addChild: aChild toParent: aParent
    aParent addChild: aChild.
    aChild when: SomeChange do: [:aChange | self doTheRightThingOn: aParent
for: aChange]

Would that be reasonable? Would it matter whether aChild used a local or a
global announcer?

Sophie



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

Sebastian Sastre wrote:
[snip]

> PS1: I found relevant the quote I recently saw in Newspeak presentation:
> "A programming language is low level when its programs require attention to the
> irrelevant", Alan Perlis
>
> PS2:  Bubbling will be like making the cooling system of the car to also receive
> the red light of the semaphore in the street. This reminds me to that joke of
> what would happen if Microsoft starts making cars...

Unfortunately in U.S.A. that is already an almost reality. :(

Ford has cars which use MS software for parts of its media system.
http://www.syncmyride.com/

Scary to think that some hacker could find a means to exploit that
system and access who knows what on the car.

I have no faith in MS to not provide an open door to its systems and
then open a way to the cars systems. To me they do not have a good
security track record.

There will be no such car at my home. :)

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