Is there an obvious way to do this in python?

[Nick Vatamaniuc]

Hendrik,

---snip---
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...
---snip---

It could be possible to separate your GUI into various modules. So you
could have for example:
BillingGUI.py
InvoicingGUI.py
QueryGUI.py
and so on.
Then your central control application (Application.py) would get the
set of module names allowed for that client to run during login. So
after the user logs in, the next thing would be to "SELECT ..."  all
the GUI modules from the database to be downloaded. The client won't
know which ones are there, only the server.

So the set of possible GUIs will be sent over to the client (preferable
in a zipped form). They are unzipped in some temporary folder (here you
can do some caching to only download if the set changed).

Then it would be imporant for you to create some nameing rule or some
interface so the Application.py will know what GUI modules look like.
For example you  could have the pattern [Capitalizedname]GUI.py be a
GUI module. The Application.py will then inspect the folder, and create
a button and label for each possible GUI module and present that to the
user. When the user clicks on the Button, the Application.py window
gets hidden and the [Modulename]GUI.py module is executed. When done,
the Application.py will be shown again and the user can either continue
with another module they are allowed to use or quit.

How does that sound?

Also, you mentioned that you won't have more than a couple of simple
fill-in forms and with drop-down options and so on. HTML then might be
the way to go. If that's all there will ever be just try to do HTML
(see Cherrypy, Turbogears and others....). If your GUI will be more
complicated in the future, just stick with what you know (Tkinter for
example).

Good luck,
Nick Vatamaniuc


H J van Rooyen wrote:
> "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