Ed Leafe wrote: > On Feb 11, 2007, at 3:38 PM, Paul McNett wrote: > >> Fixed dGrid to trap and respond to BusinessRuleViolations when >> moving the >> row number. This should fix tracker 0293. If the >> BusinessRuleViolation is >> raised by the bizobj, the grid will revert back to the prior row after >> notifying the user. > > What is the reason for changing the emphasis on the form as the > central handler for such things, such as checking for problems and > notifying the user, and moving it down to individual controls? I'm > looking at this code, and the first thing that struck me is that now > lines, labels, and other such controls now know how to 'notifyUser()'. > > Don't get me wrong; I'm looking to be convinced. I just thought we > always had an implicit Mediator pattern at work here, with the Form > being the mediator. This change seems to go against that.
Actually, you are right. I was originally having trouble forcing the grid to stay on the correct row, and simplified the code to figure out the problem. The notifyUser() was moved to dPemMixin so that I didn't have redundant code in dBizobj, but I think in the case where the grid doesn't have a dForm (a rarity, if ever) we can just throw an exception. Let me redo this. -- pkm ~ http://paulmcnett.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
