Denny.NET

I can haz ASP.NET goodness?

About the author

Denny Ferrassoli
Developer at Casting Networks. MCP / .NET
E-mail me Send mail
Add to Technorati Favorites

Recent posts

Recent comments

Authors

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008

On Again, Off Again, and Finally Google

My site has been up and down, on and off, stiff and flimsy throughout the week. I am not the sys admin of the year so running on my own virtual server has been a workout. My pains really started with Plesk, a control panel for hosting multiple websites. It's a great tool when it works and it can configure the few things I'm not familiar with with a few clicks. However when it doesn't work then I have to manually go in and tweak things myself. Like my DNS and Mail for example. For whatever reason my DNS settings for dennydotnet.com would not be created, maybe it dislikes my name :) Anyways...

Today I decided to finally fix my Mail problems after a friend enlightened me with knowledge of Google Apps. "Google Apps.. and Mail, huh?" Yep! You can create your email account on Google Apps, add a few DNS records to your domain and voila! Google now handles your e-mail, faster and more reliably. You also have access to your email via GMail and you can of course enable POP/IMAP to access it via your favorite mail program. Best of all you get to use your domain name "@dennydotnet.com" not the "@gmail.com" name and you have total control of email as well as "lists."

Allowing the Goog to handle my mail is great because I can now disable and uninstall my mail server software. This, in turn, gives me back more memory and hard disk space as well as less headaches when my email isn't going through :)

Thanks Goog!

[Update 05/08/08]: Everything went well with Google Apps and I went around my site and changed my email settings to reflect the new Google Apps email. At first I couldn't figure out which host or port to send to but after some research I was able to make the necessary changes. Below is an example of the SmtpClient code needed to send mail via Gmail.

