Adding functionality to Nopcommerce's admin screens without copying and pasting existing views


Introduction

Nopcommerce's plugin engine is fairly powerful, providing extension points to expand core functionality. A sizable ecosystem has been built aroudn these extension points. When it works, it adds a lot whole lot of value. However, oftentimes required extension points do not exist, and extending the platform becomes much trickier.

In the past I have made modifications directly to the Admin site, but this leads to maintenance pain and I much prefer a plugin approach. In this post, I'll outline how I developed a trivial plugin, adding a button to the Order List screen, without duplicating any code.

Background

For a long time administrators on my site have been able to print delivery labels from the Order List and Order Details screens. This requires adding a button to these screens, adding some Javascript to these screens and also adding some controller code. The result looks something like this:

As of right now, Nopcommerce does not have much support for admin page modifications. There are a limited number of widget zones (allowing custom widgets to be placed on screen) and otherwise very limited UI customizability.

Standard Suggestion

The most common advice you see in these situations is to create a plugin, create a new view engine and point it to customized versions of the existing cshtml view files. So, in my case, I'd take a copy of Orders\Edit.cshtml and Orders\List.cshtml, modify them with my desired behavior and point my viewengine at the modified files. In theory this is fine, and it works well for small partial views. However, for the two files in question we're looking at a totalk of 700+ lines of code being duplicated.

My Solution

The solution in my case is similar to the above, but without the redundancy implied by duplicate code.

Step 1: Create as Misc plugin

I'll asume the reader is experienced enough with Nopcommerce to complete this step without help

Step 2: Create Your View Engine

All we're doing here is telling the plugin where to find our views.

undefined

Step 3: Create Your Routeprovider

This step is pretty straightforward. The goal is to overwrite the routes that the admin page currently uses when listing/editing orders.


Step 4: Create your Controller

It doesn't get much more simple than this

Step 5: Create Your Views

So here's where the magic happens. Rather than duplicating and modifying the original view, we render it as an action in our new view, adding our button(s) and events via jQuery. Below is an example of my List.cshtml view. Orders.cshtml works the same way.

Assuming future changes by the Nopcommerce team are not too impactful, this plugin should continue to work without requiring any re-coding.

Potential Drawbacks

This is far from a perfect solution.

1. It potentially has a performance impact as view processing will take a little longer due to the nested nature of our action rendering. To me, this is insignifcant. I'm not sure if the difference is noticable and, even if it is, I am more concerned about consumer-facing and search-engine-facing performance than performance that my administrators see.

2. You can only do this once per screen. By that I mean, you can't have multiple plugins ammending the same screen. Remember, we are overriding our route list, replacing the default with our own routes. If we do this more than once, the last in wins...whichever routes are loaded last will determine what is seen by the user.

In Closing

Look, this is a hack. Undoubtedly so. At some point in the near future the Nopcomerce team will expand upon the available widget zones in the admin area and/or add further extension points to the admin panel, making all of this unnecessary. When they do, I will most certainly update my code. But, in the short term, this allows additional value to be addded to administrative screens without having to copy and paste a bunch of code.

Popular posts from this blog

Excel - Adding an existing Pivot table to the data model

Image
  I've been working more with, and continue to be amazed by, Power Pivot. I recently ran into an issue where I needed to add the data for an existing Power Pivot report to the Data Model. There is a checkbox that makes this easy when creating a PivotTable: As so often happens, the analysis grew in scope/importance and I found myself needing to add the data to the data model. While it's not obvious how, there is a way to add an existing Pivot table to the data model. There's a More Tables... link in the PivotTable Fields pane.  Clicking on the  More Tables... results in a dialog confirming that you want to Create a New PivotTable .  Doing so will result in the creation of the new PivotTable in a new sheet. By default the data is added to the data model. You'll likely lose some formatting but for anything other than a trivial PivotTable, this should save effort, as it did for me.
Read more

Getting Started with Mirth (Part 1)

Image
This is the first post in a 2 part series. The second post is here Recently I posted about my positive experience when using Mirth by Webreach as an open source communication layer between one of our in-house applications and a third party and proprietary web service interface. That post received a large amount of attention (relative to my other posts :o) ) so now I will post a quickstart guide to creating a similar setup. In this post I will go over the very basics of using Mirth (please dig in and play around with some more advanced options/configurations), specifically I will demonstrate how to use Mirth to read data from a database, package the data up in a SOAP envelope, send the data to a web service and process the SOAP response. I'll also show you how easy it is to monitor channels once deployed. Once you've installed and opened Mirth for the first time you'll be presented with an empty dashboard - but it wont stay empty for long. This is where you'll s...
Read more

Mirth

Image
Introduction Let's talk about Mirth. At it's simplest, Mirth  link is an Open Source HL7 interface engine. HL7 (Health Level 7) is an NPO involved in the development of healthcare standards and the HL7 v2.x and HL7 v3 standards are commonly used in Medical Information for data interchange - including but not limited to clinical, financial, logistical and administrative messaging. I first ran across Mirth over a year ago on a personal quest to find an alternative to our client's legacy HL7 application. Academically, I wrote a number of lexical analysis tools using lexx, yacc, bison and JavaCC and knew the challenges of writing and maintaining complex parsers. I was simply looking for something that could parse HL7 for us, and perhaps log messages and provide a little more transparency than our application currently allowed.  A year later and our legacy application is still going strong (read: my proposal was declined), but Mirth is being used in production, far away from th...
Read more