GUI definition for web and desktop

[Dikkie Dik]

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