Prev: How LoD is useful.
Next: Storing intermediate objects (for "visual debugging")
From: Valmir on 7 Aug 2007 22:16
Hi, I'm looking for an design pattern for objects that have to be
visible or not under user rights. I'm mean for example:

User A: Immortal user
User B: Mortal user
User C: stupid user

Form has 3 buttons: New, Update and Delete

User A can see and click on the 3 buttons
User B can only click on New and Update buttons
User C can only click on New button.

Is there an design pattern to controls the visibility of objects in a
windows form? Can someone give me directions or points to white papers
for this?

Thanks in advance

From: Daniel T. on 8 Aug 2007 00:24
Valmir <vcinquini(a)gmail.com> wrote:

> Hi, I'm looking for an design pattern for objects that have to be
> visible or not under user rights. I'm mean for example:
>
> User A: Immortal user
> User B: Mortal user
> User C: stupid user
>
> Form has 3 buttons: New, Update and Delete
>
> User A can see and click on the 3 buttons
> User B can only click on New and Update buttons
> User C can only click on New button.
>
> Is there an design pattern to controls the visibility of objects in a
> windows form? Can someone give me directions or points to white papers
> for this?

I would use the Strategy pattern here. Each user type has a different
algorithm that it passes to the window telling the window what to
display.
From: H. S. Lahman on 8 Aug 2007 14:05
Responding to Valmir...

> Hi, I'm looking for an design pattern for objects that have to be
> visible or not under user rights. I'm mean for example:
>
> User A: Immortal user
> User B: Mortal user
> User C: stupid user
>
> Form has 3 buttons: New, Update and Delete
>
> User A can see and click on the 3 buttons
> User B can only click on New and Update buttons
> User C can only click on New button.
>
> Is there an design pattern to controls the visibility of objects in a
> windows form? Can someone give me directions or points to white papers
> for this?

Not really. Basically one handles this with attributes in the UI.
Typically the dialog has a set of button controls and each control has
an attribute for whether it should be grayed out. The OS Window Manager
handles the access based on the attribute value. One provides the
attributes' values when the dialog is requested.

Whoever in the problem solution is requesting the dialog should have
access to the corresponding attribute of a User object. That is, the
user's privileges are expressed in User attribute with values like
{IMMORTAL, MORTAL, STUPID}. Then in the UI subsystem/layer that value is
mapped to the UI control attribute values by a lookup table by a
"factory" object when the dialog is instantiated.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl(a)pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info(a)pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



From: topmind on 10 Aug 2007 04:23
On Aug 7, 9:24 pm, "Daniel T." <danie...(a)earthlink.net> wrote:
> Valmir <vcinqu...(a)gmail.com> wrote:
> > Hi, I'm looking for an design pattern for objects that have to be
> > visible or not under user rights. I'm mean for example:
>
> > User A: Immortal user
> > User B: Mortal user
> > User C: stupid user
>
> > Form has 3 buttons: New, Update and Delete
>
> > User A can see and click on the 3 buttons
> > User B can only click on New and Update buttons
> > User C can only click on New button.
>
> > Is there an design pattern to controls the visibility of objects in a
> > windows form? Can someone give me directions or points to white papers
> > for this?
>
> I would use the Strategy pattern here. Each user type has a different
> algorithm that it passes to the window telling the window what to
> display.

That won't work well because options often are not mutually
exclusive. In other words, Strategies are too course a granularity
much of the time. You can split them up smaller and smaller as the
granularity of variance changes, but then you get a speghetti object
mess. Some variation of set theory is more flexible and more managable
IMO.

-T-

 | 
Pages: 1
Prev: How LoD is useful.
Next: Storing intermediate objects (for "visual debugging")