Best Practice For Restricting Edits

Best Practice For Restricting Edits

Old forum URL: forums.lhotka.net/forums/t/7943.aspx


Wbmstrmjb posted on Wednesday, November 04, 2009

I wanted to get some feedback on what the best way to conditionally lock down properties would be. We have objects that are editable until some event happens.

Lets say we have an object that is editable until it's status is "Locked". My initial thoughts were to just put a conditional in the SET of each property that should be read-only after "Locked" like:

if (IsLocked()) {
throw new Exception(....);
}

Are there other ways that are better to handle this scenario or am I on the right track?

Thanks,
Mike

RockfordLhotka replied on Wednesday, November 04, 2009

Your easiest option is probably to override CanWriteProperty() in that class and add your check for object state there. That way you leverage the existing features of CSLA .NET, including UI helpers like PropertyStatus.

Wbmstrmjb replied on Wednesday, November 04, 2009

This is why I love this forum! Thanks Rocky!

Wbmstrmjb replied on Wednesday, November 04, 2009

This is working perfectly for locking it down, but now the problem is the mapping in the UI after the SET is locked.

Is the best idea to remove each field conditionally from the mapping or is there a cleaner solution?

Thanks,
Mike

RockfordLhotka replied on Wednesday, November 04, 2009

I'm not sure I understand your question.

Also, the answer is different depending on your UI technology.

The UI can ask the object whether the current user is authorized to read or
write to a property by calling the CanReadProperty() and CanWriteProperty()
methods on the business object. Using that information, the UI can
enable/disable/hide/whatever the UI control(s) corresponding to that
property.

In XAML this is usually done through some fairly simple binding expressions
- and CSLA provides UI helpers like ObjectStatus and PropertyStatus to
combine these authorization rules with various other rules to make things
easier.

In Windows Forms there's the ReadWriteAuthorizer control that automatically
enables/disables UI controls for detail forms, but you are on your own for
complex controls like a datagrid.

In Web Forms you are really on your own, because there's no model for
creating extender controls or helper controls like in Windows Forms or XAML.
But it still isn't terribly complex code - you can see examples in
ProjectTracker\PTWeb.

In ASP.NET MVC you are on your own, but this is usually pretty easy since
the view can just choose whether or how to render various UI elements based
on the CanReadProperty() and CanWriteProperty() results. In the MVC world
you are largely on your own to render the UI anyway, so this is a small bit
of extra effort for a lot of gain.s

Wbmstrmjb replied on Wednesday, November 04, 2009

Thanks Rocky.

I was referring to the DataSource's Update call and mapping e.Values to the object. The properties that are throwing an exception on CanWrite (now that it is overridden) are causing a problem. Do I pull the values out of e.Values selectively based on whether CanWrite is false?

RockfordLhotka replied on Wednesday, November 04, 2009

Yes, that's basically what you need to do.

Copyright (c) Marimer LLC