Hi,
 
3.0.5 documentation states:-
 
You can access fields either by using the bean-name convention (so "getType" can be accessed as "type"). For example, refering to our Cheese class, the following : Cheese(type == ...) uses the getType() method on the a cheese instance. You can also access non getter methods, like "toString()" on the Object for instance (in which case, you do Cheese(toString == ..) - you use the full name of the method with correct capitalisation, but not brackets).
 
You're example Map(name == 'myName') only checked for the existence too.
 
Sorry if I misunderstood your requirement.
 
Cheers,
 
Mike
 

From: rules-users-bounces@lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Olenin, Vladimir (MOH)
Sent: 22 February 2007 18:59
To: Rules Users List
Subject: RE: [rules-users] talking about new features...

This will just check if MyMapSubClass contains the entry (which I think would not work anyways, since ‘entrySet’ does not comply to POJO spec).

 

From: rules-users-bounces@lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Anstis, Michael (M.)
Sent: 22 February 2007 12:14
To: Rules Users List
Subject: RE: [rules-users] talking about new features...

 

Can this not be achieved by using a Map's entrySet property?

 

$o : MyMapSubClass( entrySet contains 'myName' );

 

From: rules-users-bounces@lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Olenin, Vladimir (MOH)
Sent: 22 February 2007 16:17
To: Rules Users List
Subject: [rules-users] talking about new features...

Hi,

 

Talking about new features to be included in the new release, I think the most compelling might be the ability to use Maps as facts (ie, from the point of view of a complete DROOLS newbie). Technically POJO is a Map with some restricted functionality (can’t count properties, check for property existence, etc). Is it really a big change? The rule formulation will remain the same from what I understand and the LHS like

 

            Map(name == ‘myName’)

 

Will simply mean any map object which has a key ‘name’ and value for the key is ‘myName’. The ‘type matching’ feature would be kind of less useful in case Map fact is used, but this can probably solved through introducing some default ‘type’ key which Map object should have and in a very simplistic implementation just include ‘type’ as a constraint.

 

Another alternative (which might probably be more ‘backward compatible’ with existing implementation) is to dynamically generate POJOs from Map definition. ‘type’ or ‘class’ key will correspond to a full qualified class name, all other keys found in the map – POJOs properties. Or ‘type’ can stay ‘anonymous’ – might be useful in some cases as well….

 

The ‘weakly defined’ fact objects might be quite useful in some cases, eg when rules ‘cross cut’ business domain. Kind of ‘dynamic rules’ J.

 

 

Vlad