design guidance please :user controls and centralizing roles-related display stuff

I'm looking for some design guidance on a collection of projects I'm working
on.

The project involves a bunch of websites constructed out of a collection of
user controls. Different user populations with different access rights and
"roles" will be visiting the site. I will be using ASP.NET 2.0's membership,
roles, and profiles stuff to manage access.

User controls need to be visible or not visible depending on user role. In
some cases, one user role will see one "facet" of a control, while another
user role will see a different aspect of it.

The user controls are often going to be placed at runtime, and have their
properties adjusted at runtime.

What I am wondering now is the best way to centralize the code that manages
the display of these user controls based on role. What I don't want is
"if-else" junk spread throughout my code.

The project is large but not huge, and I am the sole developer for the
project. I have a few ideas for how this might work.

One might be to write a huge function: public static bool IsElementDispla yed
(string roleName, string userControlName ) and have visibility of various
elements constantly checking this.

Another might be to use some form of inheritance. User controls can't
inherit from each other, but maybe they can inherit functionality from
somewhere else.

Another might be to encode this knowledge in some kind of structured data. A
database would be a disaster, but XML might be better.

Any suggestions and guidance out there?

Thanks,
-KF
..

[Steven Cheng[MSFT]]

Hello KF,

As for the role based user-interface, I think there're two possible
scenarios:

** all the controls be put on the page and you control the visibility
dynamically

** the page's layout and controls constructure is not determined at
design-time on page. All the usercontrols are dynamically created and added
into page/container at runtime(based on some structure info from database
or in configuration file).

I assume you're using the second approach, correct? If so, since dynamic
controls need to be created and added into page control structure in each
page request and to make sure all the control lifecycle features works
well, it is recommended that the dynamic control instancing code be put in
Page's Init event(or load). Then, if you want to make the control
structure initializing code contralized, you can consider the following
approaches:

** define a helper class which parsing the configuration schema from
database or xml configuration file and create dynamic controls and add it
into page(get the reference of the page at its construct time). and this
class will be used in each page(which need such dynamic role based UI )'s
Init event.

** Define a base page class and override Page's OnInit methods and add the
dynamic UI parsing and constructing code logic there. And those concrete
pages which need dynamic role based UI can derive from this base page class.

What's your opinion or have you any other ideas on this?

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

=============== =============== =============== =====

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no rights.

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

Lot of ways to skin a cat on this one. I'd consider a Generic List of type
"ControlDisplay " which would be a small class that describes each control's
layout and display characteristics for a specific role. The key to the List
could be something like a concatenation of the site + controlId +role (or
something to that effect).
Then, when you are about to add a dynamic control to a page, you need only
look up the site+controlId in your List (which could be stored as static in
Global), compare to the current user's role(s), and you would have everything
you need for your display business logic.
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"ke*****@nospam .nospam" wrote:

I'm looking for some design guidance on a collection of projects I'm working
on.

The project involves a bunch of websites constructed out of a collection of
user controls. Different user populations with different access rights and
"roles" will be visiting the site. I will be using ASP.NET 2.0's membership,
roles, and profiles stuff to manage access.

User controls need to be visible or not visible depending on user role. In
some cases, one user role will see one "facet" of a control, while another
user role will see a different aspect of it.

The user controls are often going to be placed at runtime, and have their
properties adjusted at runtime.

What I am wondering now is the best way to centralize the code that manages
the display of these user controls based on role. What I don't want is
"if-else" junk spread throughout my code.

The project is large but not huge, and I am the sole developer for the
project. I have a few ideas for how this might work.

One might be to write a huge function: public static bool IsElementDispla yed
(string roleName, string userControlName ) and have visibility of various
elements constantly checking this.

Another might be to use some form of inheritance. User controls can't
inherit from each other, but maybe they can inherit functionality from
somewhere else.

Another might be to encode this knowledge in some kind of structured data. A
database would be a disaster, but XML might be better.

Any suggestions and guidance out there?

Thanks,
-KF
..

[Ken Fine]

Thank you, Peter. Very helpful.

Could I ask you to elaborate just a bit on what you're thinking about when
you suggest "....that describes each control's layout and display
characteristics for a specific role"?

I'm curious to what extent you're thinking the layout and display
characteristics could/should be described in such a lookup class.

