[Seaside] onAnswer: problems

[C. David Shaffer]

Avi Bryant wrote:

>
> Yup, that'll fix your immediate problem, but I'm not convinced it's a 
> good long term solution either.  For example, if the child you hung 
> the onAnswer: block on was two deep (say there was a navigation 
> component like a tab widget in between the parent and the child it was 
> really interested in), then things would still break.
>
I think it could be correctly resolved by building the component tree 
and seeing if the handler is a decendant of the object raising the 
notification (or maybe I'm thinking of it backwards...it's been a long 
day).  One could build it in the notification or handler, whichever is 
cheaper (finding chidren seems like it would be faster than looking for 
parent).  I will have a look in two weeks when I get back from 
vacation.  I was trying to understand your question regarding whether or 
not the new scheme is more complicated than the previous.  Personally if 
you gain a lot from the new scheme (which I think you do), and the 
answer mechanism seems like a special case which could be handled with 
some care, so it probably isn't worth going back to the "flat" scheme.  
Obviously schemes similar to the answer notification will require 
similar care but I think they would be rare.  Just my US$0.02

David