Re: [rules-dev] Fine Grained Property Change Listeners (Slot Specific)
Op 18-01-12 11:00, Wolfgang Laun schreef:
On 18/01/2012, Geoffrey De Smet<ge0ffrey.spam(a)gmail.com>
wrote:
> throw new IllegalStateException("The factClass (" + factClass +
")
> has a property (" + property + ") that has a @Modifies annotation, but
> the class isn't annotated with @PropSpecific.");
Use less words:
"In class (" + factClass + ") property (" + property + ") is
annotated
with @Modifies, but the class isn't annotated with @PropSpecific."
+1
However, there's a good case for permitting this: testing to try
both
ways, to track down a (user) bug,... Commenting out @PropSpecific is
just like turning off the main switch. If you get errors, you'll have
to mess with all the @Modifies, too.
-1 The other case, where a user adds @Modifies
but forgets to add
@PropSpecific and then sees in production that drools doesn't behave as
expected (it just ignores the @Modifies) is worse imo.
> 2) @Modifies( "firstName, lastName" ) should not put the comma (,)
> inside the quotes. Go for:
> @Modifies( "firstName", "lastName" )
Then it must be:
@Modifies( { "firstName", "lastName" } )
Yep, true. Not
sure if that still allows to use @Modifies("firstname").
Anyway, I still think we need to use a new annotation to combine
multiple @Modifies annotations,
to avoid the other problems (2 modifies that have different other
values, such a ifImplementsClass)
and specific annotations implementation limitations (you can't define
the same annotation twice on 1 method).
It's Mario's call.
> 3) What's the point of doing a @PropSpecific on a field instead of a class?
>> declare Person
>> @propSpecific
>> firstName : String
The answer is: DRL syntax requires it this way.
ah yes, my bad. Confusing though
:)
Cheers
Wolfgang
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet