Given that the section in the Guvnor manual on using DSLs is 4 lines of text
and a graphic which really doesn't show the potential, it would be easily
missed. :)
Also you need to look at the "DSL editor" section of the Guvnor manual for the
DSL syntax for defining enumerations in the DSL sentences.
To get enums in a DSL is pretty simple. you just use the syntax:
{varName:ENUM:enumName}
i.e.
[condition][]validate specific currency "{ccy:ENUM:Currency.isoCode}"=
$exposure: CurrencyExposure($ccy: currency == "{ccy}")
It's a bit of a shame it's so well hidden, as it's one of the few features of
Guvnor that's helpful for non-technical users. It can make guided rules
incredibly easy to write and read. The only thing is, it's fairly tricky to
learn your way around it. And the syntax isn't too nice. It has the unfortunate
feature of requiring that every condition is written on a single line. That
doesn't seem too bad when you look at some of the examples, but I have written
DSL sentences which involve lines of code which are more than 1000 characters
long. Not the nicest things to maintain, but well worth it in terms of the
power and simplicity it offers to users.
tip - Don't bother using the DSL editor in Guvnor or in Eclipse. in 5.5 it
doesn't actually work (bug has since been fixed), and any plain text editor is
better anyway.
On 12 Aug 2013, at 15:51, Mark Bennett <[email protected]> wrote:
>
> On Aug 11, 2013, at 2:30 PM, Stephen Masters <[email protected]>
> wrote:
>
>> Embedding Guvnor just means that you hide the top-level interface, and embed
>> the guided editor into your web app. So if you're not fond of the guided
>> editor, then embedding doesn't solve the problem.
>>
>> How far did you get into DSLs? When used within the guided editor, you get a
>> list of DSL phrases to choose from, and having picked one, users can just
>> drop values into the slots you make available in the templates, and you can
>> provide enums to populate drop-down lists. It's fairly close to what you're
>> after.
>
> Wow, I hadn't seen that in any of the reading I did, even in the books I
> looked at. Maybe it's at the very end of a DSL section that I never got to.
> Thanks.
>
>>
>> Generally with Guvnor, you do need a team of users who are pretty open to
>> the rather over-technical guided editor UI that it offers, with all its
>> Java-influenced package structures. The competition such as FICO Blaze and
>> IBM/ILOG JRules do a better job here, *if* you're prepared to spend the
>> money and spend the time learning your way around their IDEs for designing
>> templates.
>>
>> If you're up for spending the time on it, you can build your own UI to
>> generate DRL, and use the Guvnor REST interface to upload the rules. That
>> way, you can potentially get whatever UI you like, but it's a lot of work.
>>
>> Depending on your taste for adventure, another option would be to check out
>> the version 6 betas. The new workbench supposedly provides much more in the
>> way of customisation options. Check out Mark Proctor's presentation here,
>> for some of what it offers:
>> http://docs.jboss.org/drools/blog/LondonJBUG2013rulesmarkp/assets/fallback/index.html
>>
>> Steve
>>
>>
>> On 11 Aug 2013, at 21:09, Mark Bennett <[email protected]> wrote:
>>
>>> 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 / [email protected]
>>> Office: 408-898-4201 / Telecommute: 408-733-0387 / Cell: 408-829-6513
>>>
>>> On Aug 10, 2013, at 2:14 AM, Stephen Masters <[email protected]>
>>> 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 <[email protected]> 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 / [email protected]
>>>>> Office: 408-898-4201 / Telecommute: 408-733-0387 / Cell: 408-829-6513
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rules-users mailing list
>>>>> [email protected]
>>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> [email protected]
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> [email protected]
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>> _______________________________________________
>> rules-users mailing list
>> [email protected]
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
> _______________________________________________
> rules-users mailing list
> [email protected]
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
