I have put a very early version of 2.1 on the downloads page. While many of the changes exist in both the VB and C# code bases, I've been doing all the experimental stuff around validation rules in only the VB code base, so that's all I'm putting up there at the moment.
(If there's demand, I can put the C# code up there too - but it is missing the validation/authorization rules changes - they are so extensive that I want to make sure they are good before going through the work of porting them over. FWIW, I wrote several other features in C# first, but they are stable enough that I just ported them back to VB already - things like FilteredBindingList and EditableRootListBase for instance.)
At the moment there's no real documentation beyond the change log. My plan is to write a new "chapter" describing the changes and how to use them. That content will be available for purchase on my web site when it is complete, and can be viewed as an add-on to the existing book. As always, the version 2.1 code will be freely downloadable just like 2.0. Basically I'm planning to follow the same model as I've been doing for years now - charge for the book (and now additional content) and provide the code freely.
If you want to experiment with, and help me test, the rather extensive changes to the validation rules I really appreciate it. These changes include:
The per-type rules also applies to AuthorizationRules, where there's a new virtual AddSharedAuthorizationRules() method in which you can call the new SharedAllowRead(), etc. methods.
The per-type rules offer substantial performance and memory consumption benefits over the original per-instance approach, and I recommend migrating to this new approach unless you have a very specific need to customize your rules per instance. You can use both, but there's a performance impact to doing so, and so I recommend using only one or the other (preferably per-type).
The priority/short-circuiting also allows you to get major performance gains. For instance, you could do all your trivial rule checking (like string required, mas length, min value, etc.) and only do expensive rules (that might require database access, etc.) if the easy ones succeed. Also, with e.StopProcessing, you can have some rule decide that its failure was so important that no other rules should be checked, which offers a lot of flexibility.
The Warning and Information severities reflect a long-requested feature. I'm not sure I'm done here, as I still may add a new interface to Csla.Core.BusinessBase to expose these in a way more similar to IDataErrorInfo. However, I might not do that either, because it is just as easy to create an extender control to run off BrokenRules as off some new custom interface...
The real point though, is that only Error severity items will appear in an ErrorProvider control. If you want to display Warning or Information items you'll need to create your own UI mechanism to do that, and the information you need should be available from BrokenRules on each business object.
I want to include my support for the prospect of charging for the documentation of 2.1.
I think there are a lot of us that recognize the value in what you give to us and would rather see a vendor (that'd be you in some ways, Rocky) feeling that it is worth their while to continue on this process of continual development. While some of that is just your love for Csla, I'm sure some compensation for your hard work is icing on the cake.
Thanks again.
(Oh, and once ported to C# I'll be immediately bringing 2.1 into the code base since we're quite a ways from production, yet.)
Can you merge HEAD C# CVS prj with 2.1 branch ?
From: Fabio [mailto:cslanet@lhotka.net]
Sent: Tuesday, August 01, 2006 12:09 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Version 2.1 (VB only) available for testing
Thanks.
Fabio.
P.D. I know the warning: As always, be aware that this is a live repository, so there is no guarantee that the current code is tested or works in any way!!!
Rocky, could you please extend the RuleArgs to contain a PropertyText property?
With the current structure it is difficult to localize user oriented texts within the rules framework. For example you might have a property called TargetDelivery that is labeled "Target delivery date" or "Gezielte Lieferdatum" throughout your application. A PropertyText property would return a localized or user friendly text (if set). If the value is not set (PropertyText=String.Empty), the property returns the PropertyName. You use the PropertyText value (as opposed to PropertyName) for the description returned after evaluating rules.
Thus, in RuleArgs you have:
Private mPropertyText as String
''' <summary>
''' The human readable, localized name of the property.
''' </summary>
Public Property PropertyText() As String
Get
If mPropertyText Is Nothing OrElse mPropertyText = String.Empty Then
Return mPropertyName
Else
Return mPropertyText
End If
End Get
Set(ByVal Value As String)
mPropertyText = Value
End Set
End Property
And add a constructor
''' <summary>
''' Creates an instance of RuleArgs.
''' </summary>
''' <param name="propertyName">The name of the property to be validated.</param>
''' <param name="propertyText">The human readable, localized name the property to be validated.</param>
Public Sub New(ByVal propertyName As String, ByVal propertyText As String)
mPropertyName = propertyName
mPropertyText = propertyText
End Sub
You would change the CommonRules to use PropertyText instead of PropertyName.
For example in CommonRules you would change
Public Function StringRequired( _
ByVal target As Object, ByVal e As RuleArgs) As Boolean
Dim value As String = _
CStr(CallByName(target, e.PropertyName, CallType.Get))
If Len(value) = 0 Then
e.Description = _
String.Format(My.Resources.StringRequiredRule, e.PropertyText)
Return False
Else
Return True
End If
End Function
You would change the Functions and the constructors for the other CommonRules as well.
I still need to think about e.StopProcessing. I have a feeling yet another method is necessary. The ability to completely defer the evaluation of a rule until either requested or before saving. I'll see if I can work up some code for what I mean.
From: Ben303 [mailto:cslanet@lhotka.net]
Sent: Tuesday, August 01, 2006 8:38 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Version 2.1 (VB only) available for testingRocky, could you please extend the RuleArgs to contain a PropertyText property?
With the current structure it is difficult to localize user oriented texts within the rules framework. For example you might have a property called TargetDelivery that is labeled "Target delivery date" or "Gezielte Lieferdatum" throughout your application. A PropertyText property would return a localized or user friendly text (if set). If the value is not set (PropertyText=String.Empty), the property returns the PropertyName. You use the PropertyText value (as opposed to PropertyName) for the description returned after evaluating rules.
----- Original Message -----
From: xal
To: "rocky@lhotka.net"
Subject: Re: [CSLA .NET] RE: Version 2.1 (VB only) available for testing
Date: Thu, 03 Aug 2006 13:54:18 -0500
Hey Rocky, I found an issue...
Public Sub CheckRules(ByVal propertyName As String)
Dim rules As ValidationRulesManager = RulesToCheck
If rules IsNot Nothing Then
Dim list As List(Of IRuleMethod) = rules.GetRulesForProperty(propertyName, False).GetList(True)
If list IsNot Nothing Then
CheckRules(list)
End If
End If
End Sub
The bold code fragment could return null if you call rules for a property that doesn't have any... That's what the "If list IsNot Nothing" is for,,, but at the end of that bold fragment you do a .GetList(True) and that throws a null reference exception.
Maybe you can call a SortList() method ca ll inside the If and before CheckRules(list)...
Andrés
Would it be possible to turn on the XML comments by default in the C# project? I do not know if it is on by default in the VB project.
From: Brian Criswell [mailto:cslanet@lhotka.net]
Sent: Saturday, August 05, 2006 2:10 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: Version 2.1 (VB only) available for testing
Copyright (c) Marimer LLC