Wumpus World Update

I made further progress with Wumpus World today, as previously blogged here. The project is checked into drools-examples, execute "WumpusWorldServer" to run.
-larger sensor icons
-bump and scream sensors added
-left, right buttons now rotate left and rotate right.
-hero faces direction based on rotation
-can now shoot arrows
-wumpus can die

Wumpus World

I've just committed a working version of Wumpus World, an AI example covered in in the book "Artificial Intelligence : A Modern Approach". It's not complete yet, as I still need to add the ability to shoot arrows and to clumb out of the cave. But the rest of it is there and working.

When the game first starst all the cells are greyed out. As you walk around they become visible. The cave has pitts, a wumpus and gold. When you are next to a pittt you will feel a breeze, when you are next to the wumpus you will smell a stench and see glitter when next to gold. The sensor icons are shown above the move buttons. If you walk into a pitt or the wumpus, you die.

Here are the slides that I used in my presentation for Wumpus World, along with a demo, at Judcon India 2012. The code will be part of 5.4 beta 2 going out today/tomorrow.

A more detailed overview of Wumpus World can be found here.










asdf

Guided Decision Tables - An update

The guided decision table editor in Guvnor has come a long way since it was first added to Guvnor in 2008 so I thought it worth while consolidating the efforts we've made into a short summary so those unfamiliar with recent developments can re-consider what a powerful tool Guvnor now posses.

The editor in 2008

Complete re-write

When Guvnor moved from GWT-EXT to vanilla GWT we took the opportunity to re-write the entire editor. GWT's table widgets did not offer the flexibility we wanted to provide users in their authoring environment: We wanted users to be able to quickly and easily build tables enabling them to concentrate on their rules rather than data-entry. Thus the new editor was born offering keyboard or mouse navigation, in-cell editing together with merging and grouping of cells.

The editor as it is today



Guided construction

To make the initial definition process as pain-free as possible we added a Wizard to walk users through creation. The Wizard also offers users the ability to generate an expanded form table.

The wizard



Merging

Merging of cells combines cells with identical values into one; thus providing a quick way to change the value of multiple cells in a single operation (of course, you could equally select multiple-cells with either a mouse-drag operation or keyboard but we felt merging minimized the process). Merging was also the precursor to grouping of cells, a powerful facility to collapse sections of the table whilst authoring.

Merged cells



Grouping

Merged cells can be collapsed into one. All editing operations continue to work as normal: copying-pasting rows and editing cell values etc. The only difference being that you can effectively hide sections of the table. Copying and pasting a grouped row also offers a convenient way to duplicate sections of the table (before editing as appropriate).

Grouped cells



Extended and Limited Entry

What type of decision table editor would we have without offering both Extended Entry and Limited Entry? Extended entry allows constraint and action values to be defined in the table body; whereas Limited entry moves the entire definition to the column itself with the body simply allowing the user to define which constraints and/or actions apply.

Limited Entry



Analysis

Support has been added to detect mistakes in your decision table. Currently we detect 2 types of problem and want to add many more.

• Impossible matches
• Conflict detection

Conflict detection



Integration of jBPM work items

Rules are frequently used from within jBPM to drive dynamic processes. What better then than providing a means for jBPM Work Items to be used in your rules' consequences? Work Item input parameters can be bound to Facts or their properties and likewise output parameters used to populate Facts.


Use of BRL fragments

Column definitions have historically only been able to offer a thin veil of abstraction. With the introduction of BRL fragments, columns can be defined using the full range of Guvnor's guided rule authoring capabilities (including DSL) which, coupled with Limited Entry, allows a higher level of abstraction to be realized.

A BRL fragment column



Roadmap

Whilst, you might agree, significant progress has been made made there is still a long way to go. There still is a tremendous amount of work we want to complete before feeling our decision table offering is as complete as we'd like.

• Round-trip between Excel and Guvnor
• Improved integration of V&V to provide visual feedback
• Further V&V to check conflict, completeness, ambiguity, subsumption etc
  
• Expansion and contraction
• Enforcement of multi-hit and single-hit variants
  
• Typed input of default values and lists of permitted values for Conditions
• Pluggable editors for domain types
  
• Column and row drag and drop
• Horizontal decision table
• Integration of WorkingSets

jBPM Form Builder roadmap

Greetings from Argentina. This post will try to cover a general view of where the form builder is right now and where it is going to be in the near future. You can get a current status view from the video below:



On this video you can see a great deal of how the form builder works today. It doesn't cover the jBPM console integration part or the automatic form generation option, but it allows you to see how users will experience working with the form builder. To download the project, you can find it in the following locations

Nightly builds

