2.0 plugin theory

I'm writing an article on creating a plugin for version 2. At the request of a fellow user I would like to use a "Request Quote" form as my example plugin.

I'm having trouble with a concept. When I think of a plugin I think of an isolated component the main application does not depend on, but can use if it exists. Developing a feature as a plugin will create a dependency on those plugins or that type of plugin.

So I'm thinking the best way to make plugins feature worthy is by creating a controller that can be used for rendering installed "feature" plugins. Then in the Nop.Web application (where needed) we can just call

RenderAction("Feature" new { FeatureType })

. The controller checks for installed plugins and renders the first one with matching criteria.

In the mean time I'll have to add a dependency on my new plugin.


Before I publish my article I want to make sure I'm not leading readers astray if I create this dependency on a plugin.


nopCommerce developers what do you think?

I think its awesome that you are writing these tutorials, thank you!  This is going to help me a ton.  Do you think it might be possible to start with somthing basic like this Request Quote plugin, and then go with a series of how you might extend it further.  The request quote might be a really good example, because there are a lot of places you could go with it.

For example, in your current plugin the options for gathering data are static.  Maybe the next turorial you show us how to integrate with the admin site to do some configuration options.

Then another one showing how to make the data collected dynamic.  (ie: there is an admin control for defining the fields to capture, a quote queue, etc)

Then possibly extend it further to allow the customer to visit a complete quote and place an order based on that quote.

I'm sure there are a million other things you could do with it, but following the evolution and watching you implement somthing like this would be really helpful.