Dikkie Dik
2/3/2008 3:33:00 PM
> .... 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