[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

reply via email to

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