Is there an obvious way to do this in python?

[H J van Rooyen]

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



| 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?

This is the sort of thing I am looking for, thanks - its a bit rough as it
depends on magic gui names, but hey - I think it would be easy to implement,
even not using magic names - the server could tell the core app the names of the
files explicitly during the logon type dialog... *grin* that will move the magic
out of the client and on to the server...


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

Thank you for the support - now I would like to call "Time out" - I have a lot
of reading to do...

- Hendrik