[jboss-jira] [JBoss JIRA] (JBRULES-3330) Provide MoveFilter for generic factories

[Geoffrey De Smet (JIRA)]

    [ https://issues.jboss.org/browse/JBRULES-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669345#comment-12669345 ] 

Geoffrey De Smet commented on JBRULES-3330:
-------------------------------------------

This issue is probably mostly obsolete (or a long term minor issue) once we have generic selectors instead of generic move factories and they are also far more configurable:

{code}
<selector>
  <type>CHANGE_MOVE</>
  <planningEntityClassIncludes>...</>
  <planningVariableIncludes>...</>
  <isDoableFilterClass>...MyIsDoableFilterClass</>
{code}
                
> Provide MoveFilter for generic factories
> ----------------------------------------
>
>                 Key: JBRULES-3330
>                 URL: https://issues.jboss.org/browse/JBRULES-3330
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-planner
>    Affects Versions: 5.4.0.Beta1
>            Reporter: Lukáš Petrovický
>            Assignee: Geoffrey De Smet
>
> At the moment, generic factories are far too generic - for most of the problems, an optimization can be found so that the amount of reasonable moves is significantly reduced. The intention is to allow customization of the generic move factories, while still using all their power. Generic move factory simply produces every possible move and the user defines, in a MoveFilter, which of them shouldn't be passed to the planner. The feature could work like this:
> 1. An interface is introduced, called eg. MoveFilter<T extends Move>. This interface declares one method - boolean filter(Solution solution, T move). This method accepts the solution of the MoveFactory, as well as the Move object that's been created by the MoveFactory. It returns true if the GenericMove should be included in the createMoveList() method of the MoveFactory, false otherwise. 
> (Please make sure that the MoveFilter type is generic, so that filter() always knows the correct type of the move without the user doing any magic or assumptions. This would most probably require making MoveFactory generic as well, but that could be useful.)
> 2. Implementations of the MoveFilter interface are annotated with @MoveFilter(factory = [SomeMoveFactory.class, SomeOtherMoveFactory.class]). This annotation would specify to which move factory this filter should be related. Some checks should be put in place that the annotation will only work when the MoveFilter and MoveFactory share the same Move type.
> 3. The same as in (2) can be achieved by specifying filters in the XML configuration of the solver, altough I personally don't like the XML configs much.
> 4. MoveFactory's createMoveList() method is enhanced so that it runs user-specified MoveFilters and excludes the filtered moves from the resulting MoveList.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira