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
--
http://mail.python.org/mailman/listinfo/python-list
