Not having done much with MVC (lots and lots of ASP.NET Applications though) and Blazor, I'm fighting to get my head around how to accomplish what I want in Blazor.
In ASP.NET I would use the NuGet package for FriendlyUrls to accomplish this task.
I want to be able to define a list of URLs or generate them on the fly and have them route to a page I already created.
For example, I might have www.sitename.com/MyArticleName and I want it route to www.sitename.com/articles/1/ behind the scene. So the URL would look like /MyArticleName but in reality it's rendering the /articles page with a fixed ID.
My table in the DB is basically (a bit more to it though) is URL, Rewrite URL.
I can define the routes up front in some cases but when it comes to things like the articles , I would rather not define all the URLs up front as the user can add/rename/delete articles at any time.
Hopefully that makes sense. I know I can do a page like #page "/articles/{articlename}", but I don't want the user to see the /articles part of the URL.
Related
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.
So, this is both a technical and a SEO question.
Let's say you are developing an e-commerce site and the client requests that you maintain the category path in the structure of the URL. Example:
/electronics/video-games/ps3/nba2k13-p123774
How do you set up a route that will work for this and send things to the product controller regardless of the number of segments before the last segment? Example:
{arbitrary_cat_routes}/{name}-p{id}
Secondly, I understand wanting to get keywords in the URL, but is there a substantial benefit to this? I've heard that content closer to the root of the site receives some SEO preference. Doesn't buring it 3 directories deep wipe out the SEO benefit of having the keywords there?
The ASP.NET MVC routing does not support a catchall parameter anywhere in the URL just on the end. You would need to create a custom Route class that implements this functionality. This blog post summarizes how you would that. To answer your second question, I would avoid having category metadata in the URL, but I'm not super familiar with SEO.
I am always trumped by this question when starting a new project. When I look at examples like Mephisto, Typo, etc. they route their root to a controller that relates to a specific resource/model.
My problem is, almost every website I've ever built, I feel like my front page is actually a collaboration of all my models, and I can't see myself pointing to a controller that is related to a specific one as my landing page.
Does anyone tend to create a controller that is specifically intended for the front of the website? Or if maybe I am looking at this entirely wrong, please let me know.
edit:
Here is where my confusion exists:
rboard's routes maps root to a controller named index... but i can't even find an index controller
mephisto's routes use some custom routing thing, and there is no root or even a map.connect to '/'
radiant's routes for the bulk of the app goes to one controller, which then does some crazy magic
track's routes go to a controller that is related to a resource (this is an example closest to what i described above)... but doesnt fit me because as i said, my roots tend to have tons of things.
spot us actually does something similar to what i do, have a home controller that just has a show actions, and that is my front page.
My problem is, almost every website
I've ever built, I feel like my front
page is actually a collaboration of
all my models, and I can't see myself
pointing to a controller that is
related to a specific one as my
landing page.
Exactly. So what you're doing is correct.
I often make two controllers for interactions with things that aren't the usual REST stuff: 'welcome' and 'dashboard.' The welcome controller is mapped to my site's root, and the 'dashboard' controller is similar, but for logged in users.
Does anyone tend to create a controller that is specifically intended for the front of the website? Or if maybe I am looking at this entirely wrong, please let me know.
The short answer is "yes".
For what it's worth, I usually take a similar approach to Spot.Us and define a HomeController with an index action/view and just leave it at that.
Not sure if this is the answer you're looking for, but here's what I do. I usually use a combination of two controller types, a Front Controller and Action controllers. The Front Controller takes care of URL routing and determining what action to take, while the Action Controllers provide the actual functionality. It's a similar approach to what Zend Framework does.
With that being said, I'll pipe all traffic through a Front Controller, including front page traffic. I usually have an action controller named "IndexController" that handles miscellaneous page requests, and often the front page falls under that category (as well as things like privacy policy pages, contact forms, etc).
If a page is not specifically related to any of the business domain logic of the site, I tend to put it under my Index action controller, although I strive to group site functionality as best as possible.
SiteController seems like the best name to me. SiteController will contain your most important action, index, and my SiteController always contains other actions like contact, about, etc.
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]
I have a website where my present "geeky" urls look like:
http://www.bestatdubaiholidays.co.uk/pages/Quote/Details.aspx?GUID=01a25b0c-e0ac-40ba-abd1-298f3abd9612
I want to change these to Search Engine Friendly ones - something like:
http://www.bestatdubaiholidays.co.uk/the-palm-atlantis.aspx
or
http://www.bestatdubaiholidays.co.uk/the-palm-atlantis
I have hundreds of incoming links (from ad campaigns and other sites) to my geeky urls that I want to retain.
So if someone types a geeky url, I want the address bar to show the equivalent search engine friendly url.
Can anyone help? Referring to other articles won't help. Believe me, I've read every one of them. Any example urls will be helpful.
Use something like this http://blog.eworldui.net/post/2008/04/ASPNET-MVC---Legacy-Url-Routing.aspx
You don't have to use MVC, the routing classes are standalone now
I suggest using a Front controller. This means that you use the rewrite engine of whatever httpd server you're using to redirect ALL requests to a single file (index.php or index.aspx or whathaveyou) and then you use code in that file to dispatch to the appropriate page. You can do a redirect from the geeky URLs to the friendly URLs, and if it's a friendly url then you load the appropriate page.
This would be way easier than writing huge rewrite rules for each type of page you might have. And this way all of the work is done in the same language your site is already running, so you don't have to learn and maintain a new file that is in its own language just for the redirection.