I have Umbraco 7.5 and I need to know how to create normal MVC pages for adding new data to my site.
Lets say I have a Doctype "Node" in back-office. I want to let some people be able to add/edit some nodes without going through back-office. How can I do it?
I've tried to create add my view and controller (the MVC way), but apparently Umbraco hijacks all routing and my controller won't hit at all.
I've googled the matter (which is hard since I am not looking for Umbraco forms :| )and I've found this. But I prefer not to add my form as a part of other page. I mean, does it make sense to create a page in back office from type "something" and then on its template I do my add/edit form of another type? Seems strange, right?
I appreciate any ideas/ solution to this matter
You have a couple of options here. You can create a physical page for the editor to sit on, and add the editor as a SurfaceController action (basically an MVC Partial with Postback, that is still part of the Umbraco pipeline). Your form can then use the Content Service API to update the details. The advantage of this method is your code will have access to all of the Umbraco methods and templating out of the box. You could also use WebAPI controllers for the form if you want to do it all client side with JS requests.
You could also use route hijacking: https://our.umbraco.org/documentation/reference/routing/custom-controllers this allows you to have your own custom controllers for Umbraco routes, rather than using the default Umbraco ones. This is a bit more work to set up.
Finally, you can also tell Umbraco to ignore certain paths entirely, and you could run your controllers on those paths. The disadvantage here is that as the routes are being ignored by Umbraco, you don't automatically have access to all the useful Umbraco templating etc.
I've used the first method recently, and it works fine. The only caveat is that allowing users to edit nodes will fill up the version table quite quickly if a lot of users are editing a lot of nodes (every time a node is saved, a version is created). If you're going down this route, you may want to investigate something like Unversion: https://our.umbraco.org/projects/website-utilities/unversion/ which helps to keep old versions more manageable in situations like this.
Related
Say I've got an MVC website, www.codesmurf.com for example, set up with default ASP.NET MVC routing, nothing fancy. So my BlogController can be found at www.codesmurf.com/blog, and my FAQ similarly at www.codesmurf.com/faq.
Now if I also have a small survey project, currently in a different solution, how would I achieve to access this survey at www.codesmurf.com/survey?
What changes would I have to make to my routing and/or project structure to achieve this? So the entire survey project would be at the controller level of the main website, judging by the uri.
Do I have to achieve this using Areas? Do I need to create a SurveyController on the main site to redirect internally? Do I need to host this website separately and redirect externally? Any IIS configurations? How do I make sure my old routing isn't messed up?
This seemed like an easy task in my head at first, but I really have no clue what the best way to achieve this would be, and questions keep popping up in my head the more I think about it.
Note that the survey site is also an MVC project with its own controllers etc..
I haven't had much experience with changing the MVC routes, but would like to understand what I'm doing as well, so context/explanation would be greatly appreciated.
I personally would add the survey functionality as a service reference to your current MVC project.
Add Areas/Survey to your current MVC project and then start using the code from the service reference as you build up the Survey area.
When adding areas, all you will need to do is add some more rules to your map routes.
routes.MapRoute("areaRoute", "{area:exists}/{controller=Home}/{action=Index}/{id?}");
I have little to no experience in Umbraco, but it has been suggested to me as I have been asked to integrate a CMS system within my existing application. I have gone through some videos how to use Umbraco and done well so far. The problem is as follows. I have an existing MVC application with custom routing but both use the same database and dll. Example: www.ngomalta.com and animalguardians.ngomalta.com
Both have same interface, but with custom routing I can load some pages on a subdomain but not in the other. I would like to implement the same 'logic' using Umbraco. That is, I want both sites to have access to umbraco but they would have different content. Please note that it may be that I would have other sub domains in the future such as tomasina.ngomalta.com, and thus I would like scalability.
I have had a look on the net and other answers. However the solutions that I found are vice versa! What I mean is, that solutions given assume that you have an Umbraco site and you want to add an MVC controller. My situation is the opposite, I have the MVC and would like to add Umbraco views. Thus I want to make Umbraco compatabile with MVC and not design an MVC solution to be compatible/integrated with Umbraco.
Currently I have implemented a class that Inherits UmbracoApplication + WebBootManagerand and which overrides the Complete function. I have also tried to use my existing custom routing class (that inherits from [RouteBase]). It looks as if they work.. but the CSS styles and javascripts are not sort of routed or I don't know. They just aren't sent to the client. hence only the HTML is sent for both Umbraco page and my existing MVC views
First of all, is my idea with Umbraco possible?
If yes, can someone guide me some site that implements Umbraco in an existing (LIVE) MVC application and not the other way round? many of the tutorials that exist always start from a blank MVC application and build on that. I don't want such tutorials. I need a tutorial, that shows how an existing MVC application with already-existing-controllers that tries to integrate Umbraco.
Thanks for reading people..
!
I have a question about how to design my controllers properly.
Project is fairly simple: blog, immage gallery with categories and images inside them, news secion.
However I don't know how to organize my controllers for this because I want to make somewhat admin panel where administrators can edit, add and modify these things. I've came up with 3 scenariosu so far...
Admin panel will have links to site/controller/edit, but layout for these action results will be different from standard one.
Admin controller will have all these actions like BlogAdd, BlogEdit so that url will be something like /site/admin/blogedit.
Create copies of Blog controller in admin folder so url will be like /site/admin/blog/edit - i sense problems with routing since 2 controllers with same name does not sound like a good idea, however I like ho URL looks in this situation.
What I'm trying to make is CMS somewhat similar to wordpress, where blog creation,editing and deletion is completely separated from default blog itself.
I suggest you stop thinking about URLs and Controllers being a 1->1 relationship. This will make things MUCH easier and less confusing. You can make the URLs work however you want with MVC's routing mechanism and there's no reason to restrict your controller design/organization because of the URLs you want, because you can always adapt the routing to with with the URLs you have in mind.
While building the website, just focus on the controllers (and the general interface) and ignore the URLs until you get to that point, and then when you come up with a good URL scheme go into the routing system and add the routes to connect to your existing controller actions as you want.
Once you code out your blogging engine you will have a much better idea of the user workflow and will probably find different ways to organize your URLs, and you can then reorganize your URLs without touching the controllers themselves.
As to your first requirement:
There are two ways to do this depending on your end goal. If your goal is to display the same core content, but have different user options available (different overall layout, additional buttons on the page, etc..) then the best idea is really to just pass in an IsAdministrator property in your view model, and make the slight changes to the page based on if that's true or false. The reason is because you still (most likely) want the core of the page to be the same, and this keeps you from duplicating code that is related to the core data (data that's being displayed for both admins and non-admins).
Edit: So in summary, organize your controllers based on what makes it easier to develop with, not based on how the user interacts with the system with. You can always change the latter, changing the former is harder and will make maintenance annoying.
You can create Areas in your MVC project and have your admin functionality in a controller in your admin area.
This will allow you to easily seperate your administration functionality from your general blog functionality.
That's how I'd do it.
Why don't you keep the routes the same and handle the different roles via security? For example:
/blog/name-of-topic/view to view a topic (all users)
/blog/name-of-topic/edit to edit a topic (only enabled for logged in users)
/blog/add to create new topics (only enabled for logged in users)
You can handle these actions in a single controller and decorate the actions that require logged users via the [Authorize] attribute. Same thing with the links on your views, you would enable the links to edit and add topics only to visible users.
You could still have a separate panel to allow admins to hit the aforementioned add/edit links .
We have a fairly complex application that was previously using WebForms. We are in the process of rewriting bits of it from scratch using MVC. Our application is comprised of a number of widgets, that together make up the functionality of the application.
In WebForms, we used UserControls. Each UserControl would register its CSS and JavaScript by means of a collection that was stored in HttpContext.Current.Items. That collection would then be merged to output as one single request. Typically this would occur in the Page_Load event, and the containing page would then render out a script tag that would comprise all the JavaScript and CSS needed for that page.
We've been struggling with doing the same in MVC. We are using a number of views within a masterpage to mimic the widgets. Each widget has its own controller, so the functionality can be sufficiently segregated. The masterpage builds up the widgets on the page using RenderAction from MVC futures. Originally we were using the same registration method for the CSS/JS files. Each controller would register its required files in an Action. The files would then be contained in the HttpContext.Current.Items collection, and would be rendered out to the page. To facilitate this, I wrote an HtmlHelper extension to render the links/scripts out to the page. It looks like this:
<%= Html.GetRegisteredCssFiles() %>
The problem is that MVC uses a more top down approach. This call is made in the tag of the page, but our subsequent calls to RenderAction happen below. By the time RenderAction is called and the required files are registered in HttpContext.Current.Items, the code above has already executed. So, the collection is not modified at the right time.
Does anyone have any ideas on how we should be constructing this? I'm looking for answers that incorporate best practices for MVC.
This question was asked a lot of time ago, so probably you've dealt with this already. But for future visitors, maybe this solution will be helpful:
http://marcinbudny.blogspot.com/2010/01/handling-stylesheet-references-in.html
The Free Telerik MVC tools have a script and a style register that might do what you want ...
Not sure if this is a feasible solution for you, but try moving that call to the bottom of each page.
I've always included my javascript and css files in the html HEAD, so I don't know if it would work lower down. My assumption is that it'll work in most browsers, but you might have random problems in a few.
The alternative is to have GetRegisteredFiles() output some javascript that loads the CSS files in the proper place (via DOM manipulation).
The problem with either of these solutions is that the files aren't included until the end, which could cause the page to look "plain" until the CSS is downloaded.
Alternatively, the controller could predict which "widgets" will get loaded and pass that data to the master page.
I really like the way ASP.NET MVC works. I'd love to implement it on all new web projects moving forward, but I hit a snag in a prototype the other day that I really haven't found a good solution for, so I ask you, how would you design an MVC app that doesn't fit the typical REST pattern? As an example, the prototype I was designing would have several pages, but the pages themselves aren't necessarily bound to a domain model. For example, take a simple registration site, which might have the following pages:
/Default.aspx
/Register.aspx
/ThankYou.aspx
Occasionally, such a program might require an admin section to deal with such details as moderating sign ups or reviewing data. In a standard ASP.NET web app, I might add the following
/Admin/Default.aspx
/Admin/ListRegistrations.aspx
/Admin/ViewReports.aspx ...
Would it be an unacceptable deviation from the MVC pattern, in this case, to have two controllers such as:
Home->Index
Home->Register
Home->ThankYou
Admin->Index
Admin->ListRegistrations
Admin->Reports
My frustration with this is compounded by the fact that there is no real solid implementation of subcontrollers and areas yet. I'm aware of the "Areas" prototype put together by Phil Haack, but it's not very mature, and quite frankly, I'm not sure I like the way it's setup, but I don't really know how I'd like to see that work either.
I guess when I think MVC, I tend to think REST as well, and having controller actions that represent pages rather than actual entities or actions doesn't sit right with me. What do you think?
You can always mix ASP.NET Web Forms with MVC.
Just add
routes.IgnoreRoute("Pages/{*path}");
to your routing table and add traditional Web form pages to Pages folder of the application.
One mistake that newcomers to MVC make is to group actions into a controller for display reasons. In your case, instead of grouping the Register and ThankYou actions in with the homepage try separating them out into an AccountController as the MVC team has done in the sample project. You can use routing to set the Url's up however you want for the end-user.
As for your other actions, how about a ReportController? You could then additionally have an AdministrationController whose Index action/view contains links to various admin actions, including those on the ReportController.
Short Version: Group actions into a controller by function, not site navigation.
I usually ditch the "Home" controller as the first thing in a project and replace it with a "Page" controller. I use that one for anything that is "just" a page. Things like "FAQ", "Contact Us", etc. I do this at least partially because the default approach to the Home controller requires a new method being added every time you need even a basic, static page.
In that controller, I only have the one action: Display. That action gives all of those pages the same context object. I actually store the content for those pages in the database with a lookup "slug" and tie it into NVelocity templating, but even just static HTML or NVelocity templates in files would work too.
Anything else, like the others said, gets split into controllers by the "thing" being managed. So, a ReportController, User or AccountController, CartController, etc. Then the actions make much more sense.
When you're talking about listing the registered users, it's actually a list of users, so I'd have a UserController and do /User/Display/Registered/MostRecent or something similar. For the registration itself, /User/Register which would post to /User/SaveRegistration which could, in turn, redirect to /User/DisplayProfile/NewUserID or /Page/Display/Home from there.
You can have as many controllers as makes sense; that layout looks reasonable. Note that routes don't have to map directly to {controller}/{action}, but it keeps things simple. Looks fine to me - except I'd probably have ThankYou as a view - i.e. the Register [GET] perhaps uses a different view to Register [POST]