Compatibility with MVC

[brandonam]

This is such amazing work and I really appreciate the effort you've put into it, but would it be possible to make it compatible with MVC? The problem lies with the prefix being used in the init.js, for example, within the prologue theme.

Since essentially with MVC once you call a new controller and action you've modified the URL and virtual directory so the page is unable to find the required css pages. I've tried every kind of path notation I can think of, but nothing seems to work once its published.

I would love to have the mobile css load when required on my other pages but unfortunately I've now had to hack around this by forcing a particular style on the view like so:

@section Styles {
<link href="@Url.Content("/css/style.css")" rel="stylesheet" type="text/css" />
<link href="@Url.Content("/css/style-wide.css")" rel="stylesheet" type="text/css" />
<link href="@Url.Content("~/css/style-narrow.css")" rel="stylesheet" type="text/css" />
}

I've also attempted to store a hidden html object on the page and add the value to the prefix so I can modify the prefix on the page load for each view call, however unless you call the function on document loaded/ready it returns undefined, and trying to force load the scripts in order on document.ready causes more issues than it solves :(

Any work around available? or tips to get this to work correctly without breaking MVC?

[ajlkn]

Try setting the prefix to something absolute like '/css/style', then set up your routing so it ignores anything in '/css/'.

[brandonam]

Hi n33,

Thank you for your suggestion I've been experimenting with this but unfortunately not having much luck :(

I've been using absolute paths e.g. /css/style, ../../css/style. But I either lose the styling on the landing page once published or on the {controller}/{action} pages. If I use the first absolute path example above, the landing page works fine, but any navigation to another controller, once published to IIS looks in the controller/action virtual folder like so http://servername/applicationname/controller/action/css/style.css rather than http://servername/applicationname/css/style.css. For the other example above the landing page breaks as instead of serving http://servername/applicationname/css/style.css it instead serves http://servername/css/style.css

I've tried using the ignore route as you suggested routes.IgnoreRoute("{whatevercontrollername}/{whateveractionname}/"), but no luck there either unless I'm using it incorrectly?

Any help would be greatly appreciated!

[ajlkn]

Odd. That doesn't make a whole lot of sense. When you set a prefix in
skelJS, say:

prefix: '/css/style'

It's equivalent to prefixing every stylesheet the client looks for
with /css/style, ie.

...

In other words, it's purely client side. If that's not working,
something on the server side might be screwing with your configuration
(like remapping anything that looks like a route).

On 11/21/2013 8:36 AM, brandonam wrote:

Hi n33,

Thank you for your suggestion I've been experimenting with this but unfortunately not having much luck :(

I've been using absolute paths e.g. /css/style, ../../css/style. But I either lose the styling on the landing page once published or on the {controller}/{action} pages. If I use the first absolute path example above, the landing page works fine, but any navigation to another controller, once published to IIS looks in the controller/action virtual folder like so http://servername/applicationname/controller/action/css/style.css rather than http://servername/applicationname/css/style.css. For the other example above the landing page breaks as instead of serving http://servername/applicationname/css/style.css it instead serves http://servername/css/style.css

I've tried using the ignore route as you suggested routes.IgnoreRoute("{whatevercontrollername}/{whateveractionname}/"), but no luck there either unless I'm using it incorrectly?

Any help would be greatly appreciated!

---

Reply to this email directly or view it on GitHub:
#21 (comment)

[brandonam]

I do agree it definitely is something to do with the way IIS does the routing with the virtual path, I just cant figure out what or why it does it that way. I've found a sloppy hack in the mean time

function getRootWebSitePath()
{
var location = document.location.toString();
var applicationNameIndex = location.indexOf('/', location.indexOf('://') + 3);
var applicationName = location.substring(0, applicationNameIndex) + '/';
var webFolderIndex = location.indexOf('/', location.indexOf(applicationName) + applicationName.length);
var webFolderFullPath = location.substring(0, webFolderIndex);
return webFolderFullPath;
}
var rootDir = getRootWebSitePath();

and then appending rootDir to the prefix like so "prefix: rootDir + '/css/style'" this at least works when deployed live, while working locally I have to use ../../css/style as that's the only way the css will load across all views.

[ajlkn]

A pity, but at least it works. Still, I find it unusual IIS would mangle paths in this manner (particularly absolute ones, as that's bound to break stuff elsewhere).