CSLA .NET 3.5 enhancement - Objects/Property Interactivity State

vdhant posted on Saturday, January 26, 2008

Hi guys
Rocky, I have been looking into the points that you have mentioned within 'CSLA .NET 3.5 enhancement - object level authorization' and the reasons why you have done what you have done. I like the fact that there is a standard way of being able to check if a given user can perform a given action in a central unified way and it got me thinking… I think that there is a valid reason to have the following methods as virtual and at an instance level CanAddObject(), CanGetObject(), CanEditObject(), CanDeleteObject(),CanReadProperty(name) and CanEditProperty(name).

The reason I feel extremely valid (unless there is another way of doing it that you have supported) and these virtuals should (hoepfully) be included within 3.5 release.

What I am getting to is all about the concept an objects/property interactivity state. At the moment the two main things that govern the objects/properties, that is rules and auths. The auth can prevent roles from editing etc (thus preventing a user from changing something at any time) and the rules can check whether a given input is valid (thus preventing a user from changing something at save time).

Time and time again i am running into scenarios where these are great but there is a need for a third item to this combination and when all three are put together I am calling this the objects Interactivity State.

This third thing (and the reason for having the afore mentioned methods) are business logic/rules which says can this object/property edited/altered/deleted/etc in its given contextual state. It's important to note that is not saying the value supplied is invalid (which is covered by validation) or that the user can not edit it because of security permissions (which is covered by authorisation), just that according to the business rules and the objects current state the object/properties cannot be edited.

An example of this would be if i have an account object, once the age of that account is over 1 week old it can no longer be deleted or if the status of the account is pending decision, only the decision properties on the object can be edited.

Now I can see you saying that this may be able to be achieved with validation, but validation allows the user to make the change and then say it is wrong please correct it. These business rules say that because of the rules it shouldn’t be able to be touched in the first place. This knowledge allows the UI developer to represent these rules as disabled buttons or fields by calling the methods motioned above and allowing CSLA to physically prevent the change at the instance level by calling these as well. You mentioned that the UI developer would call the new static AuthorizationRules.CanxyzObject  methods to disable inputs (I can see value in this because you don’t need an instance and I thinki this is great and should reamain unchanged) but I think because of the need to enforce the style of rules that I have mentioned they need to be at the instance level and the instance level ones not only check these new business rules but also call AuthorizationRules.CanxyzObject, hence providing a unified view.

At the moment I am not seeking a very advanced solution to this problem, just that these methods be included to allow my UI developers to check not only for Authorization but for the various business rules that would prevent the object/property from being changed. Hence why if this virtual methods exist, the business object developer can include these rules in the override for the appropriate method. Now because it is not a complicated solution I imagine that in CanxyyProperty I would first check the auth and if that passed for the given property have a have a case statement which splits off for each property as rules exist. Long term the solution might look more like a cross between the implementation of both the auth and rules engines in that these business rules can be defined as delegates and automatically run when required. But as I said this would be long term and not necessary to allow the what needs to be accomplished in the 3.5 time frame.


I know this was a long one but I don’t think I could have got it out any other way.
Thanks for your time and let us know what you think.
Anthony

RockfordLhotka replied on Monday, January 28, 2008

That's an interesting idea, and I'll add it to the wish list. But I'm not adding features to 3.5 at this point.

Also, I try not to add things to the base classes that aren't used or supported by CSLA itself. In other words, just adding empty virtual implementations of methods is something I try to avoid, because methods like that aren't really part of the framework (they are neither used nor supported).

That kind of extension can be easily added in your own custom base classes, without expanding the API used by all CSLA users.

You can probably imagine how big the API would be if every virtual method anyone thinks up ends up in core CSLA... I get many suggestions like this one, and I could put most of them into CSLA - but the complexity due to the many methods used by just a few percent of users would become overwhelming.

Any implementation of this idea would have to be more holistic. The data portal and the UI controls would need to take these methods into account, which means there'd need to be a new interface (or extend an existing one), and a bunch of changes throughout the framework.

Angel replied on Tuesday, January 29, 2008

I'm trying to do something similiar, I use few functions like UIPropertyEditable and UIPropertyVisible to manage UI from state values...

My UI component (bindingsource extender and Grid Extender) checks this functions every property change.

I don't know how to solve the dependency state for lists, for example, if parent like an invoice has a particular state the user can not add more lines or yes...

At the moment the lists subscribes propertychanged parent event to change allowxxx property

¿Any other idea?