search

Sitecore / Reference-Storefront

Sitecore Reference Storefront
Other
25 stars 20 forks source link

Multisite becomes problematic...recommended work-around/fix? #4

Open Brad-Christie opened 8 years ago

Brad-Christie commented 8 years ago

When trying to get multiple storefronts in a project, this controller code ends up creating a very tight coupling on the storefront name--was this intentional? I mean, I assume it was intentional as that's how it was written--I guess the real question becomes could this be done differently, or are we adding storefronts incorrectly? For e.g. If we create the following:

I would expect them to reference a common ~/Views/Storefront/... path--we share views after all :blush:. Instead, Storefront is replaced by the corresponding shopName (so StorefrontA and StorefrontB respectively).

Am i approaching this the wrong way or missing a rudamentary understanding of how this was written? I do apologize as I haven't had the time to get too deep into this project, and can only touch upon it at the highest level, but wanted to see if I was missing something or this was just an oversight.

For now, we're pre-copying a views folder of a pre-determined name so we can give a demo with least amount of complication. However, I was contemplating modifying the code to the following for future uses:

const string RenderingViewPathFormatString = "~/Views/{0}/{1}/{2}.cshtml";
// allow overriding using a <setting>, but maintain expected behavior in its absence.
var viewsFolderName = Configuration.Settings.GetSetting("Sitecore.Reference.Storefront.StorefrontViewsFolderName", shopName);
var renderingViewPath = string.Format(System.Globalization.CultureInfo.InvariantCulture, RenderingViewPathFormatString, viewsFolderName, controllerName, renderingViewName);

But, again, not that familiar with the project. Seems like it would get the job done, but then again--what do I know? ;-)

Any info/insight is appreciated.

p.s. Great job on the project thus far, the effort's truly appreciated.

SorenKerrn commented 8 years ago

You're right that it was intentional and for the support of multiple storefronts where the MVC renderings could be different for the individual sites. Since the code was written over a year ago, Sitecore MVC now supports Areas which seems like a better way to accomodate for multi-site and even provide a fallback mechanism, if a view is not found under the Area. I expect we wil be introducing a setting to turn on or off the default behavior with the site name and otherwise rely on the Area instead.

Your proposed change also looks good and will allow you to re-use the same views for multiple sites and still be able to have discrete views for a specific site. However, it seems the fallback for area will be the best approach so you only have to specify the views that are different for each site and the rest will be stored in a central place.