"Nick Vatamaniuc" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
