In my Rails 3 application, I list many items on the homepage. Some of them are obscure, and I would like to limit my list to only popular items unless the user clicks a specific link that basically "zeroes out" the limiter.
What I have now works, but when the user chooses to "Show all items", I end up with a ugly url:
http://myapp.com/?limiter=0
Is there any way that I can strip that out so that the user does not see the ugly attribute at the end of the url?
No, don't use POST. POST is only supposed to be used when you are making a state change on the server. Use an AJAX GET if you really need to do this.
Better yet, get used to seeing GET parameters like this. It's normal. And, it's like that for a reason: it allows bookmarking a resource, including whatever settings are needed to reproduce the request later.
Read up on REST. Learn it. Live it. Love it.
There's a number of approaches you could take. Probably the most obvious one is to have a separate page for your show_all. It sounds like you're trying to do too much with your homepage.
If you must have these on the homepage, and your link is also on the homepage, you could use an ajax call to load up your items without having to redirect to that url.
Finally I suppose you could try making a route just for this situation. I don't really have any experience with Rails3 routes, though, so I can't suggest any syntax.
Really, though, this smells like an application design problem, not a technical problem. I strongly encourage you to rethink how you are trying to do this. This doesn't sound like a feature that is appropriate to put on your homepage. Make a separate show_all action.
Related
In Rails, Is it possible to prevent HTTP requests that come from the Browser's address bar ? And only allow navigation through links made within the app ?
I really looking for preventing a user to simply type his destination in the browser and only uses the links provided.
I know It maybe sounds silly. But I'm kind of trying to give a different UX than any regular website.
Is this approach possible? And If yes, How?
And what is the possible disadvantages or deficits that may cause?
For completeness, Yes.
The previous responder is right, this sounds like a bad idea, but it is possible. I imagine it similar to how authentication work. Set a secret value in the session on the first page, ask for it it on the second page the user reaches, if they don't match user didn't use your navigation. Refresh as quickly as needed (every page, for example).
Drawbacks? It's weird, that's not how webpages work. A clicked link (or GET request) is not different than a URL typed in the browser. What do you mean by "different UX than any regular website", the more details we have the easier we can help.
No*.
You can make it harder for a user to guess the correct URL by using obfuscation or use sessions to make the application stateful. But technically a GET request sent by clicking a link or by typing the url in the browser are identical to the server. The former is a form of security by obscurity.
The whole basically violates the core tenants of what a RESTful application does. In REST a resource should be omnipotent - requesting the same resource should provide the same response no matter how the user got there.
If you find that an action should not be able to be performed by typing the address into the browser you are most likely using the HTTP verbs wrong (using GET where you should be using POST, PUT or DELETE) or have a poor authorization system.
I understand that it's a good practice to only include in the URL the parameters needed to determine the object of the model.
If I have 2 models, Post and Comment... a Post has many comments and a comment belongs to one post. A URL for a comment can be
/comment/:comment_id
and from associations I can determine which Post it belongs to but
Some rails apps need to access external resources(Via APIs for example). If the rails app needs to replicate a part of another external source, what is the right way to handle URLs and routing?
If for example a post has some comments, The URL for a comment can be
/post/:post_id/comment/:comment_id
or
/comment/:comment_id
The latter has one disadvantage which is that I can't determine which post it belongs to if the API of the external source doesn't determine that and this would cause some problems with navigation through the app but it's a short URL and allows the user to easily manipulate the URL to get another comment(which I see as an advantage). At the same time using the first(long) link would make the URL so long but I can know which post it belongs to.
The only solution I can think of is to make both possible but the user would never know that the short one exists if I make the long one the default. What do you think?
I always use the longer / spelled-out version myself. I don't mind that it's long and I can only see good things come from it as you're discovering here. I also think it's an advantage because then you can do things like this:
post = Post.find_by_id(params[:post_id])
comment = post.comments.find_by_id(params[:id])
The point being that you can't go "comment fishing" this way. You have to have the right post context in order to get at a specific comment. This may not matter a whole lot if comments aren't at all sensitive, but there are many thing in a web app that may be. So scoping finds by a root object (like post here) allows a quick permissions check that can be reused and without having to check on parent objects.
Anyway, that's my 2 cents. I never understood why people take offense to the longer urls. If they work for you then don't be afraid to use them!
Sometimes at websites all comments or other data from DB is hidden by default. When user click at link like "Display comments" all comments from database are dynamically selected and placed under the content. It must be great for mysql performance, because content is generated only when user excatly need it. I would like to implement this stuff at my app.
I've got one idea to do this so far. Remote action with #comments = Content.comments and next page.insert_html at RJS template. Is it good idea or maybe I should choose different way?
The decision is purely based on the application that you are developing. For example if in case of stack overflow it does not make sense to show only the question and show answer link. But in case of a blog post it may be fine.
In the above situation, I don't think there will be a good improvement in performance by removing the comments of the content on show page. We can achieve the same functionality by making use of javascript methods. Hide the content on page load and show in on client request.
I'm designing a hosted software-as-a-service application that's like a highly specialized version of 37Signal's Highrise product. In that context, where SEO is a non-issue, is it worth implementing "pretty URLs" instead of going with numeric IDs (e.g. customers/john-smith instead of customers/1234)? I notice that a lot of web applications don't bother with them unless they provide a real value (e.g. e-commerce apps, blogs - things that need SEO to be found via search engines)
Depends on how often URLs are transmitted verbally by its users. People tend to find it relatively difficult to pronounce something like
http://www.domain.com/?id=4535&f=234&r=s%39fu__
and like
http://www.domain.com/john-doe
much better ;)
In addition to readability, another thing to keep in mind is that by exposing an auto-incrementing numeric key you also allow someone to guess the URLs for other resources and could give away certain details about your data. For instance, if someone signs up for your app and sees that their account is at /customer/12, it may effect their confidence in your application knowing that you only have 11 other customers. This wouldn't be an issue if they had a url of /customer/some-company.
It's always worth it if you just have the time to do it right.
Friendly-urls look a lot nicer and they give a better idea where the link will lead. This is useful if the link is shared eg. via instant message.
If you're searching for a specific page from browser history, human readable url helps.
Friendly url is a lot easier to remember (useful in some cases).
Like said earlier, it is also a lot easier to communicate verbally (needed more often than you'd think).
It hides unnecessary technical details from the user. In one case where user id was visible in the url, several users asked why their user id is higher than total amount of users. No damage done, but why have a confused user if you can avoid it.
I sure am a lot more likely to click on a link when I mouseover it, and it has http://www.example.com/something-i-am-interested-in.html.
Rather than seeing http://www.example.com/23847ozjo8uflidsa.asp.
It's quite annoying clicking links on MSDN because I never know what to expect I will get.
When I create applications I try my best to hide its structure from prying eyes - while it's subjective on how much "SEO" you get out of it - Pretty URLs tend to help people navigate and understand where they are while protecting your code from possible injections.
I notice you're using Rails app - so you probably wouldn't have a huge query string like in ASP, PHP, or those other languages - but in my opinion the added cleanliness and overall appearance is a plus for customer interaction. When sharing links it's nicer for customers to be able to copy the url: customer/john_doe than have to hunt for a "link me" or a random /customer/
Marco
I typically go with a combination -- keeping the ease of using Rails RESTful routing while still providing some extended information in URLs.
My app URLs look something like this:
http://example.com/discussions/123-is-it-worth-using-pretty-urls/
http://example.com/discussions/123-is-it-worth-using-pretty-urls/comments
http://example.com/discussions/123-is-it-worth-using-pretty-urls/comments/34567
You don't have to add ANY custom routes to pull this off, you just need to add the following method to your model:
def to_param
[ id, permalink ].join("-")
end
And ensure any find calling params[:id] in your controller is converted to an integer by setting params[:id].to_i.
Just a note, you'll need to set a permalink attribute when your record is saved...
If your application is restful, the URLs that rails gives you are SEO-friendly by default.
In your example, customers/1234 will probably return something like
<h1>Customer</h1>
<p><strong>Name:</strong> John Smith</p>
etc etc
Any current SEO spider will be smart enough to parse the destination page and extract that "John Smith" from there anyway.
So, in that sense, customers/1234 is already a "nice" URL (as opposed to other systems, in which you would have something like resource/123123/1234 for customer 1234 resource/23232/321 for client 321).
Now, if you want your users to be regularly using urls (like in delicious, etc) you might want to start using logins and readable fields instead of ids.
But for SEO, ids are just fine.
Well, my question is simple.
Does the ID affect the position of a webpage on Google ?
I have links like this
http://example.com/news/title-slug/15/
and people say to me that I should remove the ID from the URL.
And I belive that is not true. By my logic, you can't depend on the title's slug. I know it should work perfectly fine if there aren't two pages that have the same title, but why should I remove the ID if there is no harm when it's there.
Yes, leave it there.
Google has no business trying to second-guess what each element of a URL represents and changing its index based on that.
URLs by their nature can map to any resource, and I'm pretty sure Google recognises that. All you should do is ensure that multiple URLs don't have the same content by using redirects. So, for example, http://example.com/news/wrong-title-slug/15/ should redirect back to http://example.com/news/title-slug/15/ rather than just echo back the same page. Google doesn't really like duplicate content.
It's fine.
But I would not put that behind the title-slug though. Some url might get more confusing than the others.
http://example.com/entry/how-to-solve-question-45/15
a better one would be :
http://example.com/entry/15/how-to-solve-question-45
Besides, you can't really rely on just the title-slug, because changing the title of an entry means breaking user's bookmark. Not to mention that it is faster to retrieve an entry from the database by an integer ID instead of an url-slug.
The problem here is not whether Google will accept it, but whether or not doing so is user-friendly.
A common reason for keeping the ID in a URL is to ensure that the URL is unique. For example, if two people on here were to create a question named "Jon Skeet Facts" we'd have a problem, whereas with the ID the users are aware that they are two different questions with the same title. This is the same as with relational databases where a unique identifier is required.
In essence, why care what Google thinks? The whole Search Engine Optimisation industry is a farce, and this is coming from someone who has been paid more than once as a SEO Consultant. Why follow what Google wants when you can map Google's intentions by making your website perfect for the user? If you make a good website Google will reward you. The ID has a reason to be there, so keep it in.
I think your fine leaving it in. Seems to make sense as you get the element for identification and the element for being descriptive. It is done on here after all.
Zeus won't strike you down for it. I prefer not to have meaningless numbers in there because it's not very attractive or semantic.
Having the id will NOT hurt your SEO rankings. Having the slug there ensures that the page's main keywords will be indexed so it's all good.