Last post Jun 18, 2012 07:49 PM by Notre_Poubelle
Feb 20, 2012 06:35 PM|mjmiller|LINK
Our site is heavily localized (30+ languages) and customized. We are generating our JS content inside of CSHTML files so we can get access to the resources and the customization rules. We return these pages using a controller and set the content type to
I suppose we could just download a bunch of JS with the localized resources and reference them from the .js files, but that doesn't solve the customization issue where we turn features on and off based on the context (current tenant, current object, etc).
Does anyone have any thoughts on a better approach?
Feb 20, 2012 07:59 PM|ignatandrei|LINK
We are generating our JS content inside of CSHTML files so we can get access to the resources and the customization rules
Why aren't you just passing the messages from resources as a function parameter?
Feb 21, 2012 05:19 PM|mjmiller|LINK
Some of the HTML that's handed to the client is preprocessed on the server to include additional data from the model and, in many cases, additional elements supplied through ViewData/ViewBag properties. Examples of the types of tenant rules we push down
include the types of payment we accept and which model properties are used for account registration or password retrieval. We go this stuff on the server because it's faster and closer to where we have the data, plus, once generated for a given user we can
One of the primary reasons we ended up splitting the bits out into separate files was to get around VS's insistence on locking up when dealing with script-heavy pages.
Feb 21, 2012 07:59 PM|ignatandrei|LINK
Looks like a hell of application.
Could you share some small code to look to?
Feb 21, 2012 08:29 PM|mjmiller|LINK
Then instead of linking to the script using script src attributes in the main page, I just render the script inline. It works for our application because we only have a single "page" so there's no case where we render out the same script twice. Doesn't make
VS any faster, but hey, you can't get it all.
Once I have a small repro I'll post it. We're doing some tricks with routing that let our IoC container figure out the right partner and database contexts that'll be interesting to capture.
Jun 18, 2012 07:26 PM|Notre_Poubelle|LINK
I recently did something that sounds somewhat similar to this. I started going down a similar path, but changed directions when I started getting into issues with encoding certain content (like ampersands & newline characters, when using \ n). In the end,
we came up with something that was a bit complicated at first (need to put some somewhat complex infrastructure in place), but I'm pretty happy with the end result. We also achieved intellisense support. If you're still looking for a different solution,
I can share a few more details.
Jun 18, 2012 07:33 PM|mjmiller|LINK
We completely gave up on the approach. Our JS is now completely "clean" and comes out of .JS files. That way VS doesn't have a problem and the browser can cache it. We download the resources necessary to drive the page via a request for another JS file that
we build on the fly on the server. That way all of our localized text is cached on the client, and the per-partner settings / resources are delivered in a clean JS file. We got around the Intellisense issues by generating dummy versions of the same data, dropping
them into a server-owned folder, and using the /// references trick.
Jun 18, 2012 07:49 PM|Notre_Poubelle|LINK
Nice. Sounds similar, at its core, to what we did.