[code:c#]
SmtpClient smtp = new SmtpClient();
smtp.Credentials = new NetworkCredential( "addr@mydomain.com", "****************" );
smtp.Host = "smtp.gmail.com";
smtp.Port = 587;
smtp.EnableSsl = true;
[/code]

Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Currently rated 4.0 by 1 people

  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:
Categories: Blog | General
Posted by Denny on Tuesday, May 06, 2008 11:02 PM
Permalink | Comments (2) | Post RSSRSS comment feed

UpdatePanels: When and Where

I've been using the ASP.NET AJAX Update Panels for quite some time now and have picked up a lot of tips on when and how to use them. Update Panels were intended to allow the developer to do Partial Page Updates. Usually what you see is Update Panels updating nearly the entire page which completely defeats the purpose of Update Panels!

Here are some good tips to take into account when developing with Update Panels:

#1. One thing I notice is that people want to stuff all their functionality into one page with multiple hidden/visible panels. Then utilize the functionality by showing/hiding the panels based on actions within the page. This can lead to very confusing code...

If you're changing from one action which does a lot of functionality with X to an action which does a lot of functionality with Y then separate the functionality and use a page postback to switch between those pages. Don't throw everything together into one update panel and separate it by hidden panels. You'll end up with a ton of code which is not resuable and difficult to understand. Separate your functionality just like you would separate your DAL, BL and Presentation.

Example for an Admin section:
  • User Management (insert, update, delete users)
  • Settings (change your web app's settings)
  • Media Management (insert, update, delete media)
  • etc...

#2. Separate your Update Panels. Instead of throwing everything into one update panel break it up! Plan what areas of your page will need to update and what will trigger them to update. This will save you an insane amount of bandwidth (and download time) and return much better performance.

Example:
Lets say you have 3 areas on your page that will allow a user to: select a category, select a video and then watch the video.

  • Part 1 displays a list of categories
  • Part 2 displays a list of videos within that category
  • Part 3 displays a video player

Lets think logically about the flow of execution with the 3 parts. First a user picks a category in Part 1. Then they select which video they want to watch in Part 2. And finally the video displays in Part 3 and begins playing.

So there are 2 steps involved to watch a video:

  1. Pick a category
  2. Pick a video


And 2 triggers:

  1. "Click" a category
  2. "Click" a video



(Each arrow represents a click)

So we've got the basic idea down now how do we determine WHERE we need update panels? We need to determine what parts change. The only parts that change are Part 2 which shows a list of videos within the selected category and Part 3 which plays the selected video. Part 1 will not change because nothing within that part changes. Part 1 is only used to select a category and the categories are loaded at Page_Load.

(Of course if you added paging or sorting to Part 1 you could then use an update panel but for this example Categories are static.)

So you have 2 parts that change meaning you only need 2 update panels, one for Part 2 and one for Part 3. Now how do we trigger these updates? Based on the flow we determined above we know what triggers are needed...

Triggers:

  • Part 2 needs to update when a category is selected from Part 1.
  • Part 3 should update when a video is selected from Part 2.

We also want to hide the video player when the user selects a new category because it wouldn't make sense to continue showing a video from the "Comedy" category after they selected the "Drama" category. So we'll need one more trigger:

  • Part 3 should update when a category has been selected since we don't want to display the old video when they select a new category.


(Each arrow represents where the item is triggered from [start of line inside part] and what part it affects [end of line])

And that's all we need to properly separate our update panels. The cool thing about upate panels is that your trigger control does not need to be within the same update panel. In other words, it can be located anywhere on your page outside the update panel. That's why we only need 2 update panels. The triggers in part 1 can be set programatically or through the update panel "triggers" GUI from the properties menu.

Quick Tip: If you want to know how to set a trigger programatically then read this post.

What's the benefit of separating the update panels? Alot of Bandwidth! Update panels respond with their entire rendered contents when doing an AJAX call. Update panels also attach any control viewstates to the response. If you were to place the entire content of the example above in one update panel you'll be uploading and downloading everything every time you do a callback. On the other hand if you separate your update panels, like the example above, you'll only download the contents of the update panel that has been triggered.

Quick Tip: If a control within an update panel does not need viewstate enabled then disable it! This is a good way to decrease the size of the response.

Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Posted by SuperGhost on Thursday, August 30, 2007 2:19 PM
Permalink | Comments (1) | Post RSSRSS comment feed

New Dad, Job and Knowledge

Well it's been a long while since I've blogged and I'm finally getting around to it. There's been a lot of things going on lately! First and foremost I'm going to be a new Dad starting next year around February or March. I'm excited about the news and can't wait to find out if it's a boy or girl. Things will definitely start changing around the house!

Secondly, I started a new job! I'm really excited about working at this new place because they're doing some really cool AJAX stuff. It's a great opportunity for me because I'll get to work with some really bright people and work with the latest technologies too. I recently picked up a book titled: "Professional ASP.NET 2.0 AJAX" by Matt Gibbs and Dan Wahlin (Amazon) to get some further insight on the ASP.NET AJAX Framework. It's an excellent book and there's plenty of tips and knowledge in here even if you're experienced. For example, I finally found out what the benefit of using the ASP.NET AJAX registration methods (for namespaces, classes, etc...). It has to do with performance, amongst other things. I'll blog more about this later! On another note I introduced SubSonic to the team as well. I had some positive feedback and it looks like we could be implementing it across various projects in the future.

I've recently been working with the ASP.NET AJAX Serialization classes, in particular the JSON serializer. There didn't seem to be too many resources while Googling for examples so I poked around and created a few helper functions for myself such as serializing a DataTable or DataReader into a JSON array / object (Yes ASP.NET Futures supports this already). I'll blog about this in the future as well. Anyways, upon creating some helper functions I realized I had something interesting started. I began thinking about how I could bind my array of JSON objects to a pre-defined template, like a Repeater only on the client-side. It seems possible but I haven't researched this thoroughly to see what implications it could have. It may be a side project in the future.

Feedback:
What I'm interested in knowing is how other people have been using ASP.NET AJAX. Are you taking adavntage of Web Services, or are you using PageMethods? Are you relaying your data as XML or JSON? Why? How are you using the data passed to the client. For example are you using it to update one or two specific elements or are you bulking your objects together to complete multiple tasks?

I'm very interested in hearing your responses.

Digg It!DZone It!StumbleUponTechnoratiRedditDel.icio.usNewsVineFurlBlinkList

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Categories: Blog | Client-Side | ASP.NET | General
Posted by SuperGhost on Monday, July 16, 2007 10:05 PM
Permalink | Comments (2) | Post RSSRSS comment feed