After reading your explanation Katya, the behavior of WOSwitchComponent makes perfect sense. What would happen if it removed the components from subcomponents after the WOComponent name changed? Well, for one, WOSwitchComponent would probably be unusable in a WORepetition. So, I don't think the behavior would classify as a bug, although it may seem a little surprising at first.

Like Andrew, I don't typically use awake/sleep in something that is switched, so I've never really noticed. Interesting nonetheless. Thanks for pointing it out.

Ramsey


On Oct 22, 2009, at 2:51 PM, Andrew Lindesay wrote:

Hi Katya;

The component that is actually switched seems to behave "quasi- stateless" to me, but the tree of components below the switched one seems to behave statefully. Maybe the awake() is issued to all of the past sub-components of the switch in case the switched component changes in the request-response cycle? I make quite heavy use of switch component, but generally try to steer away from awake() and sleep() so I haven't really noticed this before. Here is a case where source-access would be helpful. Anyway; thank you for alerting to this!

cheers.

The workaround is not what my initial e-mail was about - the reason for this behaviour is what was bothering my colleague and me. After spending some time investigating the issue it turned out that all components that have at some point occupied the WOSwitchComponent are registered as subcomponents in the component that contains the switch. These components are not removed from the subcomponents list once they're no longer displayed and get awaken in the component's _awakeInContext(...) method. I'm not sure whether this is a bug, but it's definitely something to keep in mind when using WOSwitchComponent.

___
Andrew Lindesay
www.lindesay.co.nz

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/rgurley %40mac.com

This email sent to rgur...@mac.com

Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to