I am working on ASP.Net web controls based on Entities. Each control will have the ability to perform record navigation, updates, deletes and adds. I have come across scenarios where I can use 90% of the generic functionality but I need to do some customization. To support this I have created several events

Save SaveComplete Delete DeleteComplete Update UpdateComlete

So for example if wanted to change a value prior to an update I could attach to the SaveEvent. I could access the entity fields I wanted to update and then the control would handle the update.

I have now come across a second scenario. For a delete I don’t really want to delete. My entity has an IsDeleted Flag. When a user selects to delete I want the IsDeleted Field is set to True. Now I can wire up to the Delete Event, grab the entity set the IsDeleted Flag to True but what is the best way to communicate back to my control to not run the delete logic?

The two ideas I have are as follows . 1. Pass custom Event Args, one of the parameter is IsHandled. After raising the Event in my OnDelete command I can check to see if it is true, if so I will not run the delete logic 2. Add properties to my asp.net controls like ProcessingEnabledForDelte or something like that. The delete code would check this to see if should process the delete

An comments or suggestions would be helpful

Thanks Bert

So, if I'm understanding correctly, not all entities have the IsDeleted and should therefor be truely deleted, but you're creating controls that can handle either type.

So, logically then, it's the Entity's responsibility to inform the control whether the record is to be truely be deleted, since it's the only one who knows for sure. Somehow the control would need to know that on it's Delete (or DeleteCompleted) event. Perhaps a custom property on the entity, permanently set to true or false, called 'PerformsRealDeletes', which is queired by the control, who then acts accordingly.

This presumes that you have access to the entity in the OnDelete ( or OnDeleteCompleted) event.

Another possibility, use the new Manager stuff, and extend the BaseManager class to include a 'PerformsRealDeletes'. You can then perform the delete using the Manager for that entity, and also ask it whether really does it or not.

I forget, is the BaseManager stuff done with Interface and Implements? If so, you could call IBaseManager.PerformsRealDeletes if you don't know they run-time invocation type.

My brain hurts...

Assuming that the OnDelte method knows about the entity in question, the entity could implement an interface called IPersistable. This interface could have a boolean property AllowDelete.

In the delete event try to cast the entity as IPersistable. If the cast succeeds allow the delete by setting AllowDelete = true.

i.e.

public void Delete()
{

  IPersistable persistableEntity = currentEntity as IPersistable;
  If (persistableEntity != null)
    persistableEntity.AllowDelete = true;

}

You could as you suggest raise another event that sent custom event args an pass your instance of persistableEntity in the args.

Another option could be to simply check the entity in the control and let the control decide to delete it or not.

public void Delete()
{

  IPersistable persistableEntity = currentEntity as IPersistable;
  If (persistableEntity != null && persistableEntity.AllowDelete)

  //..... code in the control to run the delete logic

}

Another even more abstract approach would be to define a custom attribute and decorate your entity class with the attribute.

[PersistableAttribute(AllowDelete:=true)]
public class OrdersEntity()
{
}

If you used the attribute approach you could simply use reflection to check the type at runtime for the PersitableAttribute and the AllowDelete property. The attribute approach only works well if the behavior is consistent, i.e. if your scenario dictacts that your control will ALWAYS skip the delete code for the OrderEntity then this would work great. If the "Deleteability" of a given entity is dynamic and could change at runtime, then the attribute approach isnt what you need.

swallace wrote:

So, if I'm understanding correctly, not all entities have the IsDeleted and should therefor be truely deleted, but you're creating controls that can handle either type.

correct

So, logically then, it's the Entity's responsibility to inform the control whether the record is to be truely be deleted, since it's the only one who knows for sure. Somehow the control would need to know that on it's Delete (or DeleteCompleted) event. Perhaps a custom property on the entity, permanently set to true or false, called 'PerformsRealDeletes', which is queired by the control, who then acts accordingly.

yep that is what I concluded also

This presumes that you have access to the entity in the OnDelete ( or OnDeleteCompleted) event.

yep I do. Two ways I have seen this done is 1. Set a property like you mentioned 2. Set a value in the event args

I think I will go with 1

Another possibility, use the new Manager stuff, and extend the BaseManager class to include a 'PerformsRealDeletes'. You can then perform the delete using the Manager for that entity, and also ask it whether really does it or not.

I just started looking at those... I need to finsh this project first. Thanks for your input

Bert

I like DevilDog's solution of implementing an interface on the entity. I tried to say that, regarding the IBaseManager, but I don't think it's there.

Good luck!

Another even more abstract approach would be to define a custom attribute and decorate your entity class with the attribute.

You are good!

swallace wrote:

Another even more abstract approach would be to define a custom attribute and decorate your entity class with the attribute.

You are good!

Thanks for the compliment, youre too kind.

Thanks DevilDog

Yes the OnDelete method know abput the entity in question. The OnDelete method is actually part of the web entity base class.

My goal was to have a self-contained control that can handle all updates, inserts and deletes. When dropped on a web page I don’t need to do anything else, no more buttons events or anything.

But as you see in this case I needed a way to short circuit the control default behavior. Once again I think I was trying to over engineered it. A property on the base class will be best

So DevilDog, have you had a chance to play with DotNetNuke 3.0. If you have it set up I can send you an early sample of my new document management module that I used my new templates on

Thanks guys

Bert

bertcord wrote:

So DevilDog, have you had a chance to play with DotNetNuke 3.0. If you have it set up I can send you an early sample of my new document management module that I used my new templates on

Uh, actually, no. I was going to ask you what the hold up is. I have been slammed with desiging my .net learning management system. However, if you can tell me where to get the beta I will install it and have a look.

Hopefully the 3.0 release will go alot smoother than the 2.0 release. The jumps from 2.0 to 2.1 in such a quick time frame was about as bad as the Microsoft jump from 1.0 to 1.1 of the framework.