Est. Reading Time: 2 minutes
“Click here, edit this, move that, and save, there it’s that simple” said the presenter, with a shiny new website, upgraded to version 9 of ASPDotNetStorefront on the monitor, unfortunately the real world is never that easy. Recently, we completed the upgrade of a version 8 ASPDotNetStorefront website to version 9. Upgrades always have there own challenges and pitfalls and this project was no different. One of the biggest challenges for this project was ASPDotNetStorefront’s change to Microsoft master pages.
When upgrading, the first issue you will need to deal with is the change from ASPDotNetStorefront’s previous model of templates and skins to Microsoft’s master page model. I initially used the Upgrade Guide PDF for the conversion, but ran situations not covered by the PDF. The change to using master pages resulted in the use a server form tag wrapping the content in the master template. If you have any content that uses it’s own form, then that code will need to be modified. In this upgrade, we had two forms defined in the template that are present throughout the website, a website search form and a email sign-up form.
For the website search form we had 2 options: either use version 9′s new web control “as is” or modify the code to not use the form. We chose to modify the code because we are using a third party search add-on that offered extended search capability desired by our client. The modification we performed to the form were to use a JQuery function to capture the data submission event and do the post of the form data to the processing page instead of a normal form element.
For the email sign-up form, we had to use a different method. For this client, the email sign-up was handled by a 3rd party vendor, who’s form needed to be posted to. After posing the question to the ASPDotNetStorefront support forum and getting several answers involving some moderate to large programming changes, our web designer came up with a simple alternative: place the sign-up for in it’s own page outside of ASPDotNetStorefront’s name space and call the page in an iframe. Problem solved. For all intents and purposes the form is seamlessly integrated into the site.
Using both new and established technologies allowed us to meet the business requirements of the project without sacrificing the core programming benefits of ASPDotNetStorefront’s master templates. In the next issue, I’ll describe some of the issues we ran into with third party add-ons and working with the new templates.