Hi,
I'm looking for a java design pattern to provide different GUI according to the user role.
For example, If logon user has general user role, the GUI would disable some administrator related menu items...
I think, this kind of functionality is now in use at many applications..
Thanks in advance..
Habin
Hi
I developed an app with this feature, and I apply in some sense the MVC pattern :
A class (Controller/View) make enable/disabled some menu elements (the main App )
A class (Model) represents the user config. The controler
uses this class in order to perform the enable/disable job.
The serialization of these class is made via some tables
of a relational database. The procc is a user enter your pass and the Controller instantiate the userConfig class
via the database. The Controler make the enable/disable job via the UserConfig info.
there are some "bad" interaction betwen the app and the
info at database but I think no other way (?).
Of course there are a Super user who assign the user permitions (create and serialize the UserConfig objects)
I hope is useful for you
bye
Thank you for your response.
Can you explain more detail about your solution?
I wonder how did you distinguish GUI component according to the user role.
One way I can imagine is to specify to each component permitted user role property.
But, I think there would exist a nicer design pattern..
sincerely.
Hi
I try to explain with some more detail (sorry for my bad english) :
I write a complete hotel reservation app with Java+Bd (relational). This app is used by diferent users types.
The administrator has all privileges (can do every action) and other users can do only some actions (make a reservation, check-in, check-out etc but not modify a
room price for example).
The app is a MDI app, there are a menu and menuitems
and when a user do an actionEvent over a menuItem an InternalFrame is activated and so on. These InternalFrame make possible some actions at app level (ex. : do a check-in).
The menuItems set is controled by the App (is the Controller in MVC design pattern) and the model is represented by a set of user possible actions; so there are a class (UserConfig) with these set of possible actions.
the Controller ask UserConfig abouth the posible action
set and do the enable/disable job. There are a 1 to 1
relationship : each possible actions has a menuItem. And
there are a M to N relationship from User/Action perspective.
With this design (I think is an MVC design) the Controler mantain a UserConfig (via a Relational Database) and the Administrator (via the App) can create or modify the UserConfig objects.
At implementation level, each menu item has a name, and
for each registered user there are the name/id_user pair
of actions. These info (stored in BD) is used to create
the UserConfig objects (via username/password).
Bye