[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUe-dev] Structure of HTML client for GNUe Forms

From: Jan Ischebeck
Subject: [GNUe-dev] Structure of HTML client for GNUe Forms
Date: Mon, 13 Nov 2006 21:47:50 +0100
User-agent: Thunderbird (Windows/20061025)

Hello all,

Currently I work on the HTML frontend for GNUe Forms.
IMHO a HTML or Web interface for GNUe Forms must be multi-user and multi-forms capable. I.e. the HTML frontend for gnue-forms becomes a server providing multiple forms to different users in parallel.

I can think of the following scenarios and would like to know your opinion:

1) Gnue-forms is started with the /-u html /option. A buildin webserver ist started. Users can select different forms by providing the path + filename of a gfd file stored on the server. So by going to http://gnue-server//mypath/myfile.gfd a user can edit/use the selected form with his web browser.

2) Gnue Navigator can be started as a web server. After login into a new session, users can select and start the forms files defined in the navigator process definition file.

3) Gnue Forms continue to be a single user application. After starting gnue-forms with the/ -u html /option a webbrowser will be started on the same machine to access the webpages, which gnue-forms prepares. Directly after the form or the web browser is closed, the application gnue-forms quits. (Similar behavior
    like standard GUI application).

4) Same as 1) but as a separate program. Could also support parsing of gnue-navigator files. Proposed name:
   Gnue Websuite or MyGNUe.

Personally I would prefer a solution, where all gnue tools can be accessed through one webserver. This is both possible in scenario 2 and 4. I would prefer scenario 4 because scenario 2 forces the usage of gnue process definition files and in many cases a individual menu structure is preferred.


use cases:


a) create new

reply via email to

[Prev in Thread] Current Thread [Next in Thread]