Is there a Lemoon route for /{slug} - lemoon

I'm looking for an existing route (in Mindroute.Lemoon.Helpers.RouteHelper) that will already handle a path like http://www.mylemoonsite.com/blogpost3. It doesn't appear by requesting that URL that such a route is active, but it looks like some of the routes in RouteHelper.cs are attempting to cover that case. I can request http://www.mylemoonsite.com/blog/blogpost3, but I'm looking specifically for the former. Thanks.

Lemoon adds the catch-all route {slug*} to the end of the route-table, effectively catching everything that is not handled by other route handlers such as custom Controllers etc.
In order for Lemoon to respond to the request http://www.mylemoonsite.com/blogpost3 you need to have a page in your site with the permalink blogpost3. Since you get a response when requesting http://www.mylemoonsite.com/blog/blogpost3 I am guessing the permalink for your page is blog/blogpost3.
There are 2 things you can do to get a response from the path http://www.mylemoonsite.com/blogpost3.
Edit the permalink of the page
Add an alias to the page
If you add the alias blogpost3 the page will respond to both http://www.mylemoonsite.com/blogpost3 and http://www.mylemoonsite.com/blog/blogpost3. When adding the alias you can also specify the HTTP response code for the alias (200 OK, 301 Moved or 302 Found).

Related

How to remove '/' from end of Sinatra routes

