Madura Rules is an optional plugin to Madura Objects. It handles more complex rules than what you can say in XSD syntax. The rules are specified in a RUL file and look a lot like Java code, deliberately so that Java programmers can write them easily. Here are some examples of what they can do:
Expression in the rules can be arbitrarily complex so the rules can get much more complicated than these. They implement various predefines functions to turn fields to required if they weren’t already (or back to not-required) etc. There are also list processing functions to sum and count items in lists of objects (like the list of order items) attached to an object. You can add your of functions if you want to.
‘Truth’ is always maintained by the rules engine, so if you set a value which causes the rules to derive another value, and then change the original value back, then the derived value will be unwound automatically.
Using Madura Objects we mentioned using enums to generate a list of valid values for a dropdown field. Madura rules implements decision tables. These can be loaded with all valid combinations for several multi-choice fields. For example say you are specifying a pizza with a base, a topping and a size (small, medium, large). In a real pizza shop you would likely be able to order any combination of those. But what if some technical reason (or marketing reason) meant that the shop did not want to sell large seafood topping pizzas. Maybe they went through the topping too fast, or maybe they found the gluten-free base really tasted nasty with the seafood topping.
Wouldn’t it be nice if when the customer picked seafood topping in their online ordering system the gluten-free base disappeared from the choices on the base field and the only choice on the size was small? Or if they pick one of the other fields first and it is not compatible with seafood that choice goes away. That way every pizza that gets through the order process is a valid pizza. The shop doesn’t have to call back and explain that seafood and gluten-free taste bad etc. Madura Rules’ decision tables handles this situation easily. It can load decision tables from various sources including XML documents, database queries or something you build yourself.
Using the power of the rules alone you can implement directed questioning. Say you have a formula: bmi = weight / (height * height) and you want to find the value for the bmi. The formula is implemented as a rule and all the fields are on the same object (to keep it simple). You can launch a directed questioning operation which is effectively asking for the bmi value. The rules engine knows that it needs to find a value for weight. Now it may already have a value, this might not be the first thing this user did and it may have been entered or pulled from a database. But it if does not have a value it will be prompted for. Same with height. But it is more interesting than that. The formula needs those values in metric and people don’t always know their metric measures. So we might have other rules that deliver height converted from feet and inches, and weight converted from pounds. When the user is asked for metric height he can say ‘don’t know’ and the rules will try and find the height by conversion, which will result in another prompt, actually two: one for feet and one for inches. Eventually it will have enough data to figure the bmi.
Notice what happened here:
The advantages of all this should be obvious but let’s spell them out:
In addition we support configuring the application with Spring XML, Spring annotations and CDI.
Madura Rules is licensed with an AGPL which means you are free to use it in non-commercial applications and for commercial applications a commercial licence must be purchased. See the contact form to get in touch.