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
HttpResponseExceptionor 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
appSettingskeys and maybe thepages/namespacessection. 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.