I'm using Sinatra and the shotgun server.
When I type in http://localhost:9393/tickets, my page loads as expected. But, with an extra "/" on the end, Sinatra suggests that I add
get '/tickets/' do
How do I get the server to accept the extra "/" without creating the extra route?
The information in Sinatra's "How do I make the trailing slash optional?" section looks useful, but this means I would need to add this code to every single route.
Is there an easier or more standard way to do that?
My route is set up as
get '/tickets' do
It looks like the FAQ doesn't mention an option that was added in 2017 (https://github.com/sinatra/sinatra/pull/1273/commits/2445a4994468aabe627f106341af79bfff24451e)
Put this in the same scope where you are defining your routes:
set :strict_paths, false
With this, Sinatra will treat /tickets/ as if it were /tickets so you don't need to add /? to all your paths
This question is actually bigger than it appears at first glance. Following the advice in "How do I make the trailing slash optional?" does solve the problem, but:
it requires you to modify all existing routes, and
it creates a "duplicate content" problem, where identical content is served from multiple URLs.
Both of these issues are solvable but I believe a cleaner solution is to create a redirect for all non-root URLs that end with a /. This can easily be done by adding Sinatra's before filter into the existing application controller:
before '/*/' do
redirect request.path_info.chomp('/')
end
get '/tickets' do
…
end
After that, your existing /tickets route will work as it did before, but now all requests to /tickets/ will be redirected to /tickets before being processed as normal.
Thus, the application will respond on both /ticket and /tickets/ endpoints without you having to change any of the existing routes.
PS: Redirecting the root URL (eg: http://localhost:9393/ → http://localhost:9393) will create an infinite loop, so you definitely don't want to do that.

HTTP Requests in Laravel

In Laravel we use routes to deal with HTTP requests from the browser.
We can route a request to a controller, do some logic and then return a response.
Now, we can send in variables encapsulated with braces {} and the response can be anything, so it seems to me that routing through a controller means that the the properties of the different request methods (POST, GET, PUT etc.) are lost.
For example I could send a POST request with URI example/{id} then put in my routes.php file
Route::post('example/{id}','SomeController#SomeAction');
Then I could do something in my controller with the variable $id and send a response.
On the other hand I could send a GET request with URI example/{id} and alter my route to
Route::get('example/{id}','SomeController#SomeAction');
The controller would give the same response.
So, am I right in thinking it does not really matter what request method is used?
Two parts of your question I can identify on a second read-through:
Request methods are not lost. You have access to them with $request->getMethod(). So a GET request will return GET. You also have the method isMethod('GET') available to you, which you could use to get a truthy value which would enable you to return a different kind of response depending on the request type.
With regards to the way you set up your URL, what HTTP verb you use does matter if you're creating a REST-ful web service.
I won't explain away what a REST-ful web service is (you can look it up), here is a couple of points from your example:
If you're getting some data, you ought to be doing a GET request. It is the verb to represent a read from a resource. If you had to send a lot of data - and your intention is to add data, you ought to POST it instead.
The URI should be meaningful in a way that best describes the resource you are manipulating.
Together with the HTTP verb, you can infer the implied action. So if you are POSTing to example/1, I might infer that (and this is a digression, actually) that you are attempting to update record 1 from an example resource. In reality, you would perhaps use the PUT verb (which handles update).
Behind the scenes, Laravel uses a POST request due to browser limitations but treats it as a PUT request server-side.
Of course request type does matter. When you want to hide some request data against user and dont show it in url for example:
?username="Admin"&nick="admin1" then u will use POST otherwise you can use GET. When you want get some data u will use GET but when you want to send some data then you should use POST instead.

angular 2 route to 404 page when route param is invalid

Say I have an route with a param like this (in Angular 2): /user1/products/:id, which could have child routes like /user1/products/3/reviews.
When I navigate to /user1/products/-1, I check with my server and if the product doesn't exist, I want to render a 404 page without affecting the browser history.
Using router.navigate(['/404']) or router.navigateByUrl('/404') doesn't seem to work because it adds both /user1/products/-1 and/404 to the browser history.
Meaning when I press the Back button in the browser, I go back to /user1/products/-1 which is immediately redirected to /404 and I'm essentially stuck at /404.
In ExpressJS, we would do something like next() to pass the request to our 404 handler. Is there a client-side equivalent in Angular 2?
Update
In the new Router V3 you can use guards as explained in https://angular.io/guide/router#canactivate-requiring-authentication
Original
I think you should use #CanActivate() to do the check. If you forward in #CanActivate() the invalid URL shouldn't be added to the history (not tried)
See also https://github.com/angular/angular/issues/4112 for how to use DI in #CanActivate()
Ok, this is already implemented, just not well-documented.
According to the docs:
router.navigateByUrl(url: string, _skipLocationChange?: boolean) : Promise<any>
Has a parameter _skipLocationChange that will not modify the history.
These will do the trick:
router.navigateByUrl('/404', true);
router.navigateByInstruction(router.generate(['/404']), true);
As of Angular 2 final this is the solution:
this._router.navigateByUrl('/404', { skipLocationChange: true })
Its really interesting question, perhaps you should report it as feature request. I would be nice to have access to router instruction inside loader callback of RouteDefinition.
You could try to emulate validation adding default route /** and using regex parameter of RouteDefinition to match only positive numbers.

Codeigniter URL routing solution for my website

I have a website that is developed with CodeIgniter. I have added the route for my url as follows:
$route['about_us'] = 'about-us';
Now I have a problem with that. I.e. when I am looking for the url www.mysite.com/about_us it works and at same time www.mysite.com/about-us is also working. I want only one url to work: the one with the underscore.
I have removed this to:
$route['about_us'] = 'about-us';
But the url www.mysite.com/about-us still works. It may cause duplicate content for my website in Google and so more page links also showing. Even I don't have that functions too. Like www.mysite.com/about_us/design. Likewise in about_us controller file index function only there, but design method calling in Google.
How do I resolve this problem?
You actually don't need a route here. The normal purpose of request routing the way you are using it is so that you can use hyphenated URLs when hyphens are not permitted in class and function names. I.E. you want the url to by www.example.com/test-controller, but you can't actually name a controller test-controller because the hyphen is illegal.
If you only want to have the underscored URL such as www.mysite.com/about_us then just remove the route completely and name the controller about_us. With no routing rules the hyphenated url should 404.

Right way for blog URLs

I'm trying to do blog application and I want main page to have this URL: http://localhost/blog and posts to have URLs like this: http://localhost/blog/post-slug-name. So now I'm trying to understand how other actions should look like. Should it be something like this?
http://localhost/blog/post-slug-name/edit (GET/POST)
http://localhost/blog/post-slug-name (DELETE)
http://localhost/blog/create_new (GET/POST)
But I don't like to have "special case" create_new (because pattern is the same as for regular post). What is common way to do this?
If you have full control over how your server maps HTTP requests, you could use a POST to http://localhost/blog/post-slug-name/create to create a post using that slug name, returning a 201 Created status on success and a 409 Conflict if the page exists. The advantage of using a single create_new method is that it can handle conflict avoidance transparently and obviously.

Resources