i have to create a new asp.net mvc page that integrates content provided by a cms on the server side static. my mvc page provides a masterpage with the navigation and certain links should point to pages of the cms (which is installed on the same server). it should be something like a "server side iframe".
my idea is to create a controller which loads the page of the cms using a webrequest, extracts the body part of the page and passes the extracted data to the view. the view simply outputs the passed html. i also plan to add some logic to pass post requests to the cms (for news letter subscriptions, contact forms, ...)
now my question is: is it possible to implement this solution? or is there a better way to do this on the server side?
Could you use Application Request Routing to just hand off requests to your CMS, or do you need to include the externally provided content within an existing masterpage?
If you need to use the masterpage I would stick to the solution you suggest, although I might investigate the most robust and efficient option for querying the content from the CMS and perhaps if caching would be a good option.
It is undoubtedly possible, but keeping track of users, authentication, cookies etc. seems like a really tedious job. Also, embedding css classes, hard-coded styling etc. from the CMS in your MVC site could give you a severe headache.
If the CMS isn't home-brewed it probably has an API. In that case I would much prefer to use the API to get at the data I needed and then render that data using pure MVC. This will give you a much cleaner and more stable integration with the CMS.
Related
We are starting a major upgrade of a large WebForms application. The logic will be split between AngularJS on the front end and .NET MVC on the back end. What are the criteria about where to put routing? I can put it in RouteConfig.cs on the server and have .NET to be responsible for routing; or I can use ng-route on the client, and use only WebApi calls to the server.
I see pros and cons both ways, and I was wondering if anybody has any decision criteria. Or some articles that I missed (Google has plenty on implementing the routes; but not on the decision to pick one over another).
I would argue for full separation of concerns, so routing on the client. Doing the routing on the client puts the client in control of what is being displayed. The server would only serve the raw data via rest.
This also allows you more flexibility in the future as well. Say in 2 year you want to ditch Angular for the next new client framework. All you need are client developers to implement the UI calling the existing endpoints, the server code would not need to be touched. Want to move away from .NET backend? No problem, just implement the endpoint in the new framework, not client could would need to be changed.
You should use both as your application is large.
let say your screens are divide on the bases of rule.
When Admin will login you will load all files related to that functionality and after that take benefit of ng-view and make that functionality as a single page app.
So in this way you don't need to load all files once. by ng-view you can also share data between different screens.
Is there any way to hide the controller and action name completely in MVC.
(eg) localhost:81 should always remain same even on clicking any of the action in controller.
i.e., localhost:81/Controller/Action should not happen.
For what it's worth, you don't have to use the controller and action name in the URL. That's just the default. You can always define your own custom routes and make any URL you want hit any controller action you want. This is even easier if you use attribute routing, available in MVC5 or via the Nuget package, AttributeRouting, in lesser versions. This allows you to customize the URL for each action explicitly right on the action definition, which again can be any URL you want.
However, if you're truly looking to have just your domain as the only URL period, then #HadiHassan is correct in suggesting a SPA (single page application) architecture. There's many ways to go about this, so you'll need to just do some research to determine which set of tooling meets your needs best. At one point there was a project template for an SPA app in Visual Studio, it inexplicably disappeared for a time, and I believe it has now returned in the latest web tooling for Visual Studio. However, it's not hard to start from scratch.
You'll most likely want two projects, a Web API and a basic website project. The Web API is to provide your backend connectivity and is where you'll end up connecting to your databases and such, with something like Breeze to provide the connectivity on the client-side (your website project). There's alternatives here though, as you can also easily opt for a backend like a Node.js, which then wouldn't even require ASP.NET at all.
Since a SPA pretty much moves the entire application over to the client-side, you'll want to lean on a robust full-stack JS library. Angular.js is a popular choice, and has support for all the stuff like controllers, routing, etc. that you lose from a server-side MVC application.
How do I get Web API to render a Razor view using the model that it returns? And only XML/JSON when the accept headers (or .extension) is set? Is this even possible?
It seems crazy to require one set of controllers for rendering HTML and another for JSON/XML if they're working on the same models.
Update Darrel Miller has already written a ViewEngineFormatter for Razor which might do the trick, though haven't tried it yet.
I asked a similar question about this in the past on StackOverflow, because I wanted to do the same thing. However, I eventually ended up with an "Api" area and set of controllers, and a standard set of MVC controllers for the website.
In hindsight this actually wasn't a bad thing. I've found I tend to do different things in each set of controllers anyway. My views aren't just CRUD but tend to contain extra contextual data, so returning view models specific to that page is nice.
I think if I had stuck to my goal of combining the two I might have ended up with either over-complicated controllers or a user experience that wasn't as optimal as it could have been. So while this isn't a direct answer to your question, in my experience not being able to do this might not be such a bad thing.
Instead I've ended up with a rich set of builders and commands that most of my controllers delegate to. That way I can reuse most of the controller logic while being able to do specific things for API versus the web:
http://www.paulstovell.com/clean-aspnet-mvc-controllers
Yes, it is how it is designed for: Web API for data and MVC for rendered views. I know that some people will try adding view engine support to web API but it is not designed for it.
My personal view on this is that this parallel world between MVC and Web API (which is the source of most criticisms while community has generally praised the product) is mainly a consequence of the fact that Web API has been added to MVC without having a reference (or knowledge of it).
As Jon Galloway said on a recent podcast, had the team have HTTP knowledge they have now (as well as hindesight of the popularity of REST API now which they did not have then), they would have designed just a single pipeline serving data and rendered view alike.
I can only speculate that the future version of MVC/Web API will be presented as a single pipeline. In fact, this parallel world might have been a careful plan to unify them in the near future.
It seems crazy to require one set of controllers for rendering HTML
and another for JSON/XML if they're working on the same models.
AFAIK, that's how it is. Standard controllers should be used for rendering HTML and ApiControllers for JSON/XML.
It seems crazy to require one set of controllers for rendering HTML
and another for JSON/XML if they're working on the same models.
Web API is exactly what it is called - a technology for creating API's.
If you are creating an ASP.NET MVC application and want to return some JSON for your own purpose then you don't need content negotiation etc. therefore you don't need Web API (just use plain old good JsonResult).
If you want to create a reusable API than Web API is what you need but your client application should consume it in the same way as everybody else.
Web API isn't meant to be a "hammer" for "nailing" all non-HTML requests - use it when you need it.
I am looking for something similar to this, but not entirely. Through scouring the web, I found a couple posts by Fredrik Normen. He writes about this exact problem space and actually identifies a third-party solution in the second post listed. Basically, the solution involves creating a custom MediaTypeFormatter that knows how to handle views using the Razor engine provided by Microsoft (through the use of a third-party library).
Using Razor engine together with Asp.Net Web API to create a
Hypermedia API
Using Razor together with ASP.NET Web API
ASP.Net Web API and using Razor the next step
Hopefully Microsoft will implement something soon in Web API as Hypermedia seems to be gaining traction.
Hope this helps!
I have a project that will basically be a large brochure html website. Although some content could possibly be database driven in the future. I use ASP.NET MVC for any database driven websites usually, but not sure whether to use it for brochure html websites.
You'd probably want to use Master Pages even if the content is static. Might as well use MVC to keep headers and footers consistent across the site. (Same goes for any language, really.)
You host only plain old html files in it for now. If the need arises for database-driven content, ASP.NET MVC's routing options make it easy to switch to a dynamic site without breaking the links.
We used the same approach for setting up a dummy website for SEO purposes until the real app was developed and the switch to dynamic content was effortless.
The good thing about ASP.NET MVC (as apposed to Webforms? I assume you're asking) is that you can just use basic html and have a designer design up brochure required. If this needs to be more "dynamic" at some stage with forms or CMS etc, using the existing plain html will be easier.
Also if you're using MVC already its a no-brainer...
Danny,
it's possibly also a choice over whether your project sponsor is wanting to pay for windows hosting or whether they go down the linux route. if you know for sure that the site would NEVER be required to take data from a database then you could actually create an app in mvc (your developer app) and then have that app generate the 'flat file' site out to html files. that way, you could store the elements that make up the content in your developer database and regenerate the entire site when required. This approach would reap dividends - for example you decided to add some jquery across the site, then this would do it all in a single hit.
this way of generating flat sites would mean that you could in theory have an engine that you used for multiple clients, changing only the css and content as required.
just my tuppence worth...
jim
i recently was working on an ASP.NET MVC site that basically serves static html and uses ajax gets to return data to the page when inputs are changed. there is actually no posting or getting from an html input tag on the pages at all. (it is a specific style of site that is not used by the general public, so having compatibility problems for people without javascript is not an issue)
after designing the site, i realised that i hadn't even included any form tags. as the site does not use any direct posts or gets, and apart from it being just good html design, i wondered, in my particular situation, if there was any point to having any form tags on the page?
As ASP.NET MVC tries to differ from Web Forms, to introduce a new approach in designing web applications. They do not require forms. In fact i think it's better not to be used for navigation, submitting data, etc. Otherwise, there is no use of the MVC pattern if you still do it "the good old ASP.NET" way.
Of course ... I'm sure there are good reason forms to be used in proper places, but not as a general concept in your design.
You can read here: http://msdn.microsoft.com/en-us/magazine/cc337884.aspx how MVC was introduced in the beginning. "ASP.NET MVC - Building Web Apps without Web Forms" by Chris Tavares
Retaining a form is useful if you need your application to degrade gracefully if JavaScript is disabled or the likes. Also, jQuery and Prototype have nice Ajax helpers for serializing inputs using a form, which is really nice when you have multiple sets of data that could be submitted to different ajax endpoints from one page.
So I guess the answer to my question is no.