Hi Justin, It's always nice to reply to somebody who has taken the time to try things and learn the application.
I've added a couple of other points below. With kind regards, Mike On 6 July 2011 22:48, Justin Case <[email protected]> wrote: > Thank you Michael for your quick answer :) I certainly hope there will be > somewhere some answer to the other points as well. > > >You can use a predicate within a pattern by selecting "Predicate" as the > >Condition Column type. These compile to inline evals. It is not however > >possible to define a predicate that is not part of a pattern. > > No idea what these are :) but I'll definitely look into them. > > >If, in your example, $var and $date are constants you could look into > using a > >Template instead of Decision Table. You'll find there is greater > flexibility to > >what DRL you can define. > > I noticed I can create Templates, but I didn't think about them in that way > (templates MORE flexible??). Worth a try indeed. > IMO Templates in Guvnor are, currently, more flexible than Decision Tables simply because they allow you to define (almost) any DRL whereas the DRL possible from a Decision Table is more restricted. We have a long list of improvements we want to make to guided Decision Tables which, once complete, will make them a vastly more powerful authoring tool. > > >The community edition (i.e. Guvnor, not JBoss BRMS) has translations for > es_ES, > > >fr_FR, ja_JP, pt_BR, zh_CN and en_US. GWT compiles the resources away into > >JScript. Depending upon your locale GWT will only dispatch the relevant > bundles > >to your browser. > > I have the Guvnor (not JBoss BRMS) and can't see any of them. Not even the > Constants.properties which should be the "regular" language file... > Where do these guys get their files??? I (and my folks) would gladly share > the > translation - if we ever come to do one. > > You won't find the files in what is downloaded to your browser because GWT compiles them into its .cache files in /guvnor-webapp-5.3.0-SNAPSHOT/org.drools.guvnor.Guvnor folder. The message sources are available in the org.drools.guvnor.client.messages package. > >I find this observation strange, as the JAR is just stored as a BLOB in > JCR and > >the latest version retrieved to build suggestions available for rule > authoring. > >There are however known issues, logged in JIRA, with Validation not > clearing > >down correctly which could lead to what you report. > > Indeed the validation might be a cause, or it's not only the Validator > leaving > old skeletons behind :) A few days ago a teammate of me showed me the > problem in > 5.2.0.M1 AND ALSO showed be a dialog list with the actual model classes AND > the > old class, saying "hey but I can remove it from here and it verifies ok". > Now we > all upgragded to 5.2.0.Final and we can't find that dialog anymore :( I > kind of > miss it anyway, it would always be nice to see what classes you have in > your > uploaded model. Did 5.2.0.Final remove it? > > If you can provide a screen-shot it might nudge people's memory better? Unfortunately mine is blank. > >Not in my experience. I often upload POJO JARs (with 5.2 at least) and am > able > >to work with the classes defined therein without a restart. > > Might have to do with the above problem anyway... > > >I suspect you are accessing the > >"Declarative Model" resources from a Guvnor repository using the Eclipse > WebDAV > > >facilities (given the context of your surrounding questions). AFAIK, > Declarative > > > >models are not available this way - they are stored on the Asset in the > >repository using XStream to serialise the internal object graph to XML. It > might > > > >however be an interesting idea to provide a means to retrieve their DRL > >equivalent through WebDAV. If you'd like to pursue this please raise a > JIRA > >capturing your requirement and details of your specification. > > Correct, this is what I was expecting: some support from the Eclipse Guvnor > plugin. I can imagine however that this would be just priority pit-bottom > on the > developers todo list :) > > >Why is this a problem? As you say the field, presumably privately called > >"aThing" is accessible via the getter "AThing"? > >Does your DRL not compile? > > Well this is not a "real" problem, it works also this way. But the field > should > look like all others: the "getMyField()" accessor of the Java POJO will > show > "myField", but "getAThing()" will show "AThing" - notice the different > capitalization. > > Thank you, > JC > > _______________________________________________ > 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
