Use different extension for EWL CSS files

[wgross]

Continuing the discussion from MVC with EWL data layer, with EWL system manager: prohibitively difficult:

MVC with EWL data layer, with EWL system manager: prohibitively difficult

EWL should certainly not block you from using MVC in an EWF web app. But we need to be careful to not give developers too much flexibility since that would go against one of EWL’s main goals; see http://www.enterpriseweblibrary.org/.

My responses to your specific points:

• CSS constant class generation: I just approved your fix for this, so there’s no longer an issue.
• CSS HTTP handler: The only intrusive thing about this is how it blocks any CSS request that doesn’t include the correct timestamp in the URL. I’m open to relaxing this constraint if it’s a big problem. But the purpose was to prevent stale CSS from ever getting used after a deployment, and I think we should look into how MVC solves this problem.
• Error handling: I’m currently working on making this compatible with Web API. When I’m done, throwing HttpResponseException or whatever you do when you want to send the exception to the client should work fine.
• Ewf folder: I don’t think this is a big deal at all. Also, we can eliminate it when we’re completely separated from Web Forms.
• Web.config stomping: This is the big one. Letting developers completely opt-out of Web.config generation would open them up to all kinds of nasty errors, and I don’t know if there is any middle ground between that and full generation besides offering some limited flexibility via the EWL config files. But the good news is that I don’t see anything important in that MVC config file you posted besides some of the appSettings keys and maybe the pages/namespaces section. I’m open to automatically including all of that in the generated Web.config file if you agree.

This is all stuff we can tackle pretty easily.

What if we use a different file extension for EWL CSS files, e.g. .ewlcss? We could then have our CSS handler only operate on files with that extension. This would allow us to continue requiring the correct timestamp in the URL and doing other strict things, but would enable pre-existing MVC content to happily run within the project with its own CSS files.

What do you think, @samrueby and @greg_smalter?

[samrueby]

Would the browser be requesting .ewlcss files or would that just their extension on disk? This would resolve the problem by making EWL-CSS-handling opt-in.

[wgross]

The browser would be requesting .ewlcss files.

We could limit CSS constant generation to this file type as well.

[samrueby]

I like this. At first I thought browsers would be confused by the incorrect extension, but they really shouldn’t. They should be depending on the correct content type still being returned as well as the style tags they’re being linked-from saying type=text/css.