Hah! Good point. This is exactly why there are SetProperty() and LoadProperty() methods. Somehow it didn't occur to me that I need a ReadProperty() that works like LoadProperty().
(unless you can think of a better name than ReadProperty())
This is what i was kinda getting to here. I should have put that i was specifically meaning 3.5.
http://forums.lhotka.net/forums/thread/20461.aspx
Sounds like a good plan and the name is good.
Anthony
This would be of interest to me too, our architecture is going to use a couple of the features in 3.5 that we were just starting to build in now and are very interested in moving forward. (We use C#)
Also, in your release notes you say that the property stuff is prototype code and mentioned evaluating "if I like it". That is, how confident are you that this property approach will become a permanent part of CSLA? I assume extremely likely, but I wanted to get some sort of "yeah, that's the plan" if that's indeed the case. Would hate to start architecting around a 50/50 proposition :).
Chris
I need to update the change log to remove the "prototype" comment. This is a done deal at this point - what you see is what you get (plus a ReadProperty() method as discussed earlier in the thread).
The VB and C# versions are in sync now, except that C# has indexed LINQ support and VB doesn't yet. Everything else should be the same. And if it isn't please let me know, as that means I missed something!
I'll probably do another preview release in the next 1-2 days, as I did get one of my other primary goals done, and I'd like feedback - the object-level authorization concept has now been formalized into Csla.Security. So instead of implementing (by convention) those four static methods on each type (CanGetObject(), etc), it is all managed now through CSLA itself.
This is an important change, as it allows the data portal and UI code to check authorization in a standard, reusable manner. The result is less code in each object (no need to check authorization in factory methods or a Save() override) and the potential to use authorization in UI frameworks.
Rocky,
I haven't started looking at 3.5 yet; however... I know I've always had an issue with the use of ValidationRules.CheckRules() when I also had set AllowRead authorization on a property that also has business rules associated with it. It would always error since users in a certain role couldn't access the property and the CheckRules() function would try to access the property on their behalf.
Is ValidationRules.CheckRules() going to be able to take advantage of the new ReadProperty() method to elimitate this problem?
Ken
It depends on how you implement your rule method (as it did in
2.0-3.0).
If your rule method accesses the value through the public
property on the business object, then GetProperty() will be called and authorization
will occur.
If you want to avoid that pre-3.5 you needed to bypass the property
and get the field directly. That’s true in 3.5 as well, except now you
need to bypass the property and call ReadProperty() to get the “field”
value.
So in this regard nothing has really changed in any meaningful
way.
Rocky
From: KKoteles
[mailto:cslanet@lhotka.net]
Sent: Friday, January 18, 2008 11:13 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Csla 3.5 GetProperty and Authorisation
Rocky,
I haven't started looking at 3.5 yet; however... I know I've
always had an issue with the use of ValidationRules.CheckRules() when I also
had set AllowRead authorization on a property that also has business rules
associated with it. It would always error since users in a certain role
couldn't access the property and the CheckRules() function would try to access
the property on their behalf.
Is ValidationRules.CheckRules() going to be able to take advantage of the
new ReadProperty() method to elimitate this problem?
Ken
Rocky,
What I was trying to get at are things like your CommonRules. As an example StringMaxLength uses reflection to call the getter of a property. If you are not in a role that can 'see' a dependant property (however, for some reason it has a dependancy associated with a property you can 'see' - ValidationRules.AddDependantProperty) then everything is OK for the actual property being changed, but when the common rule fires for the denied read dependant property - you get an error (due to the deny read).
Can the common rules be updated to make sure they call the ReadProperty() methods? This should eliminate the error when I am not reading the property directly, but the common rule functionality does for validation purposes.
Ken
Ahh, I see.
That’s a tricky problem. I’m not requiring that
people use the new managed property scheme – nor do I want to. The managed
property scheme is very nice, but does incur a performance hit when compared to
using private fields. My guess is that for most apps the perf hit is acceptable,
but for other apps it may not be acceptable.
So ReadProperty() and LoadProperty() aren’t universally
useful. They only work with managed properties, not private field properties.
Rocky
From: KKoteles
[mailto:cslanet@lhotka.net]
Sent: Thursday, January 24, 2008 2:24 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: Csla 3.5 GetProperty and Authorisation
Rocky,
What I was trying to get at are things like your CommonRules. As an
example StringMaxLength uses reflection to call the getter of a property.
If you are not in a role that can 'see' a dependant property (however, for
some reason it has a dependancy associated with a property you can 'see' -
ValidationRules.AddDependantProperty) then everything is OK for the actual
property being changed, but when the common rule fires for the denied read
dependant property - you get an error (due to the deny read).
Can the common rules be updated to make sure they call the ReadProperty()
methods? This should eliminate the error when I am not reading the
property directly, but the common rule functionality does for validation
purposes.
Ken
I was thinking about this very problem and the solution I was thinking of is as follows.
As ReadProperty (read is all you would need for the validation) is a protected method this is what causes the issue. For example, if it where public it wouldn't be a problem but making it public is obviously something you don’t want to do.
Not that i have tested that this would work (i.e. whether the compiler will let you but i am thinking it should), why don’t you make ReadProperty 'internal protected' instead of just protected. This way any part of the internal framework (i.e. CSLA) can read a value when required. By doing this it would allow you to create a protected method within the base class for rule, that allows the code that makes up the rule call this method (passing in the property name that you need) which internal calls the ReadProperty. This would work (I think) because it is the base class (which is internal) is calling the ReadProperty (which is also internal). All that would have to occur is for the rule base class method, when it is called check that the target object the correct CSLA object and then pass on the request.
This is just what i was thinking for my 2 bob worth.
Thanks
Anthony
That would work for managed fields, but not for private fields,
because the rule method has no access to the private fields of an object.
Rocky
From: vdhant
[mailto:cslanet@lhotka.net]
Sent: Thursday, January 24, 2008 9:11 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: RE: Csla 3.5 GetProperty and Authorisation
I was thinking about this very problem and the solution I was thinking of is
as follows.
As ReadProperty (read is all you would need for the validation) is a protected
method this is what causes the issue. For example, if it where public it
wouldn't be a problem but making it public is obviously something you don’t
want to do.
Not that i have tested that this would work (i.e. whether the compiler will let
you but i am thinking it should), why don’t you make ReadProperty 'internal
protected' instead of just protected. This way any part of the internal
framework (i.e. CSLA) can read a value when required. By doing this it would
allow you to create a protected method within the base class for rule, that
allows the code that makes up the rule call this method (passing in the
property name that you need) which internal calls the ReadProperty. This would
work (I think) because it is the base class (which is internal) is calling the
ReadProperty (which is also internal). All that would have to occur is for the
rule base class method, when it is called check that the target object the
correct CSLA object and then pass on the request.
This is just what i was thinking for my 2 bob worth.
Thanks
Anthony
Copyright (c) Marimer LLC