• https://github.com/marianbuenosayres/jbpm
• https://github.com/marianbuenosayres/guvnor

In the next few days, I'll start keeping a stable release on this other address as well:

• https://github.com/marianbuenosayres2/jbpm
• https://github.com/marianbuenosayres2/guvnor

Feel free to download, comment or join. That pretty much covers where the form builder is right now. As to where it is heading, here's an initial roadmap

jBPM Form Builder Roadmap

1. Adding HTML5 templates: Current items work with pure GWT and HTML4 for Freemarker. The idea is to build a new renderer that will allow users to export to Freemarker as well, but allowing them to export using HTML5 instead of HTML4 to create the forms. The idea as well is to create as many menu options to properly cover HTML5 capabilities, such as audio and video tags, menus, fieldsets and so on.
2. Adding new validations: Current validations cover basic concepts, like number or email validation. The idea is to expand and improve validation definitions, in order to allow both client side and server side validation to any level of complexity. Among new validations that are thought to be added, there will be regular expression validation, multi-field validations (applied directly to the form), and rules-based validation (in order to define a ruleflow-group specially to validate the correctness of input data)
3. Adding script helpers to add dynamic ui components on client side: Script helpers are shown in the video above. They allow a user with very little knowledge of javascript to create scripting solutions for UI component's event handling. The idea is to create a new script helper to allow javascript to add a new visual component on a particular layout and layout position when an event happens.
4. Cleaning up effects and form items library: Current implementations of form items (the UI components you drop on your form) and form effects (the actions available when you right click on a form item) are done in a way that could be made configurable with a proper refactor. The whole idea is to make it more easily extensible, minimizing the amount of code to be added to create a right click action for UI components, or a UI component itself.
5. Adding tests for effects and form items library: Along with the previous item, some refactoring will be made to allow a better separation of display logic from actions logic, in order to create better test prepareness on the code side. Along with that, proper tests will be implemented for the form items and effects library.
6. Adding server validation to the generated form's API: Extension of the form utility API used from jBPM console, to handle validations on server side. 
7. Adding server interpretation of complex objects to the generated form's API: Currently, all form submit responses are treated like a map of simple data. The idea is to create complex object associations to particular paths in the form definition, in order to create the proper objects on submit time. This will benefit both user task definitions and rule-based form validations.
8. Adding template management for complex objects for the generated form's inputs: The previous item covers submit to server rendering of request data, from simple data types to complex data types. This item covers the other way around, for when a user task is given a complex type and needs to decompose it to make it available for form input data. It will allow the user to define paths within an object when defining form inputs.
9. Improvement of properties edition panel to add better coverage of properties for form items: This comes in hand with item 4. Once a proper management of form item properties is done, there will be a need for a better way of editing such properties.
10. Improvement on tree and edition panel visualization: Bug fixing and visual highlighting in the current form are two of the main things to be tackled by this bullet.
11. Allow switching layouts once they're filled without losing content: Currently, once you define a layout and start adding content to it, the only way to change layouts is to create a new one and move all the content manually. This item is thought to be able to do that automatically.
12. Adding script helpers to allow onEvent simple validations on client side: Along with validation library expansion and server validation API, this item is thought to allow some validations to happen on the client side, to be handled on particular events (i.e. like on the change of value of an input field)
13. Pagination items: Create UI components that would allow to create very large forms within several pages, all part of the same form.
14. Definition of a standard page layout for a given user or role: Most companies have a template structure for most of their forms (wether it has a logo on a particular place, a standard stylesheet, etc). The idea is to allow designers to define such page layout and force its use to either some people or a group of people within the company.
15. Definition of standard UI visualization strategies for particular types of data: This is to aid the automatic form generation. The idea is to allow users to define, for example, the standard way to create visual content for Strings, Integers, Booleans and so on. It should cover complex data types as well.
16. New translators and renderers for JSF, XUL, Android, IPhone and Swing: Among other technologies, this would be a nice subset to cover. The order of the technologies and the omission of any don't express any priority whatsoever.
17. Adding effects to allow loading contents from an ajax script or from an array variable: This way, content from a form could be loaded from an external source from the client side.
18. Importing of inputs from other external sources: Right now the only way to import inputs on the IO Data tab is to have them defined inside a BPMN2 process. The idea is to be able to take them from a server invocation, a user file, or any other way. This will also allow to define forms for other platforms different than the BPM engine.

Cheers,
Mariano

Guided Decision Table - Copying\pasting rows

Before starting the next big feature, I relaxed a bit (Mark will kill me ;-) ) and added the ability to copy and paste rows in the guided Decision Table editor in Guvnor.

This feature comes to the Template Data grid for free.



Video here.

Project Idea: Debug Helper