I am also curious if there is a "special" characteristic or quality of the
Generic List/Generic that I am not catching here that might make it
especially useful for this application. I am fairly new to C#, lists,
generics, OO, etc and the subtleties of good design is a long process.

Thanks again for your suggestion,
-KF
"Peter Bromberg [C# MVP]" <pb*******@yaho o.yabbadabbadoo .comwrote in
message news:16******** *************** ***********@mic rosoft.com...

Lot of ways to skin a cat on this one. I'd consider a Generic List of type
"ControlDisplay " which would be a small class that describes each
control's
layout and display characteristics for a specific role. The key to the
List
could be something like a concatenation of the site + controlId +role (or
something to that effect).
Then, when you are about to add a dynamic control to a page, you need only
look up the site+controlId in your List (which could be stored as static
in
Global), compare to the current user's role(s), and you would have
everything
you need for your display business logic.
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"ke*****@nospam .nospam" wrote:

>I'm looking for some design guidance on a collection of projects I'm
working
on.

The project involves a bunch of websites constructed out of a collection
of
user controls. Different user populations with different access rights
and
"roles" will be visiting the site. I will be using ASP.NET 2.0's
membership,
roles, and profiles stuff to manage access.

User controls need to be visible or not visible depending on user role.
In
some cases, one user role will see one "facet" of a control, while
another
user role will see a different aspect of it.

The user controls are often going to be placed at runtime, and have their
properties adjusted at runtime.

What I am wondering now is the best way to centralize the code that
manages
the display of these user controls based on role. What I don't want is
"if-else" junk spread throughout my code.

The project is large but not huge, and I am the sole developer for the
project. I have a few ideas for how this might work.

One might be to write a huge function: public static bool
IsElementDispl ayed
(string roleName, string userControlName ) and have visibility of various
elements constantly checking this.

Another might be to use some form of inheritance. User controls can't
inherit from each other, but maybe they can inherit functionality from
somewhere else.

Another might be to encode this knowledge in some kind of structured
data. A
database would be a disaster, but XML might be better.

Any suggestions and guidance out there?

Thanks,
-KF
..

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

Ken,
Well at a minimum you would have a ShowControl boolean that would describe
whether the control should be displayed, based on the "role" provided. I
don't know what other characteristics you need (positioning, etc).

The Generic List could be a Hashtable. Generics simple provide a strongly
typed Collection and avoid the overhead of boxing to and from type object in
a "1.1" style collection.
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"Ken Fine" wrote:

Thank you, Peter. Very helpful.

Could I ask you to elaborate just a bit on what you're thinking about when
you suggest "....that describes each control's layout and display
characteristics for a specific role"?

I'm curious to what extent you're thinking the layout and display
characteristics could/should be described in such a lookup class.

I am also curious if there is a "special" characteristic or quality of the
Generic List/Generic that I am not catching here that might make it
especially useful for this application. I am fairly new to C#, lists,
generics, OO, etc and the subtleties of good design is a long process.

Thanks again for your suggestion,
-KF
"Peter Bromberg [C# MVP]" <pb*******@yaho o.yabbadabbadoo .comwrote in
message news:16******** *************** ***********@mic rosoft.com...

Lot of ways to skin a cat on this one. I'd consider a Generic List of type
"ControlDisplay " which would be a small class that describes each
control's
layout and display characteristics for a specific role. The key to the
List
could be something like a concatenation of the site + controlId +role (or
something to that effect).
Then, when you are about to add a dynamic control to a page, you need only
look up the site+controlId in your List (which could be stored as static
in
Global), compare to the current user's role(s), and you would have
everything
you need for your display business logic.
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"ke*****@nospam .nospam" wrote:

I'm looking for some design guidance on a collection of projects I'm
working
on.

The project involves a bunch of websites constructed out of a collection
of
user controls. Different user populations with different access rights
and
"roles" will be visiting the site. I will be using ASP.NET 2.0's
membership,
roles, and profiles stuff to manage access.

User controls need to be visible or not visible depending on user role.
In
some cases, one user role will see one "facet" of a control, while
another
user role will see a different aspect of it.

The user controls are often going to be placed at runtime, and have their
properties adjusted at runtime.

