The Lack of ASP.NET Events

March 6th, 2008

The ASP.NET page Life Cycle has several events that we can use to process the logic of the page. However, these events can became quite troublesome and generate more problems than they should. A problem may arise in a rather complex page, when we need to interact with some data that has already been handled.

Usually, developers use the following events:

  • OnInit - some initializations and dymanic control tree creation
  • OnLoad - here, we know that all the controls are properly dressed up, and we can add come logic
  • Post Back Events - the button clicks, etc, are handled at this moment
  • Render - the control is rendered to the response stream

Well… normally OnLoad prepares the controls based on some logic. But what if the that logic is to be overridden by a post back event? Bummer! What I usually see it’s just recall the logic with the new given arguments. We have the same code processed twice, no big deal.

We could wait and process the logic after the post back events, but we only have Render left, that has its own semantic: just render bytes. That’s why I think that the best option could just be to add another event between the post back events and render: the PageLogic event.

Even the use of some logic at a specific event time can generate some troubles, when we have different controls that need to interact with each other at the same event. But in this scenario, we can add a custom event to the super control, that will be fired and handled by other interested controls.

Bottom line: it’s funny how the events layer provided by ASP.NET usually makes development quite easy, but on the other hand, when we’re stuck at it’s limitations, all the easiness seams to fade away…