<div dir="ltr">Hi Davide,<div><br></div><div>Drools trait functionality is one of the powerful concepts which makes Drools a good candidate for the project. So keep up the good work! :) However I'm not sure if its current level of flexibility would be sufficient for our use case. I've checked the documentation, but haven't really found the term virtual field -- could you please elaborate on this?</div>
<div><br></div><div>Do you think we could somehow hook into the evaluation of the aliases or the "fields" Map? Sometimes you would need slightly more than merely aliasing fields to something else; e.g. calculating values for the purpose of rule processing or extracting a value from a more complex object tree etc. Citing the example -- GoldenCustomer( fields[ "age" ] > 18 ) -- being able to get a reference to the target object and the field map expression "age" would be quite close to what I imagined. Our custom code could then perform the appropriate translation and return the requested value, hiding the fact whether "age" is an actual field in the Customer object itself/retrieved from an encapsulated complex object e.g. replacing expression "customer.personalInformation.birthData.age"/calculated on the flight. </div>
<div><br></div><div>What do you think?</div><div><br></div><div>Cheers,</div><div>Peter</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-26 17:58 GMT+02:00 Davide Sottara <span dir="ltr"><<a href="mailto:dsotty@gmail.com" target="_blank">dsotty@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We are working on the trait framework for cases like this. Essentially,<br>
it allows to use<br>
interfaces when writing rules AND to inject the interfaces dynamically<br>
at runtime,<br>
at the instance level. It relies on transparent proxies which wrap the<br>
data classes<br>
and implement the required interfaces. A simple field aliasing mechanism<br>
is provided<br>
(work in progress). For more complex transformations, "virtual" fields<br>
can be added.<br>
See section 7.7.8 of the manual for more details and let me know if it<br>
can help<br>
with your use case.<br>
Best,<br>
Davide<br>
<div class="HOEnZb"><div class="h5"><br>
On 05/26/2014 09:55 AM, Wolfgang Laun wrote:<br>
> Even a relatively sophisticated transformation would be easier to implement<br>
> and most certainly safer from changes in the unstable Drools API than some<br>
> hook-and-intercept mechanism built into Drools.<br>
><br>
> Notice that violent structural departure of the model the BUs see from what<br>
> you call "persistence model" might make it impossible for the BUs to come<br>
> up with rules that can be transformed to match the other model at all;<br>
> if it is possible, rules might still incur a heavy performance penalty.<br>
><br>
> It is (IMHO) a myth that "Rules" is a foolproof way of establishing<br>
> business logic<br>
> independent from the data model and application environment with which<br>
> this logic should be able to cooperate. As long as everything is kept in the<br>
> abstract (i.e., formulated in terms of mathematics) it will look good, but<br>
> any implementation may throw a spanner in the works, or worse.<br>
><br>
> -W<br>
><br>
> On 26/05/2014, Péter Gergely, Horváth <<a href="mailto:h.peter@mailbox.hu">h.peter@mailbox.hu</a>> wrote:<br>
>> Hi Wolfgang,<br>
>><br>
>> Thank you for your input. You are right that some of the cases could simply<br>
>> be covered by regexp-replace, but I'm afraid, not all of them. Interfaces<br>
>> could also help, but we have a requirement that the business rules should<br>
>> not be tightly coupled to the underlying persistence model. (I understand<br>
>> that some might say this is not ideal, but that is our current situation)<br>
>><br>
>> I am wondering whether it is possible to hook into Drools engine and<br>
>> intercept field value reference expression evaluations in run time (e.g if<br>
>> "foo.bars" is used in an expression, we could return "foo.barList") ? By<br>
>> injecting some custom code, we could make the necessary decisions and<br>
>> extract the proper value from an object. Unfortunately these parts of<br>
>> Drools are pretty much undocumented.<br>
>><br>
>> Regards,<br>
>> Peter<br>
>><br>
>><br>
>><br>
>> 2014-05-26 13:57 GMT+02:00 Wolfgang Laun <<a href="mailto:wolfgang.laun@gmail.com">wolfgang.laun@gmail.com</a>>:<br>
>><br>
>>> What you describe can be done with /bin/sed.<br>
>>><br>
>>> Notice that the DSL processor doesn't require you to translate entire<br>
>>> patterns; there is a mechanism for translating "keywords", which is<br>
>>> just arbitrary tokens to whatever replacement text.<br>
>>><br>
>>> If a "bar" must be translated to a "barList" in the context of a class<br>
>>> "Foo" but not in any other context, a more sophisticated translation<br>
>>> is required in any case (with /bin/sed still being sufficient if<br>
>>> patterns aren't split across lines).<br>
>>><br>
>>> Some say that good design makes use of Interfaces, which leaves room<br>
>>> for actual implementations being changed as long as the interfaces are<br>
>>> implemented. Here, note that rules can be written against interface<br>
>>> types.<br>
>>><br>
>>> -W<br>
>>><br>
>>><br>
>>> On 26/05/2014, Péter Gergely, Horváth <<a href="mailto:h.peter@mailbox.hu">h.peter@mailbox.hu</a>> wrote:<br>
>>>> Hi All,<br>
>>>><br>
>>>> We are evaluating Drools 6 for our use case, and face challenges where<br>
>>>> we<br>
>>>> would need some ideas from more experienced users of Drools.<br>
>>>><br>
>>>> We have an application with a massive code base and a large number of<br>
>>> model<br>
>>>> (entity) classes. We are in the process of moving away from inherited<br>
>>>> legacy technologies and refactoring the old code base. As a part of<br>
>>>> this<br>
>>>> work we would like extract some of the hard-coded business logic to<br>
>>>> external rules, that is why we are looking at Drools as a potential<br>
>>>> solution.<br>
>>>><br>
>>>> What we would like to have is some kind of abstraction or mapping<br>
>>>> between<br>
>>>> actual entities and rules the business users can define so that they do<br>
>>> not<br>
>>>> have to know the _exact_ details of the data model (field names,<br>
>>>> precise<br>
>>>> relations etc). This would be important for us so that we can refactor<br>
>>> the<br>
>>>> old model classes without affecting business rules; also it would make<br>
>>> life<br>
>>>> easier for the business users. While IDE support might make refactoring<br>
>>>> easier, we definitely want to have a separation between rules and<br>
>>> entities.<br>
>>>> Given our situation, writing and maintaining "stable" wrapper/adapter<br>
>>>> classes for the sole purpose of rule processing is out of question. I<br>
>>> have<br>
>>>> checked the documentation of Drools DSL support and for me it seems to<br>
>>>> be<br>
>>>> overkill for our use case: we do not really need a custom language, but<br>
>>>> simply an abstraction between rules and the data model classes.<br>
>>>><br>
>>>> What I could imagine is a piece of code, (a custom property resolver? -<br>
>>> no<br>
>>>> sure how it is called) which maps property expressions to actual<br>
>>> properties<br>
>>>> based on a custom annotation on the entity class or something like<br>
>>>> that,<br>
>>> so<br>
>>>> that a rule containing "Foo.bars" expression does not have to change<br>
>>>> even<br>
>>>> if we decide to rename "Foo.bars" to "Foo.barList" in the model<br>
>>>> classes.<br>
>>>> (This was just a simple example of a potential use cases)<br>
>>>><br>
>>>> Could you please share your thoughts on this topic and point me into<br>
>>>> the<br>
>>>> right direction?<br>
>>>><br>
>>>> Thanks,<br>
>>>> Peter<br>
>>>><br>
>>> _______________________________________________<br>
>>> rules-users mailing list<br>
>>> <a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
>>><br>
> _______________________________________________<br>
> rules-users mailing list<br>
> <a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
><br>
<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</div></div></blockquote></div><br></div>