Web Rule Version 4.0.0.47 Beta is Released

The first beta of Web Rule 4.x has been released and is ready for public testing. You can find links to its stand-alone CodeEffects.Rule.dll assembly and our standard demo projects that reference the beta in the References section below.

The 4.0.0.47 build released today includes a preview of three new features - setters, multiple actions and the while loop. More features will become available for public testing as they are developed and tested internally. At the end of this post I'll list all features that are currently in development.

• Multiple Actions. As you know, Web Rule versions 3.x and earlier limit rule authors to only one action per rule section. Version 4.x removes this limitation and allows rule authors to invoke as many rule actions in a single section as needed. Obviously, the same actions can be reused in multiple sections of the same rule or in different rules. Both the external actions and the actions defined in source objects are supported. Here is an example:

  If ZIP code is "30040" then
  	Set Discount(5.95) and
  	Notify("Your discount is approved!")

  All actions are visually "connected" together using the and clause. Each action will be invoked during rule evaluation in the order it is declared in the section. As always, the rule editor suggests the allowed menu options in the proper places.


• Value Setters. Value setters allow rule authors to set the values of a source object's fields within the rule section based on the outcome of that section. You can have as many value setters per section as you need and you can mix them with rule actions. Here is an example:

  If ZIP code is "30040" then
  	set Discount to 5.95 and
  	set Modified to True and
  	Notify("Your discount is approved!")

  As you can see, this rule sets the values of the discount-related fields and invokes the Notify action, all in the same section. Fields of all data types supported by Web Rule can be set inside of the rule.


• While Loop. Version 4.x comes with a great new feature that allows any .NET code to run an instance of a source object against a single rule continuously in a loop until conditions of the rule return False. For now, we've given this feature the internal code name "The Loop". It is very likely that we'll change its name when the final 4.0 is released. You are quite welcome to suggest a final name for this feature by posting comments. Here is the rule syntax:

  While Count is less than [1000]
  	do set Count to { Count + [10] } and
  	Report iteration ( Count )

  As you can see from this example, the loop logically supports only one section (no else ifs or elses) with any number of setters and actions allowed. You can run the loop indefinitely (this is the default setting of all Evaluator classes) or limit the maximum number of iterations before Web Rule exits the loop:

  // Get the rule XML
  string ruleXml = this.ruleControl.GetRuleXml();
   
  // Create a new Evaluator instance and pass it rule XML and max number of iterations
  Evaluator<Patient> evaluator = new Evaluator<Patient>(ruleXml, null, 1000);

  Each of our evaluation classes has an overload of its public constructor that takes the max number of iterations as an optional param. Again, its default value is -1 which causes Web Rule to loop through the same rule until it returns False.
  
  To create a "while" rule you need to set the Mode of your RuleEditor to RuleType.Loop.
  
  ASP.NET:

  <rule:RuleEditor ID="ruleControl" runat="server"
  	SourceAssembly="CodeEffects.Rule.Demo.Asp"
  	SourceType="CodeEffects.Rule.Demo.Asp.Common.Data.Patient"
  	Mode="Loop" />

  MVC:

  @{
  	Html.CodeEffects().RuleEditor()
  		.Id("ruleEditor")
  		.SaveAction("Save", "Post")
  		.DeleteAction("Delete", "Post")
  		.LoadAction("Load", "Post")
  		.Mode(RuleType.Loop)
  		.Rule(ViewBag.Rule)
  		.Render();
  }

  Note that because the final name of the whole feature is not defined yet, we might change the name of the RuleType.Loop enum member in the final release.
  
  Anyway, please try this feature out and let us know what you think about its implementation. As always, any suggestions, feature requests, or concerns are quite welcome.


• New Rule XML Schema. New features required a new Rule XML schema. The schema used by this beta version is already published and can be found here. Version 4.x is still in development, therefore we might (and most likely will) change this schema by the time 4.0 is released. All existing rules that use the current schema should work fine in 4.x, no updates or edits of Rule XML are necessary. Let us know if you experience any issues in this area.

I would stop typing right here. But almost every day we get questions like "When are you going to release 4.0?" or "You said that 4.0 was going to be released in February!!" So, let's talk about features that we might include in future betas of 4.x and its final release. I said "might" for several reasons:

• We have lots of new features in the pipeline. Obviously, we would love to implement all of them as soon as humanly possible. The problem is that we have customers whose entire business depends on how well Web Rule is running. We simply cannot afford to release poorly implemented features - it could be too costly for them and for us. Therefore, we will take time to research and assess each new feature. We will talk to you. We may even abandon almost-developed features if we feel that they are not something that we or you are comfortable with.


• A lot of features that we develop for Web Rule are unique. We simply don't have competitors' products to look at, code samples to examine, or resources to implement in order to know from the very beginning how Web Rule should function. Often, we have to invent pieces of functionality from scratch. This takes time. Sometimes a lot of time. And we are not going to rush things. We know that a lot of companies are waiting for the final release of 4.x in order to decide if Web Rule is the right tool for them to use in their projects. However, we will delay the release even at the expense of potentially loosing those companies to a competitor if we feel that more time would give us the better product.


• It is extremely hard to find new people in order to develop new stuff faster. Boy, did we try... Instead of hiring, we got rid of all our contractors, and we won't consider any new members for our team unless we're certain they'll be a real asset and won't drag us down. So, the infamous saying "This is a 100 man/hour project. There are one hundred of you here. So, I expect this to be done in an hour." will never happen at Code Effects. But, as you can imagine, this situation does not exactly increase the speed of our production :)

So, now that you are familiar with our development policy, consider the following features as potential candidates for inclusion in the final release (of course, we welcome all your thoughts and suggestions related to this list):

• IN and NOT IN operators. This is an often-requested feature that is very likely to be included in 4.0.


• Field and action grouping. Source objects can be quite large, sometimes containing dozens, if not hundreds, of fields, in-rule methods and actions. Grouping would help categorize those fields and actions in editor menus. Currently, we plan to add a new property called Group to the FieldAttribute and all similar attributes. Rule authors would first select a group from the menu. The menu would then display all fields from that group, ready to be selected. This feature is likely to be included in 4.0.


• IEnumerable and IQueriable support. Long overdue, this feature is coming. We are still debating details, though. That's why this feature wasn't included in this beta.


• Dynamic source factory. This is a big one. All of our Source-licensed customers have requested this feature. Basically, when implemented, it'll allow you to define/set source objects without actually having or knowing their type. Using this factory, you'll be able to tell Web Rule "Hey, my source will have property ID of type int, Name of type string, and action DoSomething with signature (int, string, bool)." No typed sources or Source XML will be needed. Freedom in its pure .NET form :) Not sure when this will be available, though.


• Multiple sources per rule. This will be especially huge for those companies that use Web Rule as a LINQ data filter. Together with IQueriable support, this feature will allow us to deliver the first super data filter. Imagine that a visitor to your online store would like to search for all TVs that have a screen size larger than 60 inches or all DVD players that have Blu-Ray. Instead of presenting the user with a long menu of all TV and DVD fields, Web Rule will use two sources, TV and DVD, for the same editor. The editor will know which options should be in the current menu based on what's already in the filter. This is a far fetched feature plan, but we are determined to make it happened.


• Miscellaneous items. Things like menu icons, more robust .NET culture support, new match and does not match string operators, and more will be considered for inclusion in 4.0 based on the current time frame and the state of more important new features. If not in 4.0, most of those smaller features will be implemented in minor versions of 4.x, or moved toward 5.0 dates.

One last thing: Thank you for your understanding and patience!