What you describe can be done with /bin/sed.
Notice that the DSL processor doesn't require you to translate entire
patterns; there is a mechanism for translating "keywords", which is
just arbitrary tokens to whatever replacement text.
If a "bar" must be translated to a "barList" in the context of a
class
"Foo" but not in any other context, a more sophisticated translation
is required in any case (with /bin/sed still being sufficient if
patterns aren't split across lines).
Some say that good design makes use of Interfaces, which leaves room
for actual implementations being changed as long as the interfaces are
implemented. Here, note that rules can be written against interface
types.
-W
On 26/05/2014, Péter Gergely, Horváth <h.peter(a)mailbox.hu> wrote:
Hi All,
We are evaluating Drools 6 for our use case, and face challenges where we
would need some ideas from more experienced users of Drools.
We have an application with a massive code base and a large number of model
(entity) classes. We are in the process of moving away from inherited
legacy technologies and refactoring the old code base. As a part of this
work we would like extract some of the hard-coded business logic to
external rules, that is why we are looking at Drools as a potential
solution.
What we would like to have is some kind of abstraction or mapping between
actual entities and rules the business users can define so that they do not
have to know the _exact_ details of the data model (field names, precise
relations etc). This would be important for us so that we can refactor the
old model classes without affecting business rules; also it would make life
easier for the business users. While IDE support might make refactoring
easier, we definitely want to have a separation between rules and entities.
Given our situation, writing and maintaining "stable" wrapper/adapter
classes for the sole purpose of rule processing is out of question. I have
checked the documentation of Drools DSL support and for me it seems to be
overkill for our use case: we do not really need a custom language, but
simply an abstraction between rules and the data model classes.
What I could imagine is a piece of code, (a custom property resolver? - no
sure how it is called) which maps property expressions to actual properties
based on a custom annotation on the entity class or something like that, so
that a rule containing "Foo.bars" expression does not have to change even
if we decide to rename "Foo.bars" to "Foo.barList" in the model
classes.
(This was just a simple example of a potential use cases)
Could you please share your thoughts on this topic and point me into the
right direction?
Thanks,
Peter