What I am wondering now is the best way to centralize the code that
manages
the display of these user controls based on role. What I don't want is
"if-else" junk spread throughout my code.

The project is large but not huge, and I am the sole developer for the
project. I have a few ideas for how this might work.

One might be to write a huge function: public static bool
IsElementDispla yed
(string roleName, string userControlName ) and have visibility of various
elements constantly checking this.

Another might be to use some form of inheritance. User controls can't
inherit from each other, but maybe they can inherit functionality from
somewhere else.

Another might be to encode this knowledge in some kind of structured
data. A
database would be a disaster, but XML might be better.

Any suggestions and guidance out there?

Thanks,
-KF
..

Thanks for bearing with me, Peter. I want to continue to explore this idea a
little further, and I hope you'll allow me a little more public embarassment
here.

So one interpretation of what you've been suggesting is to make a small
class -- let's call it UwnControl -- and attach various properties to that
class that describe name and visibility. And then I could conceivably write
code that would instantiate class instances, one for each control name that
I want to check for visiblity:
UwnControl uwnc = new UwnControl();
uwnc.App_Page_C ontrolName = inthemedia_over viewdotaspx_adm ininterface;
uwnc.IsVisibleT oAdmins = true;
uwnc.IsVisibleT oHoldersOfUwNet Ids = false;
uwnc.IsVisibleT oPublic = false;

UwnControl uwnc2 = new UwnControl();
uwnc2.App_Page_ ControlName = inthemedia_over viewdotaspx_pub licoverview;
uwnc2.IsVisible ToAdmins = true;
uwnc2.IsVisible ToHoldersOfUwNe tIds = true;
uwnc2.IsVisible ToPublic = true;

And then I could put all of those in objects in a type-safe List, and then
do lookups against the list by name in conjunction with a function that
would evaluate and return whether a given control should be visible to a
given role or not.

If I've misunderstood you -- particularly in terms of building a collection
of simple objects as shown above -- then it's possible that this fairly
simple solution will perform badly in production, and that's why I'm running
this past you again.

I like the verbosity of using a collection of objects versus a collection of
other datatypes: it's very obvious what the data says and does.

If there are better and more elegant ways to manage this while still
retaining the general simplicity of the approach you suggested initially,
please let me know. If anyone else has thoughts or insults, feel free to
chime in.

-KF

"Peter Bromberg [C# MVP]" <pb*******@yaho o.yabbadabbadoo .comwrote in
message news:62******** *************** ***********@mic rosoft.com...

Ken,
Well at a minimum you would have a ShowControl boolean that would describe
whether the control should be displayed, based on the "role" provided. I
don't know what other characteristics you need (positioning, etc).

The Generic List could be a Hashtable. Generics simple provide a strongly
typed Collection and avoid the overhead of boxing to and from type object
in
a "1.1" style collection.
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"Ken Fine" wrote:

>Thank you, Peter. Very helpful.

Could I ask you to elaborate just a bit on what you're thinking about
when
you suggest "....that describes each control's layout and display
characteristic s for a specific role"?

I'm curious to what extent you're thinking the layout and display
characteristic s could/should be described in such a lookup class.

I am also curious if there is a "special" characteristic or quality of
the
Generic List/Generic that I am not catching here that might make it
especially useful for this application. I am fairly new to C#, lists,
generics, OO, etc and the subtleties of good design is a long process.

Thanks again for your suggestion,
-KF
"Peter Bromberg [C# MVP]" <pb*******@yaho o.yabbadabbadoo .comwrote in
message news:16******** *************** ***********@mic rosoft.com...

Lot of ways to skin a cat on this one. I'd consider a Generic List of
type
"ControlDisplay " which would be a small class that describes each
control's
layout and display characteristics for a specific role. The key to the
List
could be something like a concatenation of the site + controlId +role
(or
something to that effect).
Then, when you are about to add a dynamic control to a page, you need
only
look up the site+controlId in your List (which could be stored as
static
in
Global), compare to the current user's role(s), and you would have
everything
you need for your display business logic.
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"ke*****@nospam .nospam" wrote:

I'm looking for some design guidance on a collection of projects I'm
working
on.

The project involves a bunch of websites constructed out of a
collection
of
user controls. Different user populations with different access rights
and
"roles" will be visiting the site. I will be using ASP.NET 2.0's
membership,
roles, and profiles stuff to manage access.

User controls need to be visible or not visible depending on user
role.
In
some cases, one user role will see one "facet" of a control, while
another
user role will see a different aspect of it.

The user controls are often going to be placed at runtime, and have
their
properties adjusted at runtime.

What I am wondering now is the best way to centralize the code that
manages
the display of these user controls based on role. What I don't want is
"if-else" junk spread throughout my code.

The project is large but not huge, and I am the sole developer for the
project. I have a few ideas for how this might work.

One might be to write a huge function: public static bool
IsElementDispl ayed
(string roleName, string userControlName ) and have visibility of
various
elements constantly checking this.

Another might be to use some form of inheritance. User controls can't
inherit from each other, but maybe they can inherit functionality from
somewhere else.

Another might be to encode this knowledge in some kind of structured
data. A
database would be a disaster, but XML might be better.

Any suggestions and guidance out there?

Thanks,
-KF
..

[Steven Cheng[MSFT]]

Hi KF,

I think those custom class(represent each control's visibility info against
roles) should be made as lightweight as possible. Also, since these object
List should be generated from a configuration file(XML file that store the
role based control/page layout info), you can cache those list in
Application cache and make the cache dependent on the XML configuration
file. Thus, whenever the xml file is modified, the cached list will be
invalidated. And the list should be accessed by an wrapper class which use
on-demand patter to initialize the list. e.g.

public list GetList()
{
if(Cache["_list"] == null)
{
GenerateListFro mConfigurationF ile();
}

return Cache["_list"];
}

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

This is very good, thank you Steven.

So I need just one other code sample or example before I run off this and
actualize it: can you (or someone) give me a brief example of how you could
use references in XML to instantiate a list, as you seem to describe?

Will those XML entries each instantiate a lightweight object, and then
you'll have a list of objects, or were you contemplating some other data
structure as "holders" of the information?

Thanks again. I really appreciate the opportunity to learn these practices.

-KF
"Steven Cheng[MSFT]" <st*****@online .microsoft.comw rote in message
news:wa******** ******@TK2MSFTN GHUB02.phx.gbl. ..

Hi KF,

I think those custom class(represent each control's visibility info
against
roles) should be made as lightweight as possible. Also, since these object
List should be generated from a configuration file(XML file that store the
role based control/page layout info), you can cache those list in
Application cache and make the cache dependent on the XML configuration
file. Thus, whenever the xml file is modified, the cached list will be
invalidated. And the list should be accessed by an wrapper class which use
on-demand patter to initialize the list. e.g.

public list GetList()
{
if(Cache["_list"] == null)
{
GenerateListFro mConfigurationF ile();
}

return Cache["_list"];
}

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no
rights.

[Steven Cheng[MSFT]]

Thanks for your reply KF,

For example of generating a list of class objects from XML file, you can
simply use the .net framework's XML Serialization feature. Generally,
simple custom class or generic collection class support XML serialization.
e.g., the following code demonstrate serialize a custom object's List into
xml file and deserialize it back to memory:
=============== =============== =
static void Serialize()
{
XmlSerializer serializer = new
XmlSerializer(t ypeof(List<Test Class>));

List<TestClasso bjs = new List<TestClass> ();

for (int i = 0; i < 5; i++)
{
TestClass to = new TestClass();
to.ID = "id_" + i;
to.Visible = i % 2 == 0 ? true : false;

objs.Add(to);
}

StreamWriter sw = new StreamWriter("o utput.xml", false,
System.Text.Enc oding.UTF8);

serializer.Seri alize(sw, objs);

sw.Close();
}

static void Deserialize()
{
XmlSerializer serializer = new
XmlSerializer(t ypeof(List<Test Class>));

StreamReader sr = new StreamReader("o utput.xml",
System.Text.Enc oding.UTF8);

List<TestClasso bjs = serializer.Dese rialize(sr) as
List<TestClass> ;

sr.Close();
foreach(TestCla ss to in objs)
{
Console.WriteLi ne("id: {0}, visible: {1}", to.ID,
to.Visible);
}
}
=============== =============== =

Hope this helps.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

This posting is provided "AS IS" with no warranties, and confers no rights.