Have a great project for any intrepid rule exlorers. The project itself is not too difficult and will make it really easy for people to get an idea for what is going on inside of the engine. The below is an early concept idea sketched out, don't take it as a spec to be rigidly followed :) You know where to find us if you want mentoring on this task:
http://www.jboss.org/drools/irc

While the rule itself is named, patterns are not. By allowing patterns themselves to take on ids, we can specify capture points. This is already possible for rule terminal nodes via listeners for rule activation, but users would still need to write their own handlers. The proposal here is to write a utility that will capture propagations during a given start/stop period that users can later inspect for both activations and join attempts. This will allow users to know exactly what is happening underneath.

Blow shows a rule with 3 potential capture points:

package pkg1

rule r1 when then
   Person( name == "xxx" ) @id(p1)
   Location( name == "xxx" ) @id(l1)
then
end

1) The terminal node, via the rule name.
2) p1
2) l1

The idea is to be able to turn on monitor, that has a start(), stop() and clear() methods. When started it will capture the insert, update, retract propagations. Further it should be possible to write assertion utility to assert on the state of the captured information.

When capture is turned on for a given capture point it will record a List of instances. As different nodes have different data, there is a base node and a child node. Every time a propagation happens an instance is created and added to the montior representing the current state.

BaseCapture
   NodeType nodeType       // enum for join, exists, not etc to allow  for casting to correct node
   String nodeName           // enum for join, exists, not etc
   Collection
 rules   // Rules is a collection, as the node  might be shared
   Activation activation      // Activation at the root of the WM  operation (may be null, if the acion came from outside of the wm).
   FactHandle[] f                // fact at the root of the working  memory operation
   FactHandle[] fh              // fact[] that entered the node

JoinCaptire extends BaseCapture
   Direction direction              // Left/Right enum
   FactHandle[] successJoins // the opposite fact handles that were  successfully joined with, during this montioring session
   FactHandle[] failedJoins    // the opposite fact handles that were  unsuccessfully joined with, during this monitoring session.
                                                //Note if the  propagation was from the left the join arrays will all be an length of 1.
RulePropagation extends BasePropagation
   RuleStatus status        // Matched, UnMatched, Fired

For example lets say I want to monitor the propagations on l1 and r1, that happens during two working memory actions. I can do the following:

