Updating items in a list

Updating items in a list

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


greengumby posted on Tuesday, February 23, 2010

Hi,

I have the business case where I have a List(Grid) of BusinessBase with a bool Property of isMaster. (checkbox)

What I would like to happen is when they tick a checkbox it would loop through all the other items in the list and set them unticked.  (Should not persist this)

Now I know I could create a ValidationRule and make sure that only one is ticked to enforce them to untick any others but the first way was the preferred option. 

Does an event in CSLA help me achieve this?

Thanks

Jeremy

RockfordLhotka replied on Tuesday, February 23, 2010

This behavior should be in the business layer only if this concept is not specific to your particular UI. In other words, if you took this object model and used it in an entirely different UI style, would you still want the same behavior? Or to put it another way, is this a business rule, or a UI thing?

If it is a business rule, then that's fine. You can put the rule implementation in the parent object, triggered by the ChildChanged event. The args for that event will give you a reference to the object that was just changed, so you can easily loop through the list and uncheck all other objects.

greengumby replied on Tuesday, February 23, 2010

Hi Rocky,

Yes this situation is a business rule and would happen throughout the system. If I use the ChildChanged event and look through all the other children changing values wont this create a circular loop?

Thanks

Jeremy

rsbaker0 replied on Wednesday, February 24, 2010

A common technique to handle the looping is to have a private variable of some sort that indicates that the change handling code should be locked out or suspended. Using a numeric counter for this will solve re-entrancy problems:

        void ApplyChange()
        {
            if (_lockout == 0)
            {
                try 
                {
                    _lockout++;
                    // Apply change here
                }
                finally 
                {
                    _lockout--;
                }
        }

I'm not sure you'll necessarily have a loop in this particular case, because presumably you would apply the "uncheck all the others" logic only when the new "IsMaster" property value of the object being changed is true. If you are turning off the IsMaster of the other items, presumably your test would bypass the unchecking logic.

RockfordLhotka replied on Wednesday, February 24, 2010

And that lockout code can be entirely in the parent object. Sure, when the child is changed it will run its rules (which you want), including triggering the ChildChanged event (which you want), which would trigger your parent's implementation (which you don't want).

But go ahead and let that happen - just at the top of the parent method check to see if you are already running this rule, and if so just exit - thus avoiding the infinite loop problem.

Copyright (c) Marimer LLC