- Posted by Shay Friedman on April 29, 2010
I was talking with a guy the other day about choosing ASP.NET MVC over ASP.NET web forms. I told him why I think ASP.NET MVC is better (I believe it’s the way to go if you’re a .NET web developer) and he, in turn, tried to throw at me reasons of why not use ASP.NET MVC.
This conversation is legit and it’s been going on since the very beginning of the ASP.NET MVC project. However, there are a few things which are NOT legit in this conversation.
One of them is the sentence from the title: “But you need to master HTML for that, don’t you?”. I’m sorry people, but yes, you should know HTML pretty good when developing ASP.NET MVC apps. But guess what, you should know your HTML even when developing ASP.NET web forms applications! or when developing PHP, Ruby on Rails, Django, Seaside or whatever web development framework you’re using.
If you depend on Visual Studio’s visual designer to create your application HTML markup then stop now and go learn some HTML and CSS. Designers are there to help you (even though they tend to do the opposite) and they’re not there to replace your required skills!
Being a web developer without knowing HTML is like being a carpenter without knowing the difference between screws – you can build beautiful chairs but they might break apart very quickly.
So people, arguing if ASP.NET web forms or ASP.NET MVC is the right way to go is great, but as a .NET web developer you owe yourself (and your team) to know:
- C#/VB.NET
- HTML
- JavaScript
- CSS
These are fundamentals, they are NOT nice-to-know technologies!
All the best,
Shay.
- Posted by Shay Friedman on April 29, 2010
The conference season is coming and it’s time to let you know where and when you can see and meet me!
So…
This June I’ll be speaking at the Epicenter 2010 conference, taking place on June 8th-11th in Dublin, Ireland.
The conference will be hosted in the Arts building of Trinity College, which just looks awesome:
Anyways, it’s technology we’re interested in! So I’m going to have two talks in the conference:
When: June 9th, 11:00
Title: Practical IronRuby
Abstract:
Ruby has been a home for some great innovative frameworks like Ruby on Rails, Cucumber and Rake. IronRuby version 1.0 has recently been released, unleashing the power of Ruby to the .NET world.
In this session you will get familiar with the Ruby language and its amazing ecosystem and you will learn to take advantage of it in your everyday development tasks.
Come and see how this great new addition to the .NET family makes your development process faster, clearer and happier!
(Get ready for some crazy demos here!)
When: June 10th, 15:15
Title: Ruby on Rails Vs. ASP.NET MVC
Abstract:
2010 is the year when two great web development frameworks arrive at the .NET world – ASP.NET MVC 2.0 and Ruby on Rails (via IronRuby). It is the time to get to know these frameworks and learn their advantages and disadvantages. In this session I will walk you through the good, the bad and the ugly of both frameworks providing you points to consider when coming to choose one of them.
Come and see how these two wonderful web development frameworks collide!
In addition to these talks I’ll also participate on Wednesday’s evangelist night along with Jamie Van Dyke and Julian Fitzel.
By the way, I’m staying in Dublin for a few days after the conference as well so if you’re in Dublin, let me know and we’ll go grab a pint!
See you there!
Shay.
- Posted by Shay Friedman on February 19, 2010
When developing web applications we often run into a request to print one or more pages within the applications. In most cases, these pages will contain some type of report.
There are tons of ways to do that. Most of them I don’t like, especially the trivial one that pops to mind - “open a new window with a printer-friendly version of the page and set onload=’window.print()‘”. I find it quite irritating for the user.
There is another solution, which is less popular than its fellow window.open solution, but IMHO is much more user friendly and also might save you a few lines of code. It’s the CSS @media print solution!
What’s it all about?
- You get to have a single page that prints in slightly a different way than it’s presented on the browser.
- The magic lies within a special CSS block where you define CSS classes that will be used when the page is printed.
- This way you can hide parts of the page that don’t need to be printed, change the background image, increase/decrease font size, etc.
How to use it
The idea is to declare a different set of CSS styles for the page’s print mode. The great thing about that is that you can also, via CSS, hide elements that are unnecessary for printing.
For example, assuming you have the next HTML document:
<html>
<head>
<title></title>
</head>
<body>
<h1>REPORT</h1>
<form><input type="button" id="printButton" value="Print" onclick="window.print()"/></form>
<table border="1">
<thead>
<tr>
<td>Column A</td><td>Column B</td><td>Column C</td>
</tr>
</thead>
<tbody>
<tr><td>1</td><td>2</td><td>3</td></tr>
<tr><td>4</td><td>5</td><td>6</td></tr>
<tr><td>7</td><td>8</td><td>9</td></tr>
</tbody>
</table>
</body>
</html>
- This page will be presented as follows:
Great UI indeed. However, printing this page will be a bit ugly (surprise surprise!), but really, in terms of printing the page, the header shouldn’t be that big and the print button shouldn’t be visible at all.
To do so, all we have to do is to define the styles for printing mode:
<style type="text/css">
@media print
{
/* Here goes all styles to be used when printing */
#printButton { display: none; } /* hide the print button */
h1 { font-size: 12px; } /* make the header 12 pixels */
body, td { 10px; } /* make regular text 10 pixels */
}
</style> That’s it. Now if we print-preview the page, the header will be smaller and the Print button will be hidden:
Voila! No window.open is needed!
[Side note: I know this approach might be problematic sometimes because the user wouldn’t know what to expect when the page is printed. However, I still think this is a much more elegant way than the window.open approach. Use it wisely though].
ASP.NET developers: be careful when using CSS’s ‘#’ symbol with element IDs. Remember that ASP.NET changes the final HTML element ID of your controls that have the runat=”server” attribute.
All the best,
Shay.
Full source:
<html>
<head>
<title></title>
<style type="text/css">
@media print
{
/* Here goes all styles to be used when printing */
#printButton { display: none; } /* hide the print button */
h1 { font-size: 12px; } /* make the header 12 pixels */
body, td { 10px; } /* make regular text 10 pixels */
}
</style>
</head>
<body>
<h1>REPORT</h1>
<form><input type="button" id="printButton" value="Print" onclick="window.print()"/></form>
<table border="1">
<thead>
<tr>
<td>Column A</td><td>Column B</td><td>Column C</td>
</tr>
</thead>
<tbody>
<tr><td>1</td><td>2</td><td>3</td></tr>
<tr><td>4</td><td>5</td><td>6</td></tr>
<tr><td>7</td><td>8</td><td>9</td></tr>
</tbody>
</table>
</body>
</html>
- Posted by Shay Friedman on December 7, 2009
Http handlers is a really elegant infrastructure allowing you to provide special behavior to specific paths in your application. You can use them to create RSS feeds, dynamically generate images, handle requests differently and more.
Apart from writing new http handlers, there are some built-in handlers that you can take advantage of. The built in handlers are separated into three categories (in my opinion at least): request handlers, error generators and misc. handlers.
Request Handlers
These handlers process requests in a specific way. Although these already have paths configured for them, you can manually configure them in the web.config (or via IIS Manager) to run on different paths. For example, treat ABC files the same as ASPX files. There is one catch here – because ASPX, ASHX and ASMX files are dynamically compiles, you will also need to provide build configurations for the new extensions.
The handlers in this category include:
- The regular ASP.NET page (ASPX) hander - System.Web.UI.PageHandlerFactory.
- The generic handler (ASHX) handler - System.Web.UI.SimpleHandlerFactory.
- The resource handler (WebResource.axd) - System.Web.Handlers.AssemblyResourceLoader.
- The web service handler (ASMX) - System.Web.Services.Protocols.WebServiceHandlerFactory.
- The trace handler (trace.axd) – System.Web.Handlers.TraceHandler.
The following web.config sample enables accessing trace info via MyTrace.aaa (this is web.config configuration for IIS 7 running in Integrated mode, in other versions or modes the configuration will be a bit different):
After this is configured (and tracing is enabled as well), try navigate to MyTrace.aaa page.
Error Generators
These handlers generate specific http errors. You can use them to prevent access to specific files, specific extensions or folders. These error generator handlers include:
- Forbidden – generates a 403 Forbidden http error - System.Web.HttpForbiddenHandler.
- Not Found – generates a 404 Not Found http error - System.Web.HttpNotFoundHandler.
- Method Not Allowed – generates a 405 Method Not Allowed http error - System.Web.HttpMethodNotAllowedHandler.
- Not Implemented – generates a 501 Not Implemented http error - System.Web.HttpNotImplementedHandler.
The following web.config sample prevents users from accessing all files with secret extensions. Once a user tries to access such file he or she will get a 403 Forbidden page:
<system.webServer>
<handers>
<add verb="*" path="*.secret" name="SecretAccess" type="System.Web.HttpForbiddenHandler"/>
</handlers>
</system.webServer>Try navigating to top.secret and witness the result.
Miscellaneous
The misc. category contains one handler, the static file handler, which can help in various scenarios. It will present the file content without any processing. With this handler you can, for example, enable users to retrieve lkr file (no special meaning to this extension that I know of) content.
- Static file – shows the content of a file without any processing - System.Web.StaticFileHandler.
The following sample configures lkr files to be processed by the static file handler. To test this, create a txt file in your web application root folder, rename its extension to lkr and navigate to it.
<system.webServer>
<handlers>
<add verb="*" path="*.lkr" name="lkr-handler"
type="System.Web.StaticFileHandler" resourceType="File"/>
</handlers>
</system.webServer>
All the best,
Shay.
Share it:
