Moving 3.6 -> 4.0 child object changes not causing business rules to fire in list's parent.

Moving 3.6 -> 4.0 child object changes not causing business rules to fire in list's parent.

Old forum URL: forums.lhotka.net/forums/t/9391.aspx


Jeff Flowerday posted on Tuesday, August 17, 2010

I have a business list as a property of a parent object.  I have a couple business rules that fire on changes to this list.  All was fine in 3.6 they fired but now that I've moved to 4.0 changes to children object in these lists don't cause the rule(s) to fire.

Any idea where to start looking?

My rules are firing for my simple properties, just not child changes in my list property.

I've removed my AddNewCore implementation all togethor from the BusinessListBase implementation allowing the default one to fire.

ajj3085 replied on Tuesday, August 17, 2010

How were you listening for events?  Are you overridding OnChildChanged?

Jeff Flowerday replied on Wednesday, August 18, 2010

I'm not listening to events.   Nor am overriding OnChildChanged.

I'm simply attaching a business rule to a businesslist managed property.  Expecting the rule to fire if I change a property of a child in that list.

Jeff Flowerday replied on Wednesday, August 18, 2010

ChildChanged isn't firing when I change a property of a child object which explains why the business rule isn't firing. 

I've confirmed I'm using SetProperty.  Not sure what I'm missing but it is getting frustrating...

RockfordLhotka replied on Wednesday, August 18, 2010

Are you using a managed backing field for the child object reference?

Jeff Flowerday replied on Thursday, August 19, 2010

Yes managed.

RockfordLhotka replied on Saturday, August 21, 2010

I'm not sure what you are missing either. I have specific unit tests that establish that ChildChanged is raised when a child object's property changes, so I'm pretty sure it works in general. There must be some quirk to your specific scenario that's causing an issue.

Try simplifying the scenario to replace the issue and see if you can identify the specific cause.

Jeff Flowerday replied on Wednesday, August 25, 2010

If I override the OnChildChanged in the parent, I can then force a BusinessRules.CheckRules(ChildListProperty).  Both list and actual child object change events happen in OnChildChanged and I can easily catch only the actual child changes.

But if I don't override OnChildChanged in the parent and force a checkrules the business rules that have the ChildListProperty as the PrimaryProperty won't fire when a child of the ChildList is changed?

RockfordLhotka replied on Wednesday, August 25, 2010

That is correct.

It is funny, this has never really come up quite this way - and here we have two threads (there was another one just a couple weeks ago) where someone expected rules to run based on ChildChanged.

And it is a good idea. As I said in the other thread, I'm not entirely convinced that this is the majority scenario - which is why I've never automated the behavior. But now I'm starting to rethink my position - to the point that I've added this to the wish list anyway.

Copyright (c) Marimer LLC