Re: [rules-users] Declarative fact model or Java?

In alternative, if you want total decoupling, you can define /interfaces/ that your classes extend, and write the rules against the interfaces, rather than the classes. This might help when you have different formats and improves the portability of your rule base. The classes would have to implement interfaces statically, so it can be done conveniently if you need to create your fact classes anyway. The drawback is that you can't to that so easily if you don't have access to the source code. We provided "traits" to add interfaces (a) to individual instances rather than whole classes, or (b) to attach an interface to a class which does not implement it. One bit which is missing, now that I realize, is the possibility to have declared classes implement DECLARED*** interfaces statically (anyone willing to open a JIRA request? I'm feeling lazy right now :) ) D. [Beware: arguable and debatable content below:] Remark : In a perfect world, the rules should just process "logical facts", i.e. data stored within pure beans. Behavior (methods) other assertions/retractions/updates should be provided in a controlled way, either using different, dedicated facts or globals. If this level of "purity" can be attained, among other things, debugging and rule analysis becomes much more feasible. -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-Declarative-fact-model-or-J... Sent from the Drools: User forum mailing list archive at Nabble.com.