At Deesea we are keen to use and promote Open Source solutions in our client projects. When our clients wanted shopping carts we used to build them from scratch. We built them from scratch because in the process of building them we experimented with emerging technologies and techniques. After we built quite a few, we were tired of re-inventing the wheel. After all, we had explored all we needed to explore.

Dorian, our founder, figured that the best way to go about it was to master an Open Source shopping cart application and also eventually contribute to its development. That way, we would benefit from the work the community has done and would be using and promoting an Open Source project and would be able to give back to the community as well.

Putting your weight behind an Open Source project is a risky task. It becomes even riskier when there are many competing projects in the same space. If you put your weight behind an inactive or badly developed solution, the whole purpose of going for Open Source will be lost. In such a case you’d be better off developing or using your own solutions, and when it came to shopping carts, we had a few.

Here I am going to record the thought process that was behind our choice and also share our evaluations of the solutions that are out there.

Technology

Since Deesea is a .NET shop, the solution had to be built on .NET technologies. We are a progressive development house, so we would prefer a solution that was developed using the latest technologies such as ASP.NET MVC. We are also big fans of a few other platform level Open Source tools such as nHibernate and nUnit. So if the solutions were built using any of these technologies, we would have loved it even more.

Unfortunately there weren’t any that filled our criteria 100%. But there are quite a few .NET Open Source shopping carts

While searching for ASP.NET based shopping carts, there are a few options.

• nopCommerce
• dashCommerce (was dead and now resurrected)
• ASP.NET Store Front
• Commerce Starter Kit (predecessor to dashCommerce)
• The Beer House

The challenge before us was to find the most mature, stable, production ready shopping cart, that was feature rich, easily extendable and boasted of an active community. When evaluated against this criteria, the first two solutions really stood out.

We were compelled to leave out ASP.NET Storefront due to the fact that Rob Conary has not done a release to it in over an year and the last application that he was referring to in his blog posts were significantly different from the released source. And there seems to be no direction in sight except for his explanation that a team over at MS was doing significant modifications to the solution and it will be released eventually. This scared us in a way as a project that MS worked on internally is bound to be built on 100% MS technologies and leave out other open source options. While we have nothing against MS technologies we wanted to go with a solution that would be open to embedding the best of breed technologies.

Features

Features of shopping carts are sometimes very subtle. Most shopping carts will have the basic features of a shopping cart and a check out process. It is the little nitty gritties of these, that you tend to miss on the first round, that get you by the neck during implementations.

The following is a summary feature comparison. This has been put together by the feature matrixes that are published in each solutions web sites and consists only of the features we evaluated initially. We will do a more thorough evaluation against requirements of each project.

Feature	dashCommerce	nopCommerce
Product / Catalog Features
Unlimited categories
Unlimited manufacturers
Products belonging to multiple categories
Multiple product attributes
Multiple Product Images
Multiple Product Descriptors / Product Specifications
Support for KIT products
Support for Downloadable Products
Multi-Currency Support
Ability to promote products (sale/featured/new)
Product Inventory Tracking
SEO – customize meta tags for products/catalog
Cart/Checkout/Order Management
Configurable Taxes (by Country, State)
Integration with third party Tax calculators
Configurable Shipping Rates (weight & state, country)
Integration with Shipment Providers (UPS, FedEx, DHL ,USPS)
Integration with Payment Processors (PayPal, Auth.NET,  2CO, etc)
Include/Exempt Shipping from Tax
Include Tax in Price
Email order notifications
Shipment Tracking
Refunds/Partial Refunds
Marketing/Promotions
Affiliate programs
Polls / Blog / News
Latest Products
Product Reviews
Recently viewed products
Discounts
Coupons
Free Shipping
General / Skinning / Extending
Ability to Skin the application via Master Page/CSS
CMS/Blog
RSS Feeds for Product Catalog/Content/Blog
Search engine friendly URL’s / URL Re-writing
Multi-Lingual

Conclusion

We pretty much concluded that nopCommerce is the way to go. But we are not going to ignore dashCommerce. We are a little uneasy that it suddenly disappeared, along with the forums and releases and the source for a while, but we hope all that is in the past and that dashCommerce will start to thrive again.  While dashCommerce was gone, nopCommerce kept on growing and it’s exhaustive feature list is a testament to the constant upgrades it has gone though. Also, nopCommerce has the strength of nopSolutions behind them, although we are not clear how big they are or how many developers they have dedicated to developing nopCommerce.

One thing we would love to see is if any of these solutions have plans to go MVC anytime soon. This is not very clear but based on their and their creators blogs, it seems dashCommerce maybe making some headway towards this. I for one, would love to contribute to any of these projects if they choose to go MVC!

Finally, if you agree or have comments on anything mentioned above, please feel free to comment.

In most web applications there are needs to send emails to users. And most of the time, these emails have to resemble the look and the feel of the web site, keeping the web site's branding and theme in the email messages as well.

On a recent web application that we were working on there were several emails that needed to be be sent and the client had done designs for the emails. The actual emails that were sent had to fill these templates with the users data and be sent out. These emails resembled the web pages that the user would see on the site.

After searching for the best way to send out templated emails, this is the solution we came up with. We wanted a solution that would stick to the MVC architecture that the site was using.

We created a Controller named EmailController. For each email that needed to be sent, we created an ActionResult method. Each ActionResult had a corresponding View. In this view we placed the HTML for the email template, and populated this View though the data passed to it by the ActionResult. Then using screen scraping, required method would populate the View, scrape the HTML and place it on the body of the email and send it out.

The application structure looked like the following. For brevity I have omitted the rest of the files in the application file structure and showing only the files related to sending the emails.

• <Models>
• <Controllers>
  • AccountController.cs
  • EmailController.cs
• <Views>
  • WelcomeEmail.aspx

Let's consider the Welcome Email. The EmailController.cs will have the following ActionResult.

   1: public ActionResult WelcomeEmail(int id) {

   2:     if (Request.IsAuthenticated == false)

   3:         return View("AccessDenied");

   4:  

   5:     User u = new UserRepository().Get(HttpContext.User.Identity.Name);

   6:     if (u != null) {

   7:         ViewData["email"] = u.Email;

   8:         ViewData["pss"] = u.Password

   9:     }

  10:     return View();

  11: }

  12:  

This method first checks if the request is authenticated, which means the current users is logged in. Then it retrieves the user from the UserRepository by the user name saved in the HTTPContext and populates the ViewData fields for email and password.

The WelcomeEmail.aspx page is a ASPX page which is designed using a Table HTML layout with inline CSS. The reason for using a table layout is when it comes to emails the most assured way to ensure that your email will display as intended is to use the HTML table based layout. Some email clients will not render the DIV's as intended. Also, the CSS has to be inline as most email clients tend to ignore the references to external CSS files.

Then on the Account Controller, which is the actual controller that handles the user registration, we call the WelcomeEmail ActionResult.

   1: [AcceptVerbs(HttpVerbs.Post)]

   2:  

   3: public ActionResult Register(User user) {

   4:  

   5:     // Validate inputs and create the User Account

   6:  

   7:     //Add an Auth Cookie

   8:  

   9:     //Send email

  10:  

  11:     string subject = "Welcome To Our Site";

  12:  

  13:     Helpers.Email.SendTemplatedEmail(

  14:         System.Configuration.ConfigurationManager.AppSettings["emailAddress"], 

  15:         user.Email, 

  16:         subject, 

  17:         Url.Action("WelcomeEmail", "Email", 0, "http") + "/" +u.UserID);

  18:  

  19:     Return View();

  20:  

  21: }

  22:  

The actual email sending is handled by a Helper Method.

   1: public static void SendTemplatedEmail(string from, 

   2:                                     string to, 

   3:                                     string subject, 

   4:                                     string templatePath){   

   5:  

   6:     MailMessage mm = new MailMessage(from, to);   

   7:     mm.Subject = subject;   

   8:     mm.Body = GetEmailBody(templatePath);   

   9:     

  10:     if (mm.Body != "") {  

  11:         mm.IsBodyHtml = true;  

  12:         SmtpClient smtp = new SmtpClient();  

  13:         smtp.Send(mm);  

  14:     }  

  15: }

  16:  

  17: public static string GetEmailBody(string templatePath){

  18:      System.Net.WebClient objWebClient = new System.Net.WebClient();

  19:      byte[] aRequestedHTML = null;  

  20:      string strRequestedHTML = null;

  21:  

  22:      aRequestedHTML = objWebClient.DownloadData(templatePath);

  23:      System.Text.UTF8Encoding objUTF8 = new System.Text.UTF8Encoding();     

  24:      strRequestedHTML = objUTF8.GetString(aRequestedHTML);

  25:  

  26:      return strRequestedHTML;

  27: }