Below is an example from the wxPyWiki on how to use a notebook. The
example is nice and clean and uses a subclass of wx.Panel for each page.
This implies that each page will have its own set of event handlers, etc.
My questions:
1. Given this structure, how to people typically handle things
like application state? Do they use some sort of state object which is
passed down to each subclass? (By "state" I mean the guts of what the
application is to do versus the user interface code)
2. How does a widget on PageTwo tell a widget on PageOne to change, for
example, to change the label on a button?
Just looking for input on how people typically handle this. Thanks!
Ron
------- Notebook example -------
import wx
# Some classes to use for the notebook pages. Obviously you would
# want to use something more meaningful for your application, these
# are just for illustration.
class PageOne(wx.Panel):
def __init__(self, parent):
wx.Panel.__init__(self, parent)
t = wx.StaticText(self, -1, "This is a PageOne object", (20,20))
class PageTwo(wx.Panel):
def __init__(self, parent):
wx.Panel.__init__(self, parent)
t = wx.StaticText(self, -1, "This is a PageTwo object", (40,40))
class PageThree(wx.Panel):
def __init__(self, parent):
wx.Panel.__init__(self, parent)
t = wx.StaticText(self, -1, "This is a PageThree object", (60,60))
class MainFrame(wx.Frame):
def __init__(self):
wx.Frame.__init__(self, None, title="Simple Notebook Example")
# Here we create a panel and a notebook on the panel
p = wx.Panel(self)
nb = wx.Notebook(p)
# create the page windows as children of the notebook
page1 = PageOne(nb)
page2 = PageTwo(nb)
page3 = PageThree(nb)
# add the pages to the notebook with the label to show on the tab
nb.AddPage(page1, "Page 1")
nb.AddPage(page2, "Page 2")
nb.AddPage(page3, "Page 3")
# finally, put the notebook in a sizer for the panel to manage
# the layout
sizer = wx.BoxSizer()
sizer.Add(nb, 1, wx.EXPAND)
p.SetSizer(sizer)
if __name__ == "__main__":
app = wx.App()
MainFrame().Show()
app.MainLoop()
Ron Kneusel wrote:
Below is an example from the wxPyWiki on how to use a notebook. The
example is nice and clean and uses a subclass of wx.Panel for each page.
This implies that each page will have its own set of event handlers, etc.My questions:
1. Given this structure, how to people typically handle things
like application state? Do they use some sort of state object which is passed down to each subclass? (By "state" I mean the guts of what the
application is to do versus the user interface code)
I'm pretty sure Andrea mentioned this topic last year...IIRC, he saves the values, sizes and order in sqlite somehow. I save my values to a database and my config to an ini-type file using ConfigParser...however, I am thinking about switching to ConfigObj as it sounds like it may be better.
2. How does a widget on PageTwo tell a widget on PageOne to change, for
example, to change the label on a button?
Probably the easiest way would be to use the pubsub module for this. You could probably do it with event.Skip() too and catch the event at the top and use some kind of introspection to tell where it came from and where it should go, but I think that would be a convoluted mess.
Just looking for input on how people typically handle this. Thanks!
Ron
<snip>
···
-------------------
Mike Driscoll
Blog: http://blog.pythonlibrary.org
Python Extension Building Network: http://www.pythonlibrary.org
1. Given this structure, how to people typically handle things
like application state? Do they use some sort of state object which is
passed down to each subclass? (By "state" I mean the guts of what the
application is to do versus the user interface code)
What do you mean by application state? Size and position of windows?
Or is it something else, like preventing the user from switching
notebook tabs if the data in one tab hasn't been saved? Or do you
mean a way to transfer data from one tab to the other? Or for one
panel to read another?
2. How does a widget on PageTwo tell a widget on PageOne to change, for
example, to change the label on a button?
As Mike said, pubsub will take care of this for you.
···
On Mon, Aug 11, 2008 at 5:59 AM, Ron Kneusel <oneelkruns@hotmail.com> wrote:
--
Josh English
Joshua.R.English@gmail.com
I have an "engine" class that is instantiated in my wx.App() class.
Every GUI class that needs access to the data in the engine does this
in it's __init__()
self.engine = wx.GetApp().engine.
I also use PubSub to keep the GUI in sync with itself and update data
in the engine.
···
On Mon, Aug 11, 2008 at 5:59 AM, Ron Kneusel <oneelkruns@hotmail.com> wrote:
Below is an example from the wxPyWiki on how to use a notebook. The
example is nice and clean and uses a subclass of wx.Panel for each page.
This implies that each page will have its own set of event handlers, etc.My questions:
1. Given this structure, how to people typically handle things
like application state? Do they use some sort of state object which is
passed down to each subclass? (By "state" I mean the guts of what the
application is to do versus the user interface code)2. How does a widget on PageTwo tell a widget on PageOne to change, for
example, to change the label on a button?Just looking for input on how people typically handle this. Thanks!
Ron
--
Stand Fast,
tjg. [Timothy Grant]
I'm working on a tutorial to pull this off with the new PyPubSub v3.
Why use pusub to give data to the engine if they already have a link?
As far as I can see, you still need to extract the data from the
engine using regular python calls (self.engine.Get...).
Josh
···
On Mon, Aug 11, 2008 at 10:52 AM, Timothy Grant <timothy.grant@gmail.com> wrote:
I have an "engine" class that is instantiated in my wx.App() class.
Every GUI class that needs access to the data in the engine does this
in it's __init__()self.engine = wx.GetApp().engine.
I also use PubSub to keep the GUI in sync with itself and update data
in the engine.--
Stand Fast,
tjg. [Timothy Grant]
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
--
Josh English
Joshua.R.English@gmail.com
Timothy Grant wrote:
I have an “engine” class that is instantiated in my wx.App() class.
Every GUI class that needs access to the data in the engine does this
in it’s init()self.engine = wx.GetApp().engine.
I also use PubSub to keep the GUI in sync with itself and update data
in the engine.
Clever! This will work nicely for my application, thanks!
I’m still thinking of a way to manager widgets between objects of different classes. I did look at PubSub and might go that way, but I’m also thinking of a dictionary to associate names with widget ids and then using the same “engine” technique to make sure every object can access it.
Ron
With some metaprogramming, 'foo.x = x' on your engine object can
result in pubsub messages automatically being posted. If you are
careful, you can even make the engine object itself watch for data
updates, so objects that never consume (only produce) don't need a
reference to the engine object, only that to update data it only needs
to send the data to the topic 'engine.update.<subtopic>'.
- Josiah
···
On Mon, Aug 11, 2008 at 12:22 PM, Josh English <joshua.r.english@gmail.com> wrote:
I'm working on a tutorial to pull this off with the new PyPubSub v3.
Why use pusub to give data to the engine if they already have a link?
As far as I can see, you still need to extract the data from the
engine using regular python calls (self.engine.Get...).Josh
On Mon, Aug 11, 2008 at 10:52 AM, Timothy Grant <timothy.grant@gmail.com> wrote:I have an "engine" class that is instantiated in my wx.App() class.
Every GUI class that needs access to the data in the engine does this
in it's __init__()self.engine = wx.GetApp().engine.
I also use PubSub to keep the GUI in sync with itself and update data
in the engine.--
Stand Fast,
tjg. [Timothy Grant]
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users--
Josh English
Joshua.R.English@gmail.com
http://joshenglish.livejournal.com
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
Well I went back and looked at the code, and discovered that generally
when I need to set something in the engine from the GUI I use pubsub
and when I need to update the GUI from the engine I access it
directly.
I'm not quite sure how that split happened. I now have a new goal of
completely divorcing the two so that both halves of the app really
purely on message passing. However, I've been refactoring so much
recently I've not none much useful work to advance functionality, so
I'm going to finish a couple of new tabs on the character generation
notebook, and then go back to completely divorcing the two halves.
I'd love to get some insight into that meta programming.
Thank you very much Josiah.
···
On Tue, Aug 12, 2008 at 4:56 PM, Josiah Carlson <josiah.carlson@gmail.com> wrote:
With some metaprogramming, 'foo.x = x' on your engine object can
result in pubsub messages automatically being posted. If you are
careful, you can even make the engine object itself watch for data
updates, so objects that never consume (only produce) don't need a
reference to the engine object, only that to update data it only needs
to send the data to the topic 'engine.update.<subtopic>'.- Josiah
On Mon, Aug 11, 2008 at 12:22 PM, Josh English > <joshua.r.english@gmail.com> wrote:
I'm working on a tutorial to pull this off with the new PyPubSub v3.
Why use pusub to give data to the engine if they already have a link?
As far as I can see, you still need to extract the data from the
engine using regular python calls (self.engine.Get...).Josh
On Mon, Aug 11, 2008 at 10:52 AM, Timothy Grant <timothy.grant@gmail.com> wrote:I have an "engine" class that is instantiated in my wx.App() class.
Every GUI class that needs access to the data in the engine does this
in it's __init__()self.engine = wx.GetApp().engine.
I also use PubSub to keep the GUI in sync with itself and update data
in the engine.--
Stand Fast,
tjg. [Timothy Grant]
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users--
Josh English
Joshua.R.English@gmail.com
http://joshenglish.livejournal.com
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
--
Stand Fast,
tjg. [Timothy Grant]
The problem I ran into on this came when I realized Pubsub can't
really request information, so a change in the GUI sends a message to
the engine to update its data, and the engine has to send a message
back out with this new information....
hmm... as long as the GUI elements are listeners as well, this may
work out... I can't think of another way to do this, though.
···
On Wed, Aug 13, 2008 at 8:41 AM, Timothy Grant <timothy.grant@gmail.com> wrote:
Well I went back and looked at the code, and discovered that generally
when I need to set something in the engine from the GUI I use pubsub
and when I need to update the GUI from the engine I access it
directly.I'm not quite sure how that split happened. I now have a new goal of
completely divorcing the two so that both halves of the app really
purely on message passing. However, I've been refactoring so much
recently I've not none much useful work to advance functionality, so
I'm going to finish a couple of new tabs on the character generation
notebook, and then go back to completely divorcing the two halves.I'd love to get some insight into that meta programming.
Thank you very much Josiah.
Josh English
Joshua.R.English@gmail.com
That is exactly correct, and likely why my code evolved that way. If I
want to do the message passing in both directions I will have to
change quite a bit of code where widgets are instantiated based on
methods from the engine...
my_choice = wx.Choice(self, choices=self.engine.available_choices)
will have to be changed into something where the choice is
instantiated with an empty list, and then a method is called that
populates the choices in the widget.
It feels a bit awkward to me, but I've been learning the advantages of
the message-passing paradigm.
I can really see it coming into play in the future as I've been
messing around with the Google App Engine as secondary interface to my
app.
···
On Wed, Aug 13, 2008 at 9:46 AM, Josh English <joshua.r.english@gmail.com> wrote:
The problem I ran into on this came when I realized Pubsub can't
really request information, so a change in the GUI sends a message to
the engine to update its data, and the engine has to send a message
back out with this new information....hmm... as long as the GUI elements are listeners as well, this may
work out... I can't think of another way to do this, though.On Wed, Aug 13, 2008 at 8:41 AM, Timothy Grant <timothy.grant@gmail.com> wrote:
Well I went back and looked at the code, and discovered that generally
when I need to set something in the engine from the GUI I use pubsub
and when I need to update the GUI from the engine I access it
directly.I'm not quite sure how that split happened. I now have a new goal of
completely divorcing the two so that both halves of the app really
purely on message passing. However, I've been refactoring so much
recently I've not none much useful work to advance functionality, so
I'm going to finish a couple of new tabs on the character generation
notebook, and then go back to completely divorcing the two halves.I'd love to get some insight into that meta programming.
Thank you very much Josiah.
Josh English
Joshua.R.English@gmail.com
http://joshenglish.livejournal.com
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
--
Stand Fast,
tjg. [Timothy Grant]
I dinked around with this just a bit... I have an inelegant solution
of the GUI sending a message requesting the engine send an update
message...
···
On Wed, Aug 13, 2008 at 10:29 AM, Timothy Grant <timothy.grant@gmail.com> wrote:
That is exactly correct, and likely why my code evolved that way. If I
want to do the message passing in both directions I will have to
change quite a bit of code where widgets are instantiated based on
methods from the engine...my_choice = wx.Choice(self, choices=self.engine.available_choices)
will have to be changed into something where the choice is
instantiated with an empty list, and then a method is called that
populates the choices in the widget.It feels a bit awkward to me, but I've been learning the advantages of
the message-passing paradigm.I can really see it coming into play in the future as I've been
messing around with the Google App Engine as secondary interface to my
app.On Wed, Aug 13, 2008 at 9:46 AM, Josh English > <joshua.r.english@gmail.com> wrote:
The problem I ran into on this came when I realized Pubsub can't
really request information, so a change in the GUI sends a message to
the engine to update its data, and the engine has to send a message
back out with this new information....hmm... as long as the GUI elements are listeners as well, this may
work out... I can't think of another way to do this, though.On Wed, Aug 13, 2008 at 8:41 AM, Timothy Grant <timothy.grant@gmail.com> wrote:
Well I went back and looked at the code, and discovered that generally
when I need to set something in the engine from the GUI I use pubsub
and when I need to update the GUI from the engine I access it
directly.I'm not quite sure how that split happened. I now have a new goal of
completely divorcing the two so that both halves of the app really
purely on message passing. However, I've been refactoring so much
recently I've not none much useful work to advance functionality, so
I'm going to finish a couple of new tabs on the character generation
notebook, and then go back to completely divorcing the two halves.I'd love to get some insight into that meta programming.
Thank you very much Josiah.
Josh English
Joshua.R.English@gmail.com
http://joshenglish.livejournal.com
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users--
Stand Fast,
tjg. [Timothy Grant]
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users
--
Josh English
Joshua.R.English@gmail.com
Here is a simple example using PyPubSub 3 (http://pubsub.sourceforge.net/)
### START
from pubsub import pub
pub.newTopic('gui','Group gui related messages')
pub.newTopic('gui.datalist',
'Update gui elements with market information',
('data',),
data="A list of (code, title) pairs")
pub.newTopic('engine','Group enging related message')
pub.newTopic('engine.requestData','Have the engine send the data information')
pub.newTopic('engine.addData',
'Adds data to the database',
('code', 'title'),
code = "The code for the new data (must be unique)",
title = "The name of the new data (should be unique)"
)
class Engine(object):
def __init__(self):
self._data = [('A', 'a'), ('B', 'b')]
pub.subscribe(self.psAddData, 'engine.addData')
pub.subscribe(self.psSendData, 'engine.requestData')
def psAddData(self, code, title):
print "engine getting 'addData' message"
self._data.append((code, title))
print "engine done with 'addData'"
def psSendData(self):
print "engine got 'engine.requestData' message"
pub.sendMessage('gui.datalist', data=self._data)
print "done with 'engine.requestData' message"
class GUI(object):
def __init__(self):
self._datalist =
pub.subscribe(self.psGetData, 'gui.datalist')
print "gui sending 'engine.requestData' message"
pub.sendMessage('engine.requestData')
print "sent 'engine.requestData' message"
def psGetData(self, data):
print "gui getting 'gui.datalist' message"
self._datalist = data
print "gui got data"
def Add(self, code, title):
print "gui sending 'engine.addData' message"
pub.sendMessage('engine.addData', code = code, title = title)
print "gui sent 'engine.addData' message"
def Print(self):
print self._datalist
engine = psEngine()
gui = GUI()
gui.Print()
gui.Add('C', 'c')
gui.Print()
···
###
This may be the wrong way to use PyPubSub, but it works:
pythonw -u "sendMessageTest.py"
gui sending 'engine.requestData' message
engine got 'engine.requestData' message
gui getting 'gui.datalist' message
gui got data
done with 'engine.requestData' message
sent 'engine.requestData' message
[('A', 'a'), ('B', 'b')]
gui sending 'engine.addData' message
engine getting 'addData' message
engine done with 'addData'
gui sent 'engine.addData' message
[('A', 'a'), ('B', 'b'), ('C', 'c')]
Exit code: 0
Hmmm.... hopefully the printout is detailed enough to follow the
activity... it kind of feels like I'm using GOTO statements in this
code.
On Wed, Aug 13, 2008 at 1:30 PM, Josh English <joshua.r.english@gmail.com> wrote:
I dinked around with this just a bit... I have an inelegant solution
of the GUI sending a message requesting the engine send an update
message...
--
Josh English
Joshua.R.English@gmail.com
That's pretty cool Josh, thank you for sharing. I'll try it out.
···
On Thu, Aug 14, 2008 at 10:35 AM, Josh English <joshua.r.english@gmail.com> wrote:
Here is a simple example using PyPubSub 3 (http://pubsub.sourceforge.net/)
### START
from pubsub import pubpub.newTopic('gui','Group gui related messages')
pub.newTopic('gui.datalist',
'Update gui elements with market information',
('data',),
data="A list of (code, title) pairs")pub.newTopic('engine','Group enging related message')
pub.newTopic('engine.requestData','Have the engine send the data information')
pub.newTopic('engine.addData',
'Adds data to the database',
('code', 'title'),
code = "The code for the new data (must be unique)",
title = "The name of the new data (should be unique)"
)class Engine(object):
def __init__(self):
self._data = [('A', 'a'), ('B', 'b')]pub.subscribe(self.psAddData, 'engine.addData')
pub.subscribe(self.psSendData, 'engine.requestData')def psAddData(self, code, title):
print "engine getting 'addData' message"
self._data.append((code, title))
print "engine done with 'addData'"def psSendData(self):
print "engine got 'engine.requestData' message"
pub.sendMessage('gui.datalist', data=self._data)
print "done with 'engine.requestData' message"class GUI(object):
def __init__(self):
self._datalist =pub.subscribe(self.psGetData, 'gui.datalist')
print "gui sending 'engine.requestData' message"
pub.sendMessage('engine.requestData')
print "sent 'engine.requestData' message"def psGetData(self, data):
print "gui getting 'gui.datalist' message"
self._datalist = data
print "gui got data"def Add(self, code, title):
print "gui sending 'engine.addData' message"
pub.sendMessage('engine.addData', code = code, title = title)
print "gui sent 'engine.addData' message"def Print(self):
print self._datalistengine = psEngine()
gui = GUI()gui.Print()
gui.Add('C', 'c')
gui.Print()
###This may be the wrong way to use PyPubSub, but it works:
pythonw -u "sendMessageTest.py"
gui sending 'engine.requestData' message
engine got 'engine.requestData' message
gui getting 'gui.datalist' message
gui got data
done with 'engine.requestData' message
sent 'engine.requestData' message
[('A', 'a'), ('B', 'b')]
gui sending 'engine.addData' message
engine getting 'addData' message
engine done with 'addData'
gui sent 'engine.addData' message
[('A', 'a'), ('B', 'b'), ('C', 'c')]Exit code: 0
Hmmm.... hopefully the printout is detailed enough to follow the
activity... it kind of feels like I'm using GOTO statements in this
code.
--
Stand Fast,
tjg. [Timothy Grant]
Josh English wrote:
Here is a simple example using PyPubSub 3 (http://pubsub.sourceforge.net/)
### START
from pubsub import pubpub.newTopic('gui','Group gui related messages')
pub.newTopic('gui.datalist',
'Update gui elements with market information',
('data',),
data="A list of (code, title) pairs")pub.newTopic('engine','Group enging related message')
pub.newTopic('engine.requestData','Have the engine send the data information')
pub.newTopic('engine.addData',
'Adds data to the database',
('code', 'title'),
code = "The code for the new data (must be unique)",
title = "The name of the new data (should be unique)"
)
Just a side note that these are not necessary, just "good practice" (as
are docstrings in Python code). The same could be achieved possibly more
clearly with the (alpha) TopicTreeDefn from pubsubutils:
from pubsub import pub
from pubsubutils import TopicTreeDefn
class MyTopicTree(TopicTreeDefn):
class gui:
'Group gui related messages'
class datalist:
'Update gui elements with market information'
data = "A list of (code, title) pairs")
_required = 'data'
class engine:
'Group enging related message'
class requestData:
'Have the engine send the data information'
class addData',
'Adds data to the database'
code = "The code for the new data (must be unique)"
title = "The name of the new data (should be unique)"
_required = ('code', 'title')
pub.addDefnProvider( MyTopicTree() )
and then simply doing the subscribe/sendMessage calls. The prints can
also be omitted if you use the (to be repaired shortly
pubsubutils.DefaultLogger.
[... code removed...]
Hmmm.... hopefully the printout is detailed enough to follow the
activity... it kind of feels like I'm using GOTO statements in this
code.
Some things that come to mind:
- the topic tree above does not really break coupling: e.g. why should
gui know about an engine? why should engine know about a gui? Each
should probably just know that there's "other stuff" out there, one or
more of which can provide data needed. I prefer to align the topics
along "functions" or "purpose", e.g. anything coming from the user would
be under the 'user.*' branch, anything related to application logic
would be 'control.*' branch, etc. Others may have similar tricks.
- the request-response method is ok but makes the code somewhat hard to
follow (you don't immediately know through which method the data is
going to arrive). Also, it may be artificially broad: one request may be
of interest to many providers (in your example, there is only one -- the
engine), but the response would often be of interest only to the
original sender (though not always). It may work better to give a
"response callback" as part of the topic message data. The listener
assumes that the response to the request should be given via this
callback instead of via a pubsub message. All senders of the
'engine.requestData' topic send a callable which has the same signature.
Note that you have not increased the coupling here, BUT you have
restricted the response to only the original requestor.
Publish-subscribe is a bit of an art I think. There might be some
well-established publish-subscribe patterns out there, anyone know of any?
Oliver
Oliver Schoenborn wrote:
- ... I prefer to align the topics
along "functions" or "purpose", e.g. anything coming from the user would
be under the 'user.*' branch, anything related to application logic
would be 'control.*' branch, etc. Others may have similar tricks.
Actually what I should have said is that I tend to align topic names
along "event types" present in the system, these tend to be less
variable than components (classes, modules etc). So if you ask yourself
what types of events are present in your system, these will probably
make up good choices for topic names. E.g. when user does something in
UI, this is in the 'user.*' topic branch. If your app monitors stuff on
the filesystem, there could be a 'filesystem.*' topic branch. If your
app should display the system load, it would probably have 'processtree'
topic with subtopics of 'processtree.process_started',
'processtree.exited', etc.
Oliver
So after Josiah's prompting and Josh's example, I came up with the
following code to handle things for me.
#First the py.test unit test
class TestMsgObject():
def test__MsgObject__generates_pubsub_message_on_attribute_set(self):
def got_message(data):
self.got_pubsub_message = True
self.data = data
self.got_pubsub_message = False
Publisher().subscribe(got_message, 'MsgObject.update.name')
cls = rollem_engine.MsgObject()
cls.name = 'New Name'
assert cls.name == 'New Name'
assert self.got_pubsub_message
assert self.data.data == 'New Name'
self.got_pubsub_message = False
Publisher().subscribe(got_message, 'MsgObject.update.abilities')
cls.abilities = 10
assert self.got_pubsub_message
assert self.data.data == 10
#Now the code it tests.
class MsgObject(object):
def __setattr__(self, attr, value):
self.__dict__[attr] = value
Publisher().sendMessage('%s.update.%s' %
(self.__class__.__name__, attr), value)
All of the classes that need to pass data to the GUI now use MsgObject
as their base class. I'm thinking using the class name as part of the
topic may be too granular, but I haven't gotten far enough to
ascertain that for certain yet.
Doing this the GUI no longer has to send a request to get data. It
simply sends the message to update the data, and gets messages back
for the results of those updates.
···
On Thu, Aug 14, 2008 at 2:35 PM, Oliver Schoenborn <oliver.schoenborn@utoronto.ca> wrote:
Oliver Schoenborn wrote:
- ... I prefer to align the topics
along "functions" or "purpose", e.g. anything coming from the user would
be under the 'user.*' branch, anything related to application logic
would be 'control.*' branch, etc. Others may have similar tricks.Actually what I should have said is that I tend to align topic names
along "event types" present in the system, these tend to be less
variable than components (classes, modules etc). So if you ask yourself
what types of events are present in your system, these will probably
make up good choices for topic names. E.g. when user does something in
UI, this is in the 'user.*' topic branch. If your app monitors stuff on
the filesystem, there could be a 'filesystem.*' topic branch. If your
app should display the system load, it would probably have 'processtree'
topic with subtopics of 'processtree.process_started',
'processtree.exited', etc.Oliver
--
Stand Fast,
tjg. [Timothy Grant]