Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

How do you create your ASP.Net pages?

I've got a few questions for those of you who work with ASP.NET.

1.Does anyone use the grid layout in VS.NET (in conjunction with the design view) to design your pages, layout wise. 
2. What do you think of the html that is generated through this? I know in the past, MS's generation of html has been considered some of the ugliest out there.
3.If you don't use VS.Net's design view, what do you use (be it the HTML source view, or another html editor).
4.Are there any sites you would recommend that discuss/instruct ASP.NET sites? I'm aware of devx.com and check it out from time to time, are there better sites out there?
5.Do you use code-behind? Why or why not?

Tim
Tuesday, April 15, 2003


>1.Does anyone use the grid layout in VS.NET (in conjunction with the design view) to design your pages, layout wise. 

I think this depends on what who your target audience is.  If it's for a corporate intranet/internal-app, you can use the grid layout because you can be reasonably certain what browsers will be used/supported.

>2. What do you think of the html that is generated through this? I know in the past, MS's generation of html has been considered some of the ugliest out there.

I'm less concerned about its ugliness, and more on if it works with the browsers I intend to support (generally IE5+ and Netscape 7 for internet sites and IE5+ for internal apps)

>3.If you don't use VS.Net's design view, what do you use (be it the HTML source view, or another html editor).

Personally I use both the design view and the HTML source view.

>4.Are there any sites you would recommend that discuss/instruct ASP.NET sites? I'm aware of devx.com and check it out from time to time, are there better sites out there?

http://www.asp.net/
http://www.aspalliance.com/
http://www.dotnetjunkies.com/
http://www.dotnet247.com/

5.Do you use code-behind? Why or why not?

code-behind is simply awesome - if you're building ASP.NET apps and not using the code-behind features, you're losing most of the benefit of what .NET has to offer web development.  That's my opinion anyway =)

GiorgioG
Tuesday, April 15, 2003

1. Most of my development is corporate intranet where IE is standardized, but I still don't use the Grid layout because I got burned because many users use the large Windows font set and the absolute positioning that the Grid layout uses caused some display problems with these users.


5. I use code-behind because having all that code embedded in my HTML isn't appealing at all. I hated ASP 3.0 for that very reason. The code behind just makes it much cleaner and easier to maintain.

Mark Hoffman
Tuesday, April 15, 2003

We don't use .aspx files at all.

Write write classes which directly (or indirectly) derive from Page, and use Web.config to dispatch them. All HTML is generated by using the built-in classes in System.Web.UI.HtmlControls and System.Web.UI.WebControls, plus controls of our own creation as well as third party controls.

This gives us quite a few benefits:

1. No compilation on first page hit
2. Easy to create complex control trees, including unique things like wizard and tabbed frameworks
3. HTML is always proper, never inaccurately nested tags or forgetting to close tags.
4. Dispatching can be context sensitive, not just URL sensitive.

There's no way I'd ever want to go back to hand tweaking the HTML in an .aspx file.

The one downside is that the app bounces every time you re-compile (and you do need to re-compile). This means lost session state, application going down and coming up, etc. You can overcome the session issue by using out of process (or database) session state, though. We do serve static CSS files, though, so that also alleviates a lot of the need to re-compile when adjusting layout, if you're just adjusting the CSS (i.e., changing presentation as opposed to changing structure).

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, April 15, 2003

"3. If you don't use VS.Net's design view, what do you use (be it the HTML source view, or another html editor)."

My employer is too cheap to buy a Visual Studio NET license. Being a manufacturing shop, they are perfectly happy with staying with VB6.

I was using WebMatrix, but it changing the case of the tags drove me nuts. I now just use Multi-Edit (my fav editor).

"5. Do you use code-behind? Why or why not?"

I don't use code-behind, for reasons stated in the previous answer.

Hector
Tuesday, April 15, 2003

Brad, you wrote that you "write classes which directly (or indirectly) derive from Page, and use Web.config to dispatch them"

How do you do use the web.config to dispatch them?  Your entire app is coded by hand?  Sounds like a pain?  Or are you using this in conjunction with user controls?

Thanks!
-Giorgio

GiorgioG
Tuesday, April 15, 2003

No user controls, and it's not a pain. I find it quite useful in a data-driven system. Of course, most people hard-code their UI, so I suppose it could seem inefficient in that scenario -- the first time you edit the page. The 20th time, maybe you'll reconsider. :)

Page derives from IHttpHandler, so dispatching is a matter of adding handlers to Web.config.

<httpHandlers>
  <add verb="*" path="*/login" type="Company.LoginPage, CompanyWebProject" />
</httpHandlers>

However, we're finding the regex matching system in Web.config to be a little too tough to code against (the URL that's regex matched is from the root of the web site, not the root of the application), so we're going to move to a custom-attribute system that utilizes reflection.

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, April 15, 2003

I used to use VS.Net in source view.  But, I couldn't get debugging to work correctly.  Instead of that, I now create all my files (aspx and matching cs) locally with Dreamweaver (which upstreams my aspx files to the server for me).  I have a batch file to compile the CS and dump them in the /bin directory on the server.  Still, this doesn't get me debugging, intellisense, or code-behind... so I'm wondering why I devised this system.  At least I'm being forced to learn ASP.Net better (hopefully).

rick
Tuesday, April 15, 2003

Brad, so you can't have UI designers make changes to a page layout?

Ben
Wednesday, April 16, 2003

Sure, why couldn't I? It's just that the end result isn't manipulating HTML, it's manipulating code.

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, April 16, 2003

Can you elaborate Brad? ;-)  How are you going to do visual design with this method?  I'm probably missing a piece of the puzzle.  Thanks.

GiorgioG
Wednesday, April 16, 2003

Brad, when you mention that app bounces everytime you have to re-compile, how do you mean?  Is it because someone may try to access the site during the re-compile operation (which ASP.Net avoids by compiling to a temp dir), or is it something else?

rick
Wednesday, April 16, 2003

I don't do visual design in the way that you probably mean it. I don't use a WYSIWYG editor.

~

The AppDomain gets unloaded and reloaded any time any file in the /bin directory changes, so when you recompile, the web app shuts down and restarts itself on the next request.

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, April 16, 2003

The problem I would have with your method Brad is that it doesn't make use of the ability to seperate code from the presentation layer, somthing that I and my UI designer love about ASP.NET.

I can build the base pages with a crap UI, then he can come in and make the pages look great (using Homesite, all hand coded as well) but he doesn't have to bother writting and C# code, or getting me to put his HTML into C#.

I can see how your solution would work for you if you are the UI designer as well as the coder, but for many of us working with a design team this method doesn't really work.

Ben
Wednesday, April 16, 2003

GridLayout sucks.  Don't use it unless your app doesn't really matter.

For one thing, your app will be completely useless to non-graphical browsers such as text browsers, screen readers for the blind, and computer programs trying to make some sense out of your page based on the order of content.

If you move your controls around, the tab order will be completely messed up.  You may be able to manually fix that by manually assigning the tab order, but if you're doing that much manual work, just learn HTML.

As previously mentioned, absolute positioning and user font size changes don't mix.  If you specify your font size in pixels, IE users won't be able to resize their fonts.  However, every other modern browser (and I would expect IE7) can resize all text.

Finally, if you need to hand edit any of the generated code afterwards (like putting in an HTML tag or attribute the designer doesn't know about), you're in for a world of hurt.

FlowLayout isn't quite as bad, but I still avoid using it from the designer..

If you don't know HTML and your audience uses modern, capable browsers, then the designer is an acceptable tool (in FlowLayout mode).  If you do know HTML, the designer wastes more time than it saves.  I only use it if I've added a bunch of controls to my form and I don't feel like doing the event wireups manually.  Even then, I hit Ctrl-Z immediately when I switch back to HTML view to undo any horrible changes the designer has made to my beautiful code.

Richard Ponton
Wednesday, April 16, 2003

Brad, I would be interested in knowing more about the way you are using http handlers. Can you explain exactly how you are taking care of presentation while having code in the httphandler classes.

Deepak(WebJives.com)
Wednesday, April 16, 2003

VS.NET's designer just sucks, I could rant about it forever.  If anything, work exclusively in HTML mode; it will give you more control and hone your HTML kung-fu.

I must second Brad's method.  Using aspx/code-behind, I ended up placing complicated logic in the code-behind anyway, which leads to design elements in both the aspx page and the code-behind.  So I figure, why not just put all the design in the code-behind?

Consider a page with many different design elements, each of which is dependent on various variables, such as user authentication/authorization.  Using an aspx page, you'd have to stick each element in a panel, and then show/hide the panels depending on these variables.  This can get really messy really fast (also, keep in mind that panels add 'div' tags where you might not anticipate them, which in turn can cause HTML validation to fail). 

Using just code-behind, all your design code is in one place, and it follows a clear path of execution.  It also makes inheritance easier, which facilitates page templating. 

Yes, this does mean that there's no designer, and at first, this made me uncomfortable.  But consider your alternatives.  An aspx page of multiple panels isn't going to be any easier to maintain.  And if a panel needs to be added or removed, it'll require code changes anyway.  A programmer is required for all but the simplest design change.

After working with many aspx/code-behind pages, I have to say that separation of code/design is wishful thinking.  If I had it to do all over again, I'd put everything in the code-behind file.

So that's my experience.  Brad, I've seen you mention this method in different places, ever think of writing it up?  Also, instead of using web.config to broker requests, why not just create a stub .aspx file for each code-behind?

monsur
Thursday, April 17, 2003

My handlers are all about presentation logic. Our business logic is very nicely tucked away in a separate assembly.

We extend Page with our own default layout of pages, which are rendered by classes we call Themes (different sections of the site have different themes). The theme will generate the majority of the "noise" in the page (top nav, left nav, etc.) and essentially leave a "hole" in the page into which a control will render itself for the body.

We extend Control with a bunch of control support methods, including explicit support for composite controls, a ViewState replacement system we call PageState and ControlState, command routing (ala MFC), and dynamic control tree re-creation as necessary (comparable to InvalidateRect).

We don't use .aspx files, because we dispatch not only on the destination but also context that's provided by the parameters to the page. Well, there's also the benefit of no compilation on the first hit, and it's one less thing to deploy. ;)

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, April 17, 2003

Hey Brad,

What's the overall benefit of doing it this way?  It seems like you're reinventing the wheel (ViewState) to do some of this stuff (mind you I think what you're doing is interesting, I'm just not sure what the overall benefit is.)

Thanks
Giorgio

GiorgioG
Thursday, April 17, 2003

Wouldn't http://myserver/myapp/default.aspx?url=/my/really/cool/path&actionid=12384&recordId=12328-1238213-1238213-1238 work just as well?

GiorgioG
Thursday, April 17, 2003

We actually have significant issues with the implementation of ViewState. Take a look at some of the third party controls that party all over ViewState. We did, and in one case a demo page was 2 megabytes with over 800k of that attributed to ViewState. What was this demo? A tree control.

We're very very conscious about the bytes that go down the wire. Having a non-page-injected analog to ViewState was the best compromise we could find until Microsoft really honestly fixes this. Sure, I know it's meant to foster statelessness, but I'm not an anti-state zealot.

Everything we did was to work around issues in existing ASP.NET infrastructure, or to help our productivity. The display of our pages is very highly data-driven, so I can't even fathom using some other system to do it.

Oh, and that example URL? Very long. People paste URLs into e-mail, so it's good to keep them at 70 characters or less.

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, April 17, 2003

Brad, Any thoughts of putting all this in some kind of article or are you bound by some NDA (as I understand all of it is work stuff). It will make a very interesting read for all of us out here.

Deepak(WebJives.com)
Saturday, April 19, 2003

At the moment, there's not much chance of writing it up, mostly because I don't have any time. I'm not under NDA, but under something much more effective: part-ownership. :)

Some day, when I have the time, maybe...

Brad Wilson (dotnetguy.techieswithcats.com)
Saturday, April 19, 2003

Ben, how do you work with your designer? I thought that once an asp.net control was added to a page, any html designer except VS.NET would be useless?

Thomas Eyde
Saturday, April 19, 2003

Interesting approach, Brad.

Where I work we have gone the opposite direction, and it works really well for us. We put the overall layout in the code-in-front, and what I think of as "presentation logic" in the code-behind.

Presentation logic is what was described above as turning panels on and off.

The very fact that this may depend on complicated conditions like authentication and context is the reason that we like it in a separate file. This is logic that isn't likely to be known or understood by the page designer.


Many things I like about this:

* No mixing of languages. I really used to hate old ASP because you ended up mixing VBScript and HTML and it was impossible to read. It was easy to mess up and end up with really silly malformed output. Using brad's technique, this problem is magnified because you have to compile to discover the problem.

If you refactor the control down to the nth degree to avoid this, then you end up with a very complex control tree that's just as difficult to follow.


* No recompile for layout changes. Where I work, they are fairly common and it's nice to be able to deploy a single ASPX to fix a design issue.

Also in the development phase, this prevents *constant* recompilation as you try to get the layout correct.


* Keeps the JavaScript close to the HTML (only useful if your app uses DHTML). Our app is very DHTML-intensive and one thing that really pissed me off at first about ASP.Net was the limited ability to output javascript. We created a control that you can use in the code-in-front which simply contains javascript. It has attributes that control where on the page it shows up, whether it should get output just once or once for each instance of it's parent control, and so on. It can also be wired into the event handler of another control on the page.

So again, this keeps you from having to edit javascript code within C# and allows you to "see" the HTML that you're manipulating right next to the javascript.


* Finally, we recently completed a dynamic workflow engine which allows users to create forms for filling in steps of a long process (think infopath).

Code-in-front worked great here. The users drag the controls onto a blank usercontrol (using webmatrix) and the code-in-front is saved into a DB clob. The first time we need to display the page we simply pull it out of the DB, save to a temp file, and then use ASP.Net's regular old LoadControl( ) method.


I guess it comes down to what works for you. Personally, I tend to go with the least complicated solution that can possibly work. The code-in-front/code-behind is that for me, but perhaps because I'm proficient in HTML.

Sorry this was so long! I talk to much :)

Aaron Boodman
Tuesday, February 03, 2004

*  Recent Topics

*  Fog Creek Home