Managing Product Specifications


So currently I work on a team that managages an ecommerce website, and we're looking to migrate to Episerver Commerce. One somewhat unique aspect of our website is that we have roughly 1,500 types of specifications for our roughly 30,000 sku's.

Initially I was looking at creating a product schema of roughly a hundred different Content Types/Meta Classes however, I recently found out that these meta classes can't be fully managed inside of Commerce Manager, and requires coded classes for each Content Type. This is no problem for CMS, and if we had a smaller amout of product types I'd be fine with this solution however, we have a team of content editors and to require a recompile every time we want to make a new product type would not only be burdonsome for our developtment team, but also would require an outage, and this just doesn't make sense.

I wanted to reach out and see if there's any other methods of managing large amounts of product specifications that's possibley, more scalable, something that doesn't require a recompile.


Apr 29, 2016 17:06

It sounds like it should be possible to solve by modeling in another way, but without knowledge of your specific problem I can only speak in general terms: Whatever extra piece of information your content editors need to add that prompts them to create a "new product type" would require a development effort to make any use in the site anyway, right? If it is some new kind of information that doesn't fit the existing fields and the way they are displayed or ussed on the site, that would require the site code to be adapted? And while you are adapting you can just add in the new content model and your adaptations will be much easier to code.

If it is "just" about making it possible to somehow dynamically extend the display of the products I think you can create a more or less dynamic content type and display template. The simplest case is of course using ordinary XHTML fields where the editors can add in media, blocks etc. More advanced cases could include different "setting" properties that affect the page rendering and use of the actual information properties, custom properties like som sort of name-value collections (there is a builtin name-value collection meta field type called StringDictionary but it is not ported to the content model and does not offer the best performance) or other more advanced custom property types.

Apr 30, 2016 13:33