No problem with the dialog, however the publish message from dialog1.panelA is also received by frame1.panelB. However it should have no effect. Currently part of the publish message data is "panelA.GetParent()" and in panelB I check for the message data if it matches "panelB.GetParent()" then I don't do anything.
However this obviously falls apart as soon as the parent hierarchy changes and it also 'smells bad' .
Any hints on how one should do this type of stuff with PubSub would be very welcome.
I don't see anything intrinsically wrong with your approach. You are
saying that the information in the message is not only internal to
panelX but also depends on its context - frame1 or dialog1. I agree
that passing (pointers to) objects smells, so how about constructing
the
panels with a context marker: wx.GetId(), 'FrameBased', whatever you
need to distinguish the source.
Phil
···
On Jul 29, 7:22 am, "Werner F. Bruhin" <wbru...@gmail.com> wrote:
I have something like this in my application.
panelA - publish message
panelB - receive message
frame1
- panelA
- panelB
All is fine so far.
dialog1
- panelA
- panelB
No problem with the dialog, however the publish message from
dialog1.panelA is also received by frame1.panelB. However it should
have no effect. Currently part of the publish message data is
"panelA.GetParent()" and in panelB I check for the message data if it
matches "panelB.GetParent()" then I don't do anything.
However this obviously falls apart as soon as the parent hierarchy
changes and it also 'smells bad' .
Any hints on how one should do this type of stuff with PubSub would be
very welcome.
No problem with the dialog, however the publish message from
dialog1.panelA is also received by frame1.panelB. However it should
have no effect. Currently part of the publish message data is
"panelA.GetParent()" and in panelB I check for the message data if it
matches "panelB.GetParent()" then I don't do anything.
However this obviously falls apart as soon as the parent hierarchy
changes and it also 'smells bad' .
Any hints on how one should do this type of stuff with PubSub would be
very welcome.
Werner
I don't see anything intrinsically wrong with your approach. You are
saying that the information in the message is not only internal to
panelX but also depends on its context - frame1 or dialog1.
Just to clarify this a bit more.
panelB should not react to a message from a panelA which is not a sibling of panelB's instance. There is only one frame in the application using panelB, but there are a few dialogs which use it, so e.g. dialog2.panelA's message should not affect dialog1 nor frame1 panelB.
I agree
that passing (pointers to) objects smells, so how about constructing
the
panels with a context marker: wx.GetId(), 'FrameBased', whatever you
need to distinguish the source.
I think I should get away from using GetParent (so a change like adding a panel to frame1 which is becoming the parent of panelX is not causing problems), maybe it would be better if frame1 and dialog1 pass/set something in panelA and panelB when they get instantiated. Maybe a param called "MyContext" or ....
I actually have a similar problem (or a re-factor opportunity ) with the way panels get at the current database connection and/or a particular database object instance. I think I use too often GetParent (which works but makes reuse of panels etc a bit more difficult).
Anyhow thanks for ideas.
Werner
···
On Jul 29, 7:22 am, "Werner F. Bruhin" <wbru...@gmail.com> wrote:
No problem with the dialog, however the publish message from dialog1.panelA is also received by frame1.panelB. However it should have no effect. Currently part of the publish message data is "panelA.GetParent()" and in panelB I check for the message data if it matches "panelB.GetParent()" then I don't do anything.
However this obviously falls apart as soon as the parent hierarchy changes and it also 'smells bad' .
Any hints on how one should do this type of stuff with PubSub would be very welcome.
You could use a dynamicly constructed topic for the subscriptions that is based on the context. For example, using the parent to define the context:
Or anything else could be used for the context portion of the topic if you don't want to rely on the parent being the common point of the sender/subscriber, such as some name passed in to the class's __init__.
This way you can use the same classes for the different contexts, but still keep their messages separate. And if you ever do want to share messages between the different contexts, then you can use the dotted hierarchical nature of the pubsub topics and just leave off the dot and context string to catch "theMessageName" messages from anywhere.
No problem with the dialog, however the publish message from dialog1.panelA is also received by frame1.panelB. However it should have no effect. Currently part of the publish message data is "panelA.GetParent()" and in panelB I check for the message data if it matches "panelB.GetParent()" then I don't do anything.
However this obviously falls apart as soon as the parent hierarchy changes and it also 'smells bad' .
Any hints on how one should do this type of stuff with PubSub would be very welcome.
You could use a dynamicly constructed topic for the subscriptions that is based on the context. For example, using the parent to define the context:
Or anything else could be used for the context portion of the topic if you don't want to rely on the parent being the common point of the sender/subscriber, such as some name passed in to the class's __init__.
This way you can use the same classes for the different contexts, but still keep their messages separate. And if you ever do want to share messages between the different contexts, then you can use the dotted hierarchical nature of the pubsub topics and just leave off the dot and context string to catch "theMessageName" messages from anywhere.
I like this idea of making it part of the topic and will probably pass in some contextName into the __init__.
.
.
) with the way panels get at the current database connection and/or a particular database object instance. I think I use too often GetParent (which works but makes reuse of panels etc a bit more difficult).