I'm looking for an easy and consistent way for a BO to notify the UI that an Add, Delete, Save, or Undo has been canceled. Having corresponding “Canceled” events to these methods would be one solution.  The event arguments would be similar to the existing After events except that a “message” item would need to be added to the Before and Canceled events to allow the developer to include a reason the method was canceled.

 

Currently I'm including logic in the form that I feel should really be in the BO because there is nothing in the framework (at least I haven't found it) to communicate to the UI that a method was cancelled in the BO and why. There may be a better way of doing this in the current framework that I haven’t thought of, and if so, I’m open to suggestions.

 

One other thing I noticed while thinking about this is that the BO Save methods are overridable while the Delete methods are not.  I’d like to see them marked overridable to allow the developer to extend them if necessary.  

 

-Larry

Marking the Delete methods as overridable is easy... we can certainly do that.  However, adding the functionality for a message and a cancel reason might be more than we want to support.  However, you could create an inherited BusinessLayer that has the proper functionality by overriding the OnBefore* methods and raising your own event rather than the base BusinessLayer event.  You could then raise a Cancelled event from the same place, right after you raise your own event if the Cancel has been set to true.

A custom business layer did occur to me. I just wanted to see if there was any interest before I started down that path.

-Larry

Unfortunately you're the first person to mention it... most everyone just wants to be able to cancel, but they don't care about why they were canceled.

Hi Ben,

 

The reason for the request was to handle the following type of situation.

 

·     Business Rule: You cannot delete a customer that has related orders.

 

·     Business rule is enforced by a foreign key relationship in the database

 

·     Using the SF maintenance form if you try to delete a customer with related order records you get an ugly exception error. While it might be possible to capture the exception and display a friendlier message you shouldn’t be relying on exceptions to enforce your business rules and therefore some additional logic is required.

 

·     Create a public method on the customer BO to check for related records.

 

·     Use the maintenance form’s BeforeDelete event to access the public method on the BO and if there are related records, generate a friendly message to the user and cancel the delete.

 

While using the form's BeforeDelete event works, I felt that checking for related records and canceling the delete is a business rule that should be handled by the business object and not the form. The problem is that there is no facility within the framework for the BO to inform the UI that it canceled the delete and provide a reason.  Currently if you use the BO's BeforeDelete event and cancel the delete within the BO, the records aren’t deleted and the only information accessible to the UI is that zero records were deleted (I didn’t actually check to see if DeleteCurrentRow() returns 0 if the delete is canceled but I assume that is what happens).  There may be multiple business rules that prevent a record from being deleted, so just informing the user that nothing was deleted is not very informative.

 

Although I can certainly provide the functionality the user expects using SF as is, I’ve always tried to keep the UI as dumb as possible and place all the smarts in the BO. I know I’m probably being overly picky but it comes from reading too many books like Expert One-On-One Visual Basic .NET Business Objects.

 

-Larry

 

 

No, that's a perfectly valid reason to have that sort of functionality.  However, with our time constraints and the other feature requests we still have pending, you will probably be more pleased by overriding the BeforeDelete to implement the functionality on your own. 

And yes, we cram everything we can into the business objects... there's just no reason to have the UI contain logic like that, so you are definitely on the right track.

OK I've got my inherited custom business layer and the functionality I want. If you'll just mark the BO delete methods as Overridable I won't have to mess with the SF source code.

-Larry

I've already flagged them and they will be in the next release