> .... I have an application > that is accessible through the web and also through desktop > applications and both clients should be presented a simple dialog GUI. > This dialog will only include text fields, radio buttons and a file > upload field. > > My idea is that if there was a lightweight GUI definition format then > I would define the current list of fields and other GUI elements in > this format, expose this file on the web, and both the web client and > the desktop client would first fetch this file and generate the > appropriate GUI from that dynamically.
I am very new to Python, and my first python application has a "cascading" user interface: if enough is given on the command-line, it sticks to being a command-line app, and if more data is needed, it presents a GUI. I never did this before, and it taught me a good lesson. The main thing I learned from it is that the GUI tends to control not only the input of the application, but also its flow and modularity structure. I was really glad that I did not include a web interface (which would not have made any sense in my case). The web applications are usually totally different because of: - the stateless nature of HTTP - the use of HTTP headers (session handlers, redirects, authentication) So designing a "local" GUI format that can also be used in a web environment is not really impossible, but hardly practical. For instance, a "local" GUI can hold information, do some validation and store the whole input as a batch, or better said, as a transaction. Web applications do not work this way. Sure, if you rely on javascript (not a good idea if you want your app to be portable), you can do some basic validation and even make server calls. But still, a well-designed web app is more fault tolerant due to the browser variations: In a web environment, you would store "half" inputs that can be finished later, where in local applications you would not. Local GUIs do not suffer from expiring sessions, for example. So a GUI format is not the main problem. The main problem is the "nature" of the whole application. By the way: my User Interface classes did not share a definition file or something. So a simple user interface like yours could easily be generated in two varieties, by two different classes or modules. And a more complex UI would suffer from the difference in nature, so it would even call for two different client applications. Best regards -- http://mail.python.org/mailman/listinfo/python-list
