CODEWITHSUNDEEP
c#asp.netdynamicwebformscontrols
barbrady
barbrady

Reputation: 360

Design for page with dynamic asp.net grid server controls and handing button events

So I've built a site that, on many pages, has a standard "grid" (asp:table) being build on the server, and on many pages these grids contain standard links ("edit", "delete", etc) or a checkbox per row for multi-select operations.

The grid has to be built early enough in the page life cycle that the dynamic server controls can be accessed for event-handling (CommandEvents). For example, an "Edit record" button, which fires a command event (passing the record's ID in the command argument) has to be built on or before page_load or the event won't be handled. This works fine but sometimes building the entire grid in advance is not very efficient. For example, if it's an operation that performs an action then leaves the page, it's silly to build the entire grid just to leave the page before it's rendered/needed. Or, in cases where the action adds or removes records from the table, the table is already built and either has to be built an entire second time, or records have to be manually added/deleted from the table control in the button event handler.

My question is if there's something I'm missing here in regards to a design flow. I would imagine this is a standard scenario for CRUD-type sites. Basically I want to be able to handle events from dynamically built controls with a minimum of redundant/unnecessary server processing.

Would it be better to dynamically build standard html controls and use client-side script to do a __postback() passing the "action" and "ID" values, that way they can be accessed in say, the Page_Load() before the grid has to be built? Should I just take advantage of the fact that I can use the Request.Form information much earlier than I can access dynamic asp server controls? I do like the ability to access/set the properties of the dynamic controls in a more object-oriented way (rather than building dynamic html strings) but I think efficiency trumps that desire in this case.

Upvotes: 1

Views: 241

Answers (1)

user2907792
user2907792

Reputation: 11

So, I've ended up going ahead and utilizing the __EVENTTARGET and __EVENTARGUMENT request values to handle server events I want processed before the bulk of the page loading is done. Utilizing the controls from the HTMLControls set instead of the WebControls set didn't really make the building of the dynamic controls any different, so I suppose my concerns there were unjustified.

The plus side is the events can now be caught in a simple switch statment anywhere during the page life cycle rather than relying on the CommandEvents firing after all dynamic content has been built and the view state has been processed.

I thought that utilizing the built-in event-handling nature of the .net "forms" environment would be preferred to essentially creating my own event handling routine, but it appears there are some exceptions to this.

Upvotes: 1

Related Questions