Two different uniGUI sites served by same standalone server

[itognet]

I am having a hypothetical question that is nagging my mind 

 

Is this possible with uniGUI ? 

Having two client browsers on the same PC to show a domain.com/masterpage and a domain.com/workerpage (two different pages/forms)

 

or is the uniGUI more single minded ?

 

If it is possible, would it then be possible to have the masterpage send/read commands to/from the workerpage controlled by the uniGUI.

Both pages with be logged in with same user/password.

 

If anyone have an idea or even a example, I would be pleased. Thanks. 

 

 

 

 

 

[Ron]

Sure, you can use url params, like domain.com?page=master

and domain.com?page=worker, both served by a single server,

standalone or not, and you will see different forms if you set it up

like so, when loading the app.

 

If you want to avoid url params, I think you need a webserver, and

then you can redirect domain.com/master to a DLL

and in the redirect you can insert the url params.

 

If you totally want to avoid url params, you can use a webserver

and redirect to two different instances of the same DLL, using the

url to determine category, or a local file being loaded at mainmodule create.

 

By "sending commands", you do not really send commands to a page

but to the server, and if you create a server-side routine that checks

a db for changes, you can then present that on the other page.

The app can know which category it is in (master/worker) and query

only the commands intended for it.

 

For more direct browser client-client communication, you have to use

websocket clients in each web client, and set up an extra websocket

server to connect the clients.

[vlkc]

In my opinion you can use users with different rights. After they login - transfer them to different forms

[Ron]

In my opinion you can use users with different rights. After they login - transfer them to different forms

 

Right, you can use the peerIP, the local time of day, the local outside temperature, client browser properties/client opsys...in short whatever,

to create different responses from the server upon login or after login. That is the nature of a server - you decide what is to

be served, on which conditions. If you have a predetermined group of people, user access may be the easiest way. If there is no

user login, other available client data may be used to create different server responses.