gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] Re: Workplace refactoring


From: Jim Busser
Subject: [Gnumed-devel] Re: Workplace refactoring
Date: Fri, 26 Jun 2009 10:19:38 -0700

More thoughts:

1. A user could only knowledgeably choose a different workplace (from among existing backend values) *after* the connection to the database had been made. Truly it needs to be available as a selection from a second dialog which would have to be inserted after the login dialog but before the main GNUmed gui and its plugins load.

2. In order for the above to be non-intrusive, would it be easy enough manageable for the client to detect whether, at login, a modifier key (alt?) is held down, and only if it is held down to offer the user to select a workplace that is different than what this server-machine-user config file may otherwise say, and that this would affect only the current instance of the client?


On 25-Jun-09, at 6:49 PM, Jim Busser wrote:

Presently the options for switching among sets of plugins (workplaces) are:

1. alter the selections within the workplace GNUMed default, save this new configuration, and then open a new client. This is a cheat, since instead of switching *among* pre-defined workplaces, it *alters* an existing workplace which then creates problems if other users wish a different combination.

2. insert a single workplace name into a backend server level, or machine level (?), or user level gnumed-client.conf file --> the problem here is how, at the worker level, to over-ride when moving between different machines other than by having a personal user account (and therefore having to logout and login) under each machine?

The following was said in January... how would it be implemented that a GNUmed user (who was not logging or logged into the machine as a system user) could have attached to their GNUmed login a set of plugins to be used *separately* from (over-ride) any workplace, if one had been specified?

On 4-Jan-08, at 4:00 AM, Karsten Hilbert wrote:

... The other facet of this is that in the code options can be
defined to user OR workplace independant for lookup. Such
that if a workplace-independant option is set in one
workplace by a user and is looked up under the same user but
with a different workplace it is still found and reused. If,
at some point, the user would chose to explicitely set that
option under the second workplace that value would take
precedence - for that workplace.


At the wiki page CustomizingBackendLogin there is a specification for profiles... is there a solution here to define multiple profiles, each of which could reference the same database but a different workplace, so that in this way the workers could choose (via the login window of the client that is being opened) which workplace to select? Or does the transfer S(torage and management) of workplaces into the backend thwart this approach?





reply via email to

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