5

I've just started an internship with a company whose main product is an ASP.NET web forms. My related experience so far has been with Java and front end web development. My current task is to make their site responsive and more accessible for various users.

Currently I'm struggling to make sense of how each HTML page is generated. All of the user controls are programmatically generated from code behind .ascx.cs files and there is no markup in any of the .ascx files themselves.

I was wondering if this is standard practice? And are there any tools I can use to get a clearer picture of what each part generates?

  • 1
    I don't think its really that 'standard', but its certainly not uncommon. Best of luck to you. You don't have an easy road in front of you, I'm afraid. – Graham Jun 16 '15 at 18:37
  • There isn't a right or wrong way to define controls on a WebForms page, though it's good practice to adhere to separation of concerns (layout from logic) and define controls declaratively where possible. Programmatically defined controls tend to be preferred where there are runtime decisions that affect your layout. Declaratively defined controls tend to be preferred for static controls where runtime decisions will have less of an impact. – ravibhagw Jun 16 '15 at 19:07
  • You could try adding some comments to the aspx files. The you will at least see where they are going in the page. but my advice would be to ignore the backend and implement your changes via css and javascript – Ewan Jun 16 '15 at 20:53
5

***Edited

I am editing here because I did not really answer you question: ASP.NET was created around 14 years ago, when AJAX and DOM manipulation where in their infancy. The idea was to create controls and drag and drop them on a form. The controls would be part of a tree under the web form.

Anyway, At that time, ASP.NET fit the bill for 90% of projects, it had never been easier to create a web app then it had become with ASP.NET. Now it is 2015, and things have changed drastically over the years, namely, AJAX is everywhere.

One of the issues with ASP.NET is that it generates unique IDs for each control based on where the control fit in its page's control hierarchy. It also saves a pages encrypted ViewState, the state of all its controls, in a separate form field. So if you change the DOM drastically, when the pages tries to restore it's view state, it will error out, because the page is no longer the same state as it was when the view state was captured.

For example a generated id of "somepage_control_othercontrol" could be used by the asp.net page to find a control that is nested within its page and and restore its current view state, without having to do it manually. So, to sum it up, the best practice at the time was to reuse nested controls and there xml representations in the markup, for example, <asp:TextBox />.

If you want to use ASP.NET how it was designed to be used, use nested User Controls and Server Controls and try not to mess with the DOM too much.

If you are going do a lot of DOM manipulations via javascript, don't mind pulling post parameters into variables manually, don't care whether a control automatically repopulates with it's last value after a post, want to determine your own input control names, then you can use straight HTML aspx file with no server controls and turn off ViewState on your page, but for most pages you will doing a lot more work that the framework would normally do for you.

***End Edit

I have not done non MVC asp.net development now for several years, but the best way that I know of to understand how User Controls are generated is to understand the Page Execution and Control Execution Lifecyclesenter image description here and the events that render them.

See https://msdn.microsoft.com/en-us/library/ms178472.aspx

https://msdn.microsoft.com/en-us/library/aa719775(v=vs.71).aspx

https://msdn.microsoft.com/en-us/library/ms178472(v=vs.85).aspx

http://www.codeproject.com/Articles/457647/Understanding-ASP-NET-Application-and-Page-Life-Cy

PreInit All the Dynamic Controls, Master pages, Profiles and themes should be set in this event.

Init This should be used to set the initial value of the Control properties.

InitComplete This should be used to have custom ViewState data. This is the first place where ViewState has been loaded and can be changed.

Preload This can be used to set the properties of the controls.

Load All the Database connections and Data Binding can be performed here. Before this event finishes up all the validations will be done. Once the event is finished, the events for all the controls will execute before calling the next event in this list.

LoadComplete This event can be used for activities on controls that require them to be fully loaded.s

PreRender This is the last page where the visual properties of the controls can be changed before getting them displayed on the page.

PreRenderComplete This will be called when the page is ready and no changes in visual elements can be made. All data binding are done at this point.

SaveStateComplete View State has been saved and from this point onwards changes in ViewState will not be preserved i.e. ViewState has been saved for the page already.

Unload The Page processing is done now. This is the last event that will be called.

Essentially you need know exactly where you can do a certain types of tasks within the page and control life cycles. Once you understand this, you just need to subscribe to the right event for the task and write the code that's require in the event handler.

Here is a complete list of all the events as the happen in order across all scopes

Page ProcessRequest

Page ProcessRequestMain

Page DeterminePostBackMode

Adapter DeterminePostBackMode

Page LoadScrollPosition

Page OnPreInit

Page ApplyMasterPage

PostBack ApplyMasterPageRecursive

Control InitRecursive

Control ResolveAdapter

Control ApplySkin

Page ApplyControlSkin

PostBack ApplyControlSkin

Page OnInitComplete

PostBack LoadAllState

PostBack LoadPageStateFromPersistenceMedium

PagePersister Load

Control LoadControlStateInternal

Control LoadControlState

Adapter LoadAdapterControlState

Control LoadViewStateRecursive

Control LoadViewState

Adapter LoadAdapterViewState

PostBack ProcessPostData

Page OnPreLoad

Control LoadRecursive

Control OnLoad

Adapter OnLoad

PostBack ProcessPostData

PostBack RaiseChangeEvents

PostBack RaisePostBackEvents

Page OnLoadComplete

Control PreRenderRecursiveInternal

Control EnsureChildControls

Control ResolveAdapter

Control CreateChildControls

Adapter CreateChildControls

Control OnPreRender

Adapter OnPreRender

Control SaveViewState

Page SavePageStateToPersistenceMedium

PagePersister Save

Page OnSaveStateComplete

Control RenderControl

Control RenderControlInternal

Control Render

Adapter BeginRender

Adapter Render

Adapter EndRender

Control RenderChildren

  • Interesting, the question included "I'm struggling to make sense of how each HTML page is generated." and I was down voted for this explanation. Is that not exactly what I am showing here? – Paul W Jun 16 '15 at 17:40
  • +1 I don't know who downvoted you, but I certainly upvoted. Very nice overview! Bookmarked. – Marjan Venema Jun 28 '15 at 9:55
1

It seems like a fairly unstandard way of building out of pages, but that doesn't necessarily mean that it's bad. This way it can be fully dynamic without being tied to the markup. I can see advantages in a highly fluid CMS, for example.

In regards to what they generate in an HTML sense, this answer seems to cover most the controls you are asking about.

  • Panel - Div
  • Panel -- GroupingText="###" is Fieldset, Legend
  • Label - Span
  • Button - Input, Type Button
  • Link Button - Href with JS Postback Script
  • Hyperlink - Standard HREF
  • Image Button - Input, Type Image
  • Textbox -- Default is Input, Type Text
  • Textbox -- Mode = Password is Input, type Password
  • Textbox -- Mode= Multiline is Textarea
  • DropDownList - Select
  • Listbox - Select
  • RadioButton - Input, Radio with GroupName
  • Checkbox - Input, Checkbox
  • Repeater/Listview --Complex.
  • Gridview - Table
  • Table - Table
  • File - Input, Type=File

I'm not sure if there are tools for finding this out exactly, but if you are ever in doubt, you can always view the source code that renders within your page for some sort of clue as to how its actually functioning. Just set up a very simple test project and check the output.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.