Move dictionary from instance to class level

[Dave Angel]

Frank Millman wrote:
> 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
>
>
>   
OK, that makes good sense.  And I withdraw any suggestion to use 
pickling, since that could be subject to hacking.

It now appears that the messages are only incidentally GUI events.  And 
that you would be well advised to make every possible event a separate 
message, so that if the server state and the client state get out of 
synch, you can readily check and reject such operations.  For example, 
you'd have a message for pressing the SUBMIT button on a particular 
form, but you'd have different message types for other buttons on the 
same form, or for SUBMIT on other forms.

DaveA