Move dictionary from instance to class level

[Frank Millman]

Dave Angel wrote: 
> 
> Frank Millman wrote:
> >
> > That is definitely *not* what I want to do.
> >
> > I want to make the server as generic as possible, so that 
> it can handle any
> > type of client, hopefully even including a browser 
> eventually. Therefore the
> > server has no knowledge of wxPython event types.
> >
> > I have abstracted all the event types I am interested in 
> (the list is fairly
> > stable now). My protocol requires that the client maps a 
> specific gui event
> > type to a message identifier, and the server maps the 
> message identifier to
> > a method that handles the message.
> >
> > Hope that makes sense.
> >
> > Frank
> >
> >
> >   
> Yes, it makes sense. Sorry for heading down that particular 
> dead-end.  
> But the more I think about it, the more likely I think it is 
> that you'll 
> be adding new message types, even if they're just variants of ones 
> already defined.  So it might behoove you to have a shared "data 
> structure" that describes the whole message, not just equates 
> a name to 
> an integer.
> 
> Or consider pickling.  I don't know the tradeoffs, but the 
> idea is that 
> an object is constructed at the other end that has all the same data 
> members as the object you had at this end.  Perhaps with a flexible 
> enough class definition, you could represent all or at least 
> several of 
> your messages with the same object.
> 
> I am curious about your topology.  You're sending events from 
> the client 
> (which presumably has a mouse and keyboard) to a server.  But 
> what does 
> the server do with those?  Does it have its own screen, or what?
> 

I'll try to explain.

I am writing a fairly standard business/accounting application. (I am now
adding Business Process Management to it, which is complicating matters, but
that is another story.)

Most of the gui stuff is basic forms processing - screens with static data,
text fields for display and input of data, and buttons for signifying
certain actions to be taken.

My original attempt had both the gui and the business logic running on the
client, with a connection to a database running on a server. It worked, but
then I realised it was very insecure - it would be easy to hack the python
code, bypass the business logic, and allow any update to the database.

So my second attempt took all the business logic out of the client and put
it onto the server. To execute a form, the server builds a form definition
by creating objects to represent each of the widgets, creates a list of the
components with sufficient information for the client to render them , then
sends a json'd copy of the list to the client, which interprets it and
displays the required form. The client informs the server of each event, and
the server handles the event in much the same way as it did before when the
business logic was on the client.

For example, clicking a button triggers a response which could involve
updating the database, displaying another window with additional data, etc,
etc. Previously there would have been a method on the client designed to
handle the response, and the method would be added to the button constructor
so that it would be called when the button was clicked.

Now the method is on the server, and is stored as an attribute of the button
object on the server. When the user clicks the button, the message is passed
up to the server (each widget has its own id, which is part of the message),
the server is notified that the button was clicked, and it calls the
associated method.

There is a lot more to it than that, but hopefully that will give you an
idea.

If I ever get this to a workable state (it is taking far longer than I
anticipated) I will release it as open source, and will then welcome as much
feedback as possible.

Frank