[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUe-dev] Structure of HTML client for GNUe Forms
From: |
Bajusz Tamás |
Subject: |
Re: [GNUe-dev] Structure of HTML client for GNUe Forms |
Date: |
Thu, 16 Nov 2006 08:28:42 +0100 |
Hello Jan!
I think starting with 1) is enough first,
later you can extend it in direction 4).
But if you prefer to start with 4), it's ok too :)
Bajusz Tamás
On Mon, 13 Nov 2006 21:47:50 +0100
Jan Ischebeck <address@hidden> wrote:
> 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 mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnue-dev
>