3:09 p.m.
Thanks Steve.
I'll check out dozer.
I did look at DSL's, but the emphasis is really on putting a UI on things.
Your advice on hold off baking in every single field also mirrors a point that was raised
on the team recently. Advanced users can always drop into DRL mode, etc.
Actually, Guvnor's guided rules isn't our ideal UI either. I think we were hoping
for more of a "wizard" toolkit where users select from a list of pre-existing
rules and fill in templates, at least as an option for new users. Then more advanced
users could jump out to the guided rules or even the expert / DRL rules mode. But
Guvnor's guided rules are still a pretty advanced UI for newcomers. It's kind of
funny, I think people assume that anything that has a "UI" is easy/obvious to
use, even for new users; I'm pretty sure we could all rattle off many counter-examples
from the software world. ;-)
Any thoughts on conjuring a simpler UI for truly "guided" rules creation? I
read that Guvnor could be embedded, but not sure that really helps either.
--
Mark Bennett / LucidWorks: Search & Big Data /
mark.bennett@lucidworks.com<mailto:mark.bennett@lucidworks.com>
Office: 408-898-4201 / Telecommute: 408-733-0387 / Cell: 408-829-6513
On Aug 10, 2013, at 2:14 AM, Stephen Masters
<stephen.masters@me.com<mailto:stephen.masters@me.com>>
wrote:
Your plan seems about right to me. When working in pure Drools, you don't always need
to do this. However, when working in Guvnor, I have always found it necessary to create a
simplified domain model for facts.
In Guvnor, you can bind variables to fields and drill in, but it's fiddly. Guided
rules are much more readable when they are dealing with matching bean-style facts with key
attributes available through simple getX() accessor methods. And of course you definitely
need the bean-style getX() methods.
The other thing to think about, is that when working with Guvnor, you should be avoiding
any dependencies on external classes from within your facts. Otherwise, you will need to
put everything on your Guvnor web server's class path, which totally messes with your
ability to upload fact model updates. Yet another reason to keep them simple.
So given that you're going with that plan, here are my tips for the lazy (like me)...
To help with simplifying your transformations, it may be worth looking at Dozer or
similar: http://dozer.sourceforge.net/
Personally, because I have often found that I'm doing things like mapping multiple
objects into a single fact, I tend to just do the mapping in straight Java code. It tends
not to be too painful, as I rarely find the need for bi-directional mappings. I don't
often need to get a fact back out of working memory. So although it feels a bit naughty, I
often avoid the fact-to-domain-object transform. :)
Think about what properties you really might want to write rules about. It's easy to
spend a huge amount of time writing a huge fact model, and transforms for every single
property of every class in your domain model. Truth is you probably won't write rules
that look at all of it. So have a think about whether you do need to map everything or
not. My tip here would be to follow a TDD approach. Look at what rules your users want to
write. You should find that the rules mostly follow certain stereotypes, so create rule
tests covering a representative selection of such stereotype (ensure coverage of all
unique fact attributes which are examined). Create a fact model which can satisfy those
tests. Create tests for transforming from your domain model to your fact model. Create
transforms to that fact model. Assuming you have a reasonably iterative environment, you
can add transforms for additional attributes when users have tried out the application and
come up with new rule stereotypes they would like to work with.
As an alternative (or to complement the above), take a look at DSLs. Each DSL phrase
becomes available in your guided editor, so you can have simple rule phrases which the
users can understand, but underneath, you can have code which is drilling into nested
objects.
I do hope that's helpful… :)
Steve
On 10 Aug 2013, at 00:47, Mark Bennett
<mark.bennett@lucidworks.com<mailto:mark.bennett@lucidworks.com>> wrote:
We want our domain experts to be able to create Guided Rules in Guvnor (5.5)
But Guvnor seems pretty limited about what it will accept, and how it will render it.
We're attempting to create adapter classes that will:
* Allow us to expose a rich set of fields and methods in UI
* Use as injected facts into the engine
Main issues we're having:
* Native objects are nested, but Guvnor seems to want shallow
* Our native objects can have different attributes (different schemas)
- And you can't say getField( fieldName )
* Some returned items can be multivalued, vs. singular
Our idea is:
* Have admin send a prototypical request & schema event into our native system
* Scrape and flatten that into a java class that exposes Guvnor friendly methods
* Send that class into Guvnor
* Keep a copy of that class to create instances of when injecting facts into the engine
Is there some type of easy way to map complex objects to/from the simpler Guvnor/Drools
model? Some type of reflection based mapper with some simple rules or a template?
We're wondering what others have done in this situation?
Thanks,
Mark
--
Mark Bennett / LucidWorks: Search & Big Data /
mark.bennett@lucidworks.com<mailto:mark.bennett@lucidworks.com>
Office: 408-898-4201 / Telecommute: 408-733-0387 / Cell: 408-829-6513
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users