This is a design document for the GSoC project for refactoring of rules.

Requirement

To be able to refactor rules source - specifically change the name of a field, or fact type.

This needs to work on all source rule formats (drl, dsl, brl (xml), xls and so on)...

Implementation Design

The implementation will be on a new project called drools-assistant that will contain all the rules refactoring features. The major feature will be the posibility to add more refactor rule modules instead the initial DRL & DSL module that will be implemented, with this you will have the posibility to develop brl, xmls, etc Rules extra modules that you could integrate with the Eclipse Drools Plugin and Guvnor with a common interface. Also this can be easily integrated on maybe another future IDEs (Flex? Netbeans plugin? who know's) because is totally decoupled of the IDE.

The alma matter of the refactor module will be the editors hability of text replacement, just as the suggestion feature is working right now on the Drools plugin. The output will consist on a collection of objects containing the text to replace and the offset, just simple like that, so with this data you can integrate on another editors on a easy way.

Features to implement

• Variable binding: Give to the user the posibility to create automatically a binding variable, which can be used on other constraints and in the RHS.

• Variable rename: As the name says, the objective is rename a selected variable with a new name  in all the rule. Similar to the feature that the Eclipe Java Editor brings with Java variables.

• Parameters order to improve the performance: The objective is suggest changing the parameters orders in a constraint, moving on the most restrictives to the left creating a more efficient rule. This can be a little hard to implement, and maybe the results will not be the best ones.

• Cross products detection: Maybe another hard one.

• Join/Linking variable suggestion: This feature will analyze the object types relationships, suggesting the possible links/filters between objects.

• Organize Imports: Implement the same feature that the Eclipse Java Editor brings to the user. Letting us add imports based on the classes used inside the LHS and removing imports that aren't used.

• NICE to have: cope with renaming of fact classes if triggered from eclipse but not in the DRL editor.
  

Initial Class Diagram

<TODO: upload class diagram>

How integrate extra rule refactor modules?

This can be just extending AbstractRuleRefactor class and implementing the code, also you are going to need extra objects with the rule parsed to identify the contents. More details coming soon.

Eclipse plugin integration

The refactoring options will be appear in the same contextual menu used into the autocompletion feature.

Guvnor integration

Guvnor isn't the most used ide to create rules for a developer point of view. The integration isn't necesary into this proyect propossal, but will be integrated with a GWT Panel and the users could select all the refactoring options that desires.