> Alex, please don't take this to be picking on you; this
> is more a post to
> everyone whom reads these forums.
>
> You are not writing procedural, object-oriented, or
> functional code. You are
> writing rules to look for patterns of objects. If
> everything is done in an
> eval you are losing the majority of the benefits of using a
> rule engine, e.g
> node sharing, indexing, etc. Flesh out your object model.
> Assert all of your
> objects into Working Memory. This will allow you to reason
> over anything
> without using evals.
>
> OK -- rant off --
>
> Alex, you may want to try and refactor your model to be
> more "rules
> friendly". That way your could write rules more like
> the following.
>
> when
> $f : Fact()
> Detail(name == "END_SET", value == true)
> Detail(name == "SET", value = 1)
> Detail(name == "PLAYER1_SCORE", $score1 :
> value)
> Detail(name == "PLAYER2_SCORE', value <
> $score1)
>
> On Tue, Feb 24, 2009 at 12:39 PM, Zevenbergen, Alex <
>
azevenbergen@paddypower.com> wrote:
>
> > Thanks for replying.
> >
> >
> >
> > rule "Player 1 wins first set "
> >
> > when
> >
> > $f : Fact()
> >
> > eval
> ($f.getDetails().get("END_SET").toString() ==
> "true" &&
> Integer.valueOf($f.getDetails().get("SET").toString())
> > == 1 &&
> Integer.valueOf($f.getDetails().get("PLAYER1_SCORE").toString())
> >
> >
> Integer.valueOf($f.getDetails().get("PLAYER2_SCORE").toString()))
> >
> > then
> >
> > //then settle selection;
> >
> > end
> >
> >
> >
> >
> >
> > this rules runs perfectly as long as the hashmap
> contained in the ‘fact’
> > object has all the required keys and their values are
> not null. For the time
> > being I have just changed any null values to a value
> of ‘DEFAULT’ but it
> > would be preferable to be able to look for
> f.getDetails().get("END_SET") (for
> > example) knowing that the engine that sent it might
> not be in an end_set
> > state so may not have added that key.
> >
> >
> >
> > That example is very basic but as I create more rules
> for more sports it
> > could become very cumbersome to have to ensure that
> every key referenced in
> > the rules is in the hashmap each time!
> >
> >
> >
> > Alex
> > ------------------------------
> >
> > *From:*
rules-dev-bounces@lists.jboss.org [mailto:
> >
rules-dev-bounces@lists.jboss.org] *On Behalf Of
> *David Sinclair
> > *Sent:* 24 February 2009 17:27
> > *To:* Rules Dev List
> > *Subject:* Re: [rules-dev] Dealing with null pointer
> exceptions thrown by
> > parsing rules
> >
> >
> >
> > I understand what you are saying Alex, but could you
> post an example rule
> > to see exactly how you are doing it? It may be that
> you could simply rewrite
> > the rule so you don't get the NPE.
> >
> > On Tue, Feb 24, 2009 at 4:24 AM, Zevenbergen, Alex
> <
> >
azevenbergen@paddypower.com> wrote:
> >
> > Hi all,
> >
> >
> >
> > I have started writing my rules packages and so have
> had a decent amount of
> > success. However all my rules are based on value pairs
> from a hashmap object
> > that is contained within my fact object. This approach
> works fine if the
> > parameter the rule is looking for is in the map and
> has a value.
> >
> >
> >
> > But I will need to be able to pass null values to the
> rules (and expect
> > them to just not fire any rule that looks for that
> param), however this
> > always throws a null pointer exception.
> >
> >
> >
> > So my question is: Is there any mechanism to deal with
> this in drools.
> >
> >
> >
> > Simply setting all nulls to a default value isn’t
> preferable in this
> > situation as the app is going to be used by several
> different sources and
> > has to be able to take in many different types of
> info.
> >
> >
> >
> > Thanking you,
> >
> >
> >
> > Alex
> >
> >
> >
> ________________________________________________________________________
> > Privileged, confidential and/or copyright information
> may be contained in
> > this communication. This e-mail and any files
> transmitted with it are
> > confidential and intended solely for the use of the
> individual or entity to
> > whom they are addressed. If you are not the intended
> addressee, you may not
> > copy, forward, disclose or otherwise use this e-mail
> or any part of it in
> > any way whatsoever. To do so is prohibited and may be
> unlawful. If you have
> > received this email in error
> > please notify the sender immediately.
> >
> > Paddy Power PLC may monitor the content of e-mail sent
> and received for the
> > purpose of ensuring compliance with its policies and
> procedures.
> >
> > Paddy Power plc, Airton House, Airton Road, Tallaght,
> Dublin 24 Registered
> > in Ireland: 16956
> >
> ________________________________________________________________________
> >
> >
> > _______________________________________________
> > rules-dev mailing list
> >
rules-dev@lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> >
> >
> ________________________________________________________________________
> > Privileged, confidential and/or copyright information
> may be contained in
> > this communication. This e-mail and any files
> transmitted with it are
> > confidential and intended solely for the use of the
> individual or entity to
> > whom they are addressed. If you are not the intended
> addressee, you may not
> > copy, forward, disclose or otherwise use this e-mail
> or any part of it in
> > any way whatsoever. To do so is prohibited and may be
> unlawful. If you have
> > received this email in error
> > please notify the sender immediately.
> >
> > Paddy Power PLC may monitor the content of e-mail sent
> and received for the
> > purpose of ensuring compliance with its policies and
> procedures.
> >
> > Paddy Power plc, Airton House, Airton Road, Tallaght,
> Dublin 24 Registered
> > in Ireland: 16956
> >
> ________________________________________________________________________
> >
> > _______________________________________________
> > rules-dev mailing list
> >
rules-dev@lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> _______________________________________________
> rules-dev mailing list
>
rules-dev@lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev