[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 1.5.0.8 (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.
Jan
use cases:
server
a) create new
- [GNUe-dev] Structure of HTML client for GNUe Forms,
Jan Ischebeck <=