Is there an obvious way to do this in python?

[H J van Rooyen]

"Nick Vatamaniuc" <vatamane at gmail.com> wrote:


|HJ,
|
|As far as GUI language/library goes:
|
|Some people suggested HTML,  but I think HTML is a very awkward way to
|create a good looking dynamic GUI that is _both_ easy to use and fast
|and easy to design (which is what you would want probably). Just to
|have a nice user editable table for example, you would have to jump
|through hoops (using Javascript, DOM, CSS etc), while you could do it
|much easier with PyGTK and wxPython, especially if you use a gui
|designer like Glade or wxGlade. Even Tkinter beats HTML as far as
|building GUIs in Python goes. I believe this might change in the future
|with the adaption of SVG but that will take a while... That said, if
|your interface can "get by" with just buttons, text boxes, and text
|areas HTML will be  the best choice.
|

At the moment my toy system just uses Tkinter-  Buttons, Labels, Entry boxes and
Listboxes (which I populate from a dict) - and it has logic in it to do only one
dummy transaction, which I just ship to the server machine where nothing
happens - it is just echoed back to the client which prints it on stdout - If I
stay with this it will be a most uninteresting GUI - but that is not the point
at issue now...

|
|As far as "updating-on-the-fly" goes:
|
|For the client to get the code on the fly you will have to implement
|some sort of a downloader in the first place that when the user logs
|in, it downloads the GUI code from the server and runs it. So if you
|update the code the day before the next day they will get a different
|interface, or if a new user/machine type is created you just have the
|new code ready on the server and it will automatically be downloaded
|and run, is that right?
|

This is broadly what I had in mind, yes - but sort of down to a transaction
level - this user does invoicing, this one enters cheques, this one does credit
notes, and their supervisor can do all three, and in a different department its
different because the jobs are different, but the invoicing GUI module is the
same for wherever its used...

|Here is then how I see your use case:
|1) You would define your business rules in your database, you will have
|usernames, user types, access rights, data tables, columns types,
|relations, views, etc...

Yes no matter how you do it, you need to keep a per user or per machine set of
what can be done. - in banking terms - a sort of Terminal Management System...

My thinking is simpler than this, because you are already thinking in "data base
speak" - now dont get me wrong - I realise that I will have to use a database -
but for me to start thinking in terms of views and stuff is kind of premature
when I dont even have a clear picture in my head of the kind of data the said
management system should keep, as I am not sure of what can, and cannot be done.

|2) Then each user type will have a specific interface GUI code kept on
|the server (perhaps as a zipped binary GUI.zip in a database column
|called ClientSpecificGUI).

I would like to split this down further - see above - so for each user there is
a sort of *pointer* to each of the kinds of transactions she can do, and these
are shipped separately and *linked* at the client side...

|3) The client starts your Application.py which is the same across all
|clients. They will enter their username/password. The Application.py
|then sends those to the server to log into the DB.

*nods*

|4) After successful login, the  Application.py performs a SELECT query
|to download the zipped GUI.py file.
|5) GUI.py is unzipped and executed to start the GUI. The Application.py
|code will pass the DB connection object to the GUI.py, so the GUI can
|continue to talk with the database. GUI.py runs and does its magic, in
|the meantime Application.py waits for GUI.py to finished and then both
|exit.

|Is that what you had in mind?

Very close - I have not even thought this far - I did not think of building a
GUI for each user, I thought of building it for each transaction - kind of a
series of things like my toy - and then I got stuck on the "linking the separate
transaction guis into an app on the fly" bit, which is why I started the
thread - I really want to know if it is possible to do this sort of thing in
Python, and so far Bruno has come up with Pyro, while everybody else (including
Bruno) is beating me over the head with HTML

Now part of the reason I would like to go the transaction type route instead of
the  "per user" route is robustness and maintainability, and the ability it
would give me to introduce new transaction types easily - as I see it if say an
invoice's GUI code is stable I would never have to touch it again even if I
combine it with anything else, as it would have been designed from the start to
combine with others of it's own ilk, under a kind of communications controller
that is standard...


|NOTE: This means that the client will need to have all the required
|libraries at just the right versions. Imagine that your user decides to
|upgrade to Python 3000 because it sounds cooler than plain old Python
|2.4 ;) , but then they won't realize that it will break your code and
|they might not be able to run your application anymore. So you would
|have to know at least roughly how much control over the whole client
|machine you will have. Will they all be regular desktops that users
|will use day to day and then once in a while launch your application
|then close it, or will these all be dedicated terminals like an  ATM?
|The two are very different. You can assume complete control of all the
|OS environment in a dedicated terminal but not in the case of a user
|desktop.

True - have not even considered this - this would, I imagine, vary from site to
site, and depend more on local IT policy - this is probably the strongest
argument to date against going this route, as these machines would not be as
tightly controlled as an ATM...

but then - If I want to use Python in the client at all, I would have to somehow
come to terms with this - its more the normal sort of version control that would
have to be done - after all if a user's machine is an XT running DOS - then its
going to have to be upgraded before it can be used as a terminal...

So this is more an argument against the use of Python on the client and I don't
like that...

|Hope this helps,
|Nick Vatamaniuc

8<----------------------------------------------------

Yes it does, Thanks. I feel we are getting closer to the point where I can
decide if what I am thinking of is practical or a pipe dream - it sounded so
simple - make a series of guis for a series of transactions, ship them to the
client, where there is a simple top level thingy that swallows them and ties
them all together and handles the comms to the server... I mean the language is
called Python... :-)

- Hendrik