Try this:
(clear)
;;
;; There's no need for an artificial fact to trigger some initial
processing.
;;
(defrule assert-request-parameters-rule
"Assert stored data one time."
(declare (salience 100))
;; implied: (eval true)
=>
(foreach ?key (((fetch request-parameter-map) keySet) iterator)
;; produce an assert and eval it
(eval (str-cat "(assert (" ?key " " ((fetch request-parameter-map) get
?key) "))" ) )
)
)
(defrule got-one
(one ?val)
=>
(printout t "one has the value " ?val crlf)
)
(bind ?map (new java.util.HashMap))
(?map put one 1)
(?map put two 2)
(?map put three 3)
(store request-parameter-map ?map)
(reset)
(run)
(facts)
On 14 August 2010 04:15, Donald Winston <[email protected]> wrote:
> I just don't want to have to write a lot of Java code to support he use of
> the rule engine. I realize now I can use the rete.store() to store a Map
> and put the data in the fact base. I just have to know the keys when I'm
> coding the rules and use
>
> (assert (param-name ?param-value))
>
> I cannot do this:
> (assert (?param-name ?param-value))
>
> correct?
>
> I can also assert unordered facts by using slot names for the keys and use
> one template for the map instead of creating a lot of little facts
> vertically.
>
> I don't mind changing the rules when the data changes. I do mind having to
> modify java classes every time some new data is added or deleted.
>
> I've used the Blaze Advisor rule engine before. We passed a large hash
> table of data to it and created the initial fact base for the rules. We
> passed data back to the app the same way after applying the rules.
>
> On Aug 13, 2010, at 2:41 PM, Wolfgang Laun wrote:
>
> Donald,
>
> Assuming you could assert facts from Map.Entry resulting in simple ordered
> facts such as
> (key value) you'd still have to adjust the rules to each change in the key
> set. This is usually more demanding than adding another deftemplate.
>
> In a map all keys are necessarily distinct. This would mean that you create
> as many different fact types as there are entries. It's difficult to see how
> you can write rules for this setup (but my bean might be too bean-oriented
> to see that.)
>
> Anyway, you can always (in Java) iterate over the key set, write a simple
> .clp file containing a deftemplate for each key and slurp this file in
> (using (batch)) from your "main" .clp file.
>
> Also, you have the option of defining a single fact type (ordered or
> unordered) for two values, say
> (deftemplate Entry (slot key) (slot value))
> and assert all your Map.Entry things as such. (Rules will have an unusual
> look-and-feel.)
>
> BTW, to execute an (assert ...) from a string you'd have to call (eval).
> Function (build) is for constructs, i.e., deftemplate, defrule, and cousins.
>
> Finally, I have the uncanny feeling that whatever you are trying to solve
> with this approach might be better solved in a fundamentally different way.
> But that's just a feeling, like Swing ;-)
>
> HTH
> -W
>
>
>
> On 13 August 2010 19:27, Donald Winston <[email protected]> wrote:
>
>> ok. Thanks. I won't bother you anymore about this issue. It looks like the
>> proper way to do what I want is to use the Jess java api and create ordered
>> facts from my map using the Fact class and assert them after the rules.clp
>> file has been loaded instead of just storing the map from my java app. (I
>> was looking to minimize the use of the java api when working with the rule
>> engine, but this doesn't look too bad)
>>
>> On Aug 13, 2010, at 11:59 AM, Ernest Friedman-Hill wrote:
>>
>> > Java classes are totally optional in Jess -- in fact, templates and
>> facts created directly from the Jess language are always more efficient.
>> >
>> > If Jess were to store the properties of an object in a Map -- so that
>> they were dynamic and extensible at runtime -- then it would be considerably
>> slower, for the same reason that fully dynamic languages in which objects
>> are maps of code and variables are slower than compiled languages.
>> Construction of a fast Rete network requires knowing what properties are
>> being dealt with. Think of a database in which all the data was stored as
>> object-attribute-value triples -- would it be as fast as a database with
>> fixed tables and columns?
>> >
>> >
>> > On Aug 13, 2010, at 11:41 AM, Donald Winston wrote:
>> >
>> >> So I have to create a template and know all the identifiers before
>> loading data into the fact base? This means I'll have to create java bean
>> objects for all my data. Every time the data changes I'll have to modify the
>> java classes. I don't believe in creating objects for things that have
>> little or no behavior. That's what Maps and Lists are for.
>> >>
>> >> I suppose I could generate a "init-facts.clp" file when my app starts
>> up and load it along with the rules.
>> >>
>> >> On Aug 13, 2010, at 11:18 AM, Ernest Friedman-Hill wrote:
>> >>
>> >>> Basically for the same reason that you can't say something like this
>> in Java:
>> >>>
>> >>> String theMethodName = "toString";
>> >>> String myString = myObject.(theMethodName)();
>> >>>
>> >>> but instead you have to use reflection to find the method "toString"
>> and call it using the Method object. The compiler needs to know the correct
>> template to use to compile the code, and it can't do that if the name of the
>> template is in a variable.
>> >>>
>> >>> Now, you may ask *could* it work the way you want? Indeed, it could --
>> but it doesn't at this time. We've talked in the past about allowing this
>> kind of thing, and it has its pros and cons.
>> >>>
>> >>>
>> >>> On Aug 13, 2010, at 11:05 AM, Donald Winston wrote:
>> >>>
>> >>>> Can anyone explain to me why this does not work? Why can't I use
>> >>>>
>> >>>> (deffacts initial-facts
>> >>>> "Facts to trigger a few appropriate salient initialization rules."
>> >>>> (assert-request-parameters))
>> >>>>
>> >>>> (defrule assert-request-parameters-rule
>> >>>> "Assert stored data one time."
>> >>>> (declare (salience 100))
>> >>>> ?x <- (assert-request-parameters)
>> >>>> =>
>> >>>> (foreach ?key (((fetch request-parameter-map) keySet) iterator)
>> >>>> (build str-cat "(assert (" ?key " " ((fetch
>> request-parameter-map) get ?key) "))"))
>> >>>> ; why not (assert (?key ((fetch request-parameter-map) get
>> ?key))))
>> >>>> (retract ?x))
>> >>>>
>> >>>> (bind ?map (new java.util.HashMap))
>> >>>> (?map put one 1)
>> >>>> (?map put two 2)
>> >>>> (?map put three 3)
>> >>>> (store request-parameter-map ?map)
>> >>>> (reset)
>> >>>> (facts)
>> >>>> (run)
>> >>>> (facts)
>> >>>>
>> >>>> Jess, the Rule Engine for the Java Platform
>> >>>> Copyright (C) 2008 Sandia Corporation
>> >>>> Jess Version 7.1p2 11/5/2008
>> >>>>
>> >>>> This copy of Jess will expire in 207 day(s).
>> >>>> f-0 (MAIN::initial-fact)
>> >>>> f-1 (MAIN::assert-request-parameters)
>> >>>> For a total of 2 facts in module MAIN.
>> >>>>
>> >>>> f-0 (MAIN::initial-fact)
>> >>>> For a total of 1 facts in module MAIN.
>> >>>
>> >>> ---------------------------------------------------------
>> >>> Ernest Friedman-Hill
>> >>> Informatics & Decision Sciences, Sandia National Laboratories
>> >>> PO Box 969, MS 9012, Livermore, CA 94550
>> >>> http://www.jessrules.com
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --------------------------------------------------------------------
>> >>> To unsubscribe, send the words 'unsubscribe jess-users
>> [email protected]'
>> >>> in the BODY of a message to [email protected], NOT to the list
>> >>> (use your own address!) List problems? Notify
>> [email protected].
>> >>> --------------------------------------------------------------------
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> --------------------------------------------------------------------
>> >> To unsubscribe, send the words 'unsubscribe jess-users [email protected]
>> '
>> >> in the BODY of a message to [email protected], NOT to the list
>> >> (use your own address!) List problems? Notify
>> [email protected].
>> >> --------------------------------------------------------------------
>> >
>> > ---------------------------------------------------------
>> > Ernest Friedman-Hill
>> > Informatics & Decision Sciences Phone: (925) 294-2154
>> > Sandia National Labs
>> > PO Box 969, MS 9012 [email protected]
>> > Livermore, CA 94550
>> http://www.jessrules.com
>> >
>> >
>> >
>> >
>> >
>> > --------------------------------------------------------------------
>> > To unsubscribe, send the words 'unsubscribe jess-users [email protected]'
>> > in the BODY of a message to [email protected], NOT to the list
>> > (use your own address!) List problems? Notify
>> [email protected].
>> > --------------------------------------------------------------------
>> >
>>
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> To unsubscribe, send the words 'unsubscribe jess-users [email protected]'
>> in the BODY of a message to [email protected], NOT to the list
>> (use your own address!) List problems? Notify [email protected]
>> .
>> --------------------------------------------------------------------
>>
>>
>
>