ksession.insert( new Person("darth"));
fh = ksession.insert( new Location("death star));
NodeMonitor l1monitor = ksession.getMonitor("pkg1/r1/l1")
NodeMonitor r1monitor = ksession.getMonitor("pkg1/r1")
l1monitor.start();
r1monitor.start();
ksession.insert( new Person("yoda));
ksession.retract( fh );
l2monitor.start();
r2monitor.start();

List props = l1monitor.getResults(JoinCapture.class);
List props = r1monitor.getResults(RuleCapture.class);

l1monitor will show left propagation for yoda and a successful join for death star
r1 will have two entries. It will show a match (activation creation) but it will also show an unmatch, due to the retract.

Fine Grained Property Change Listeners (Slot Specific) (Mario Fusco)

Just a quick recap of what I did until now to check if we are all on the same page and also agree with the naming convention I used.

The property specific feature is off by default in order to make the behavior of the rule engine backward compatible with the former releases. If you want to activate it on a specific bean you have to annotate it with @propSpecific. This annotation works both on drl type declarations:

declare Person
@propSpecific
firstName : String
lastName : String
end

and on Java classes:

@PropSpecific
public static class Person {
private String firstName;
private String lastName;
}

Moreover on Java classes you can also annotate any method to say that its invocation actually modifies other properties. For instance in the former Person class you could have a method like:

@Modifies( "firstName, lastName" )
public void setName(String name) {
String[] names = name.split("\\s");
this.firstName = names[0];
this.lastName = names[1];
}

That means that if a rule has a RHS like the following:

modify($person) { setName("Mario Fusco") }

it will correctly recognize that both the firstName and lastName have been modified and act accordingly. Of course the @Modifies annotation on a method has no effect if the declaring class isn't annotated with @PropSpecific.

The third annotation I have introduced is on patterns and allows you to modify the inferred set of properties "listened" by it. So, for example, you can annotate a pattern in the LHS of a rule like:

Person( firstName == $expectedFirstName ) @watch( lastName ) // --> listens for changes on both firstName (inferred) and lastName
Person( firstName == $expectedFirstName ) @watch( * ) // --> listens for all the properties of the Person bean
Person( firstName == $expectedFirstName ) @watch( lastName, !firstName ) // --> listens for changes on lastName and explicitly exclude firstName
Person( firstName == $expectedFirstName ) @watch( *, !age ) // --> listens for changes on all the properties except the age one

Once again this annotation has no effect if the corresponding pattern's type hasn't been annotated with @PropSpecific.

I've almost finished with the development of this feature (at the moment I am missing the compile-time check of the properties named in the @watch annotation together with some more exhaustive tests), so if you think that I misunderstood something or there is room for any improvement (or you just don't like the annotation's names I chose) please let me know as soon as possible.

Mario

Fine Grained Property Change Listeners (Slot Specific)

Mario just got a first cut working for fine grained property change listeners. Previously when you call update() it will trigger revaluation of all Patterns of the matching object type in the knowledeg base.

As some have found this can be a problem, forcing you to split up your objects into smaller 1 to 1 objects, to avoid unwanted evaluation of objects - i.e. recursion or excessive evaluation problems.

The new approach now means the pattern's will only react to fields constrained or bound inside of the pattern. This will help with performance and recursion and avoid artificial object splitting. We previously discussed this here:
http://blog.athico.com/2010/07/slot-specific-and-refraction.html
You can see the unit test here:
https://github.com/droolsjbpm/drools/blob/ca55c78429cbc0f14167c604c413cdc3faaf6988/drools-compiler/src/test/java/org/drools/integrationtests/MiscTest.java

The implementation is bit mask based, so very efficient. When the engine executes a modify statement it uses a bit mask of fields being changed, the pattern will only respond if it has an overlapping bit mask. This does not work for update(), and is one of the reason why we promote modify() as it encapsulates the field changes within the statement. You can follow Mario's chain of work on this at his github activity feed:
https://github.com/mariofusco.atom

The adventerous amoung you can pick this up from hudson, or from maven, and start playing now. My hope is that this will make drools much easier to use:
https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/drools-distribution/target/
Btw we are after a name. Drools is not a frame based system, so "slot specific" doesn't seem appropropriate. Property Specific seems a bit of a mouth full. I'm quite liking High Fidelity Change Listeners :) any other suggestions?

slot-specific is the name used by Jess for this feature, . It's also the standard way that Clips COOL works, which is the Clips OO module. Although that's partly a side effect of the triple representation of properties used in COOL, and the modifications are triple based. I don't know what mechanism Jess is using to enable this.

Mark

jBPM Form Builder follow-up

Greetings! Among the things developed over the last two weeks for the jBPM Form Builder, here are the ones worth mentioning:

Script helper refactor: Some of the classes had issues when being stored on the server side, due to dependencies with GWT client-side classes. A small refactor was made to make them GWT independent, and utilize the GWT API from a particular view object to render on screen.
User roles implemented: JAAS implementations for JBoss and Jetty are available now as stated in my last post. The jBPM Installer inside my fork has the necessary implementations for JBoss, and the Jetty implementations are available to start up the project from the Debug mode in the Eclipse Plugin. Profiles are created as described previously: web designer and functional analyst. Web designer has all the functions available (can define forms, custom menu items and use any item available), while functional analyst can only define forms using the menu items authorized by the web designer.

The whole idea behind these components will be to facilitate web designers to administrate component standarization from inside the form builder.
And here's some of the next items on the to do list:

HTML5 templates: Current form generation templates for Freemarker work with HTML4. There will be a new set of them that will use HTML5, which will probably lead to new menu items to fully cover HTML5 components.
More script helpers: Current script helpers allow to make an easy implementation of an ajax service call, a combobox population ajax call, and to toggle visualization of  a particular component (selected by id). There will be more script helpers, focused on creating new visual components on runtime and live validation of fields. And that's where the next one falls in
More validations: We had a few simple validations to start checking where to store them and what to do with them. Now that they seem to reach a plateau where no major refactor is needed, it is a good moment to start adding a lot more validations to the ones that are already there.

That will be all for now. Cheers!

Mariano

Guided Decision Table supports BRL columns

Work has been completed to allow BRL fragments to be used as both (or either) Condition and Action columns in the Guided Decision Table within Guvnor.

You can see the feature in action here and read more about it below.

Adding a BRL column



A BRL fragment is a section of a rule created using Guvnor's (BRL) Guided Rule Editor: Condition columns permit the definition of "WHEN" sections and Action columns the definition of "THEN" sections. Fields defined therein as "Template Keys" become columns in the decision table.

A Condition BRL fragment



An Action BRL fragment



Consequently any rule that could be defined with the (BRL) Guided Rule Editor can now be defined with a decision table; including free-format DRL and DSL Sentences.

BRL fragments are fully integrated with other columns in the decision table, so that a Pattern or field defined in a regular column can be referenced in the BRL fragments and vice-versa.

A decision table with BRL fragments and regular columns



Source from BRL fragments