Est. Reading Time: 3 minutes
The implementation of a new website project often creates conflicts between the clients business requirements, the designer’s “Vision” and the websites capabilities. This is especially true when using “out-of-box” software solutions that were created without the current project in mind. As a system engineer, it is my job to find economical solutions to these conflicts. In the recent upgrade of version 8 to version 9 of ASPDotNetStorefront, we encountered one of these conflicts with a 3rd party add-on for storefront.
In the previous version of the site, a third party add on was being used to add custom filtering and listing on a category landing page. However this add on was not compatible with version 9 of ASPDotNetStorefront. So we couldn’t use the existing solution. In browsing ASPDotNetStorefront‘s marketplace, we found a vendor that offered an add-on that offered similar functionality for version 9, so we purchased that and installed it. The installation was rather straightforward and went well. During testing the functionality appeared to correct. All that needed to be done was the “styling”, and that is were the conflict arose.
We had designed the layout of the form such that there was a header area and a left navigation area with categories. A pages content would display in a defined “div” area wrapped by the header and left navigation. This had been implemented at the template level in the previous version of the site and had worked well. In version 9, however, the new Add-on wasn’t designed to work with the left navigation, instead, it wanted the entire width of screen for its processing. This posed a problem because the category appeared below the left navigation, with a large gap between the header and the content.
Re-engineering the 3rd party add-on or redesigning the site was outside the remaining budget for the project. So we had to find a solution using the existing functionality offered by ASPDotnetstorefront, that could fit in the resources remaining. Ideas explored included using a different master page template for the category listing page, modifying the existing template to have two different areas for the left navigation and dynamically control which was visible. We finally came up with the idea of moving the left navigation into an XML config file where the display logic could be handled with XSLT parsing.
The benefits of doing this were two fold. First, the existing master page only needed to be modified to call the navigation code via the xml config file, no custom background code need to be created. Second, we could centralize the left navigation code so that the maintenance would be reduced.
To implement the changes we needed to modify the master page to call the left navigation using the XML config file, add the display logic to the XML config file, and modify the 3rd party’s category listing XML config file to call the left navigation config file.
Total implementation time for this was approximately 1 hour, which was substantially less than creating a custom master page or customizing the processing code. By analyzing the problem, defining options and examining available resources, we were able to successfully meet the requirements for design, business and software.