newbie here, umm... IdentityChanged Event, is this doable, should it be done?

bobo posted on Wednesday, October 25, 2006

Hi!

I  have a business requirement in which a person would be logged on as an operator and all activity would occur under their context. Occasionally Supervisor interaction would be required, so we would be switching context temporarily and then logging off setting the original  operator context back.

I would like to add an event somewhere so if the IPrincipal in Csla.ApplicationContext.User changes it would be raised, I could then attach a handler to a base form of sorts and have it manage all sorts of things under the hood automatically.

With Csla.ApplicationContext being a static class, that gets ruled out. Anybody have any suggestions on where I can put/work this in? It sounds like a good idea to be able to communicate a user change across  an application, maybe i'm wrong... any thoughts?

Thanks

ajj3085 replied on Wednesday, October 25, 2006

Sounds like a fine idea, although you might be able to tackle this another way.

In the new PTracker, the Logout changes the principal, then tells all its forms this happened.  The business objects 'know' because they always look at ApplicationContext.user anyway.

What other kind of processing do you need?

bobo replied on Wednesday, October 25, 2006

I saw the Logout in Ptracker but my thinking was that I didn't want a particular UI element, like a logout button, being in control of all the forms. If the IdentityChanged was implemented as an event then any form/UI element could implement its own handling of the event.

If I'm in a modal dialog of sorts, and i have to do a context change  there, my paddle would be sitting next to the logout button somwhere "back  there". I  would not be able to use that mechanism to do the notification. If all sorts of UI and non-ui elements (maybe even one of those crazy nebulous singletons, that aren't  bound to anything), implemented handlers for the IdentityChanged Event  then that would seem like a pretty nice "decoupled" way of communicating a Security context switch.

That was my thinking,