<UPDATE 2>The filna beta of Web Rule 4.0 was released on October 15, 2013. Details are posted
here</UPDATE 2><UPDATE 1>We had a nasty bug in version 4.0.1.17 that prevented users from inputing params into in-rule methods and actions if the source object doesn't declare any dynamic menu sources. This bug was first reported by Darian (thank you!!) It's fixed in version 4.0.1.87 that can be downloaded from the References section below. Both demo projects that are linked there still use the "bugged" version 4.0.1.17.
Also, just wanted to mention that the IEnumerable support is currently in development at full speed. It is definitely going to be the coolest implementation of collection support in the industry! We hope to release the final beta of 4.0 that implements collections by the end of August. Please stay in touch.
And, as always, your feedback has been a huge help. Please keep it coming!
</UPDATE 1>This release is the further preparation of Web Rule for the upcoming support of
IEnumerable and
IQueryable interfaces. It also introduces several new features. You can download this beta and demo projects by clicking links in the References section below. The next beta of Web Rule will introduce the native support for collections. The new features include:
- Right Side In-rule Methods. This has been on our request list for quite some time. As you know, the current version of Web Rule does not support the use of in-rule methods as values. Version 4.0.1.17 allows you to do that. It also allows setting a field's value to the return of any in-rule method, provided that types of both the field and the return are the same (or at least they are both of numeric types - Web Rule provides an automatic boxing for numeric values.) For example, provided that you have a public .NET method Today() declared somewhere in your code that returns the System.DateTime value of today, you can now create a condition like this:
Check if Flight Date is Today
This version also allows the use of in-rule methods on both sides:Check if Get flight date( "ATL123" ) is Today
... where Today is the same Today() method used above and the GetFlightDate() is a method that returns a flight date by flight number. You can also set values of fields to return values of in-rule methods in the rule section setters, provided that both the field and the return are of the same value type (or at least they are both of numeric types.) This is how it looks like in execution type rules:If Something is "something" then set Date of registration to Today
This feature wasn't available in the first beta that introduced value setters.
- New Filter Extension Overloads. The current version of Web Rule and its support for rule-based data filtering suffers from the general inability to obtain the type of LINQ provider that is used to filter the data at the time of rule evaluation. In other words, we have no way of knowing if you use Linq-to-SQL, or LINQ-to-Entity, or any other LINQ provider when the Filter() extension is invoked from your code - .NET doesn't provide those types at the time when we need it.
The problem is that different LINQ providers have different implementations of .NET types and methods. For instance, you would think that at least providers that come with .NET framework generate the same SQL for the same methods when it comes to SQL parsing. Nope. The LINQ-to-SQL and LINQ-toEntity don't even support the same list of methods. And that causes big issues.
Consider the case sensitivity support in data filtering. It works flawlessly with LINQ-to-Object because the actual filtering happens in-memory and all .NET native types and all overloads of their methods are available for Web Rule to instantiate and invoke when and where they are needed. So, if any of your data source property of the System.String type is decorated with the FieldAttribute and sets its value of the StringComparison to one of the "case sensitive" options, Web Rule uses the overload of the System.String.ToString() method that takes the param of the StringComparison type. Because all overloads of all .NET types are available at the time of Filter invocation, Web Rule is able to filter your data in accordance with your settings.
At the same time, if you try to use case sensitivity in the same way using either LINQ-to-SQL or LINQ-to-Entity, your setting will be ignored by the current version of Web Rule. In certain cases you even get an exception. This happens because neither provider supports the overload of System.String.ToString() that takes string comparison option as a param when it comes to SQL generation.
In version 3.0 we begun playing an exiting game with Microsoft called "Guess which underlying LINQ type they are going to rename next?" We were trying to make a decision whether or not case sensitivity is supported by the currently used provider based on a hard-coded list of names of underlying types for each LINQ provider that Web Rule supports. We lost immediately, on the day when Microsoft released their next version of .NET. Pretty much all LINQ-to-Entity types from our list were either renamed or completely removed. For about three weeks our support queue experienced almost 300% increase in LINQ-related support requests. Poor Alex had to work almost 24/7 in those crazy days :) That was absolutely stupid idea on our part anyway. To be fare to Microsoft, they did declare all those types as either private or internal and they did not document either of those classes.
In version 4.0 we are going to fix this issue once and for all. Namely, we are going to put the decision making process on your shoulders, our fellow developer :) You will have to tell us which provider your code is using to filter your data. Today we only fight with that case sensitivity thing. Tomorrow other issues of the same nature may arise. For that reason we are introducing a new type called CodeEffects.Rule.Core.EvaluationParameters:public class EvaluationParameters
{
public string RuleId { get; set; }
public GetRuleDelegate RuleGetter { get; set; }
public LinqProviderType LINQProviderType { get; set; }
public EvaluationParameters() { }
}
The first two properties of this class represent the key parameters of all existing overloads of the Filter() method. In future versions we may deprecate most overloads in favor of just a couple of them - the empty one and the one that takes an instance of the EvaluationParameters.
The last property is of the new LinqProviderType type:public enum LinqProviderType
{
Default,
SQL,
Entities
}
Use its Default member to indicate that things in your code are fine the way they are and you don't want to mess with all that new stuff. Use this option in cases where your filtering rules are case insensitive. Obviously, this is the default value. Web Rule is still going to guess which provider is currently used. But this time it's different. Now we simply ignore any case sensitive settings if we can't tell the type of the provider when the Default member is used. Otherwise, use one of the other two members to tell Web Rule which provider is being used. Web Rule knows what methods your provider supports; it will call proper overloads of .ToString() when it's time to generate SQL that is performs a case sensitive string comparison.
By the way, all of this is related only to data filtering. Business rules evaluation in Web Rule works perfectly fine with any of your field settings.
- The Current Thread Culture Issue. You don't need to read any further if your code executes on a thread with "en-US" culture (the default culture on most US-based machines) or if you don't use any non-US formatting for date/time values. Otherwise, I have a great news for you. We finally found a way to properly format all date/time values on both the client and server based on the culture of the current thread. Reference this beta in your project(s), remove the "en-US" culture forcing code that Alex sent you and test your system by editing and evaluating a couple of rules. Everything should work fine now, no matter which culture your server is set to.
As always, we would like to
THANK YOU for your great support and patience! Please test this new beta and let us know if you have any feedback, questions or concerns.