Why is this:
http://MySite.com/Project/24/Search/32/Edit/49
preferred over this?
http://MySite.com/Project/24?Search=32&Edit=49
I'm not sure where your premise is coming from? It looks like an artificial example, which makes it hard to comment on.
A better comparison would be something like:
http://MySite.com/Project/24/Members/Edit
As opposed to:
http://MySite.com/Projects.aspx?id=24§ion=Members&action=Edit
Where, among other things, the hierarchy of entities is immediately obvious from the first example (ie, a Project contains Members). It also suggests that you can use other URLs that contain similar structures to the first (ie, /Projects/24 and /Projects/24/Members), so in that sense it's more concise.
If it comes down to actions that have a variable number of parameters, such as searching, then it's totally fine to use URL parameters as this will give you more flexibility, eg:
http://MySite.com/Projects/Search?name=KillerApp&type=NET
You could construct a URL using the first style, but you don't really gain anything, and managing the route could add unnecessary overhead:
http://MySite.com/Projects/Search/name/KillerApp/type/NET
I would argue that this (or any similar construction, eg if you removed the param names) suffers from an artificial hierarchy - the action in this case is really Search, and everything else is just a parameter of the Search, so it's in the same hierarchy, not some "sub" hierarchy.
Not really a fair comparison. The style allows you to drop the GET parameter names, so the routed one should read something like
http://MySite.com/Project/24/32/49
It's really an aesthetic improvement, though -- it's both neater-looking, and easier to type or read out to someone.
Its mostly a human readability issue, although (since most search engine ranking algorithms are not publically disclosed), it is believed to have SEO value as well.
In the example case, it may not be any better. But it's a Search Engine Optimization in general. Here are some SEO best practices -- from that article ...
Ideally, the URL structures should be
static, and reveal what the page is
about. A simple and clear URL
structure is much easier for both
search engine spiders and human
beings.
Easier to remember as well. It's easier for a user to remember /Employee/1 to get the information for employee #1 rather than understand a querystring. Not a reason to use it but I think its a small improvement.
Related
I'm working on a new advert website and want to implement some good SEO URLs.
I got category URLs like:
/category
/category/sub-category
This seems ok. What about detail pages?
Option 1:
/announcements-and-notices/announcements-various/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
Option 2:
/adverts/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
In reality my website has a pretty long URLs due to multiple areas you can shop. So it would become:
/en/area-name/announcements-and-notices/announcements-various/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
/en/area-name/adverts/15880/suscipit-dis-molestie-malesuada-vestibulum-ut.html
Which detail page would be a better URL? The first option seems to be better if the product has no long/good title. The second seems better as its the most relevant one and shortest especially with long category names.
I would like to hear your thoughts!
EDIT:
I found this two google docs:
http://www.google.nl/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDYQFjAA&url=http%3A%2F%2Fwww.google.com%2Fwebmasters%2Fdocs%2Fsearch-engine-optimization-starter-guide.pdf&ei=lXyaT6T_L8zR4QSM4c2qDw&usg=AFQjCNEMj8KHxhxQz9cMLoMxMDiLdrAbJw
http://support.google.com/webmasters/bin/answer.py?hl=en&answer=76329
I think I will be going for /adverts. Anyone disagree?
i have seen many of SEO analysts miss something about optimizing their webpage and that is your page will be optimized for only some keywords not all keywords. it is not important how length is your URL. you should first analyze whether the contents in your webpage is rich enough to have such URL with these keywords or not. if the answer for every keyword is yes then the more length will give you the more rank.
I think you can even set your pages up in a way to use only the slug and skip the id, such as:
/adverts/suscipit-dis-molestie-malesuada-vestibulum-ut
or even just:
/suscipit-dis-molestie-malesuada-vestibulum-ut
like this and refer straight to the adverts controller and the advert itself, which has this slug assigned to it (the one with id 15880).
This way you'll have nice and clean URLs. Just assign and keep an unique slug for each advert and handle it using .htaccess, or dynamically inside the code of your site, if the system allows it.
Cheers.
Using shorter i18n keys (e.g. t '.submit_button') in Rails views makes them easier to type, but is it actually good? When later you decide to refactor your views and partials you have to remember to update the respective localization entries. Wouldn't it be more robust to name them by their business meaning and always specify the full key-name?
Well, I'm using a mixture. ;-)
For things like "yes", "no", "submit", "cancel" I tend to use a namespace called "defaults" so I always use it like t 'defaults.cancel'. That could also address the "submit_button" thing you mentioned above.
For my specific views I decided to use the lazy lookup feature.
If you want I18n keys for specific views you have to decide what fits best for you:
If you don't mind searching your yaml file for the I18n keys and
change them if you change the view do so. The advantage is that you
save some characters for each I18n.t call of it in your view.
But if you change your view names very often (not sure why you should
have to do so :) ) then you might be better of using the way you described.
As I already said I prefer the first option since it's more convenient for me.
I am using ColdFusion 9.0.1.
I have a new web site that uses Bikes.cfm and Makers.cfm as template pages. I need to be able to pass BikeID and MakerID to both of the these pages, along with other variables. I don't want to use the Actual page name in the URL, such as this:
MyDomain.com/Bikes.cfm?BikeID=1234&MakerID=1234
I want my URL to look more like this:
MyDomain.com/?BikeID=1234&MakerID=1234
I need to NOT specify the page name in the URL.
I want these two URLs to access different data:
MyDomain.com/?BikeID=1234&MakerID=1234 // goes to bike page
MyDomain.com/?MakerID=1234&BikeID=1234 // goes to maker page
So, if BikeID appears in the URL before MakerID, go to the Bikes.cfm page. If MakerID appears before BikeID, go the Makers.cfm page.
Is there an easy and existing method to arrange the URL keys in such a way to have them point to the appropriate page?
Should I just parse the the URL as a list and determine the first ID and go to the appropriate page? Is there a better way?
Any thoughts or hints or ideas would be appreciated.
UPDATE -- It certainly appears that using the order of parameters in a URL is a bad idea for the following reasons:
1) many programs append variables to the URL
2) some programs may reorder the variables
3) GoogleBot may not consider order relevant and will most likely not index the site correctly.
Thanks to everyone who provided advice in a positive manner that my approach was probably a bad idea and would not produce the results I wanted. Thanks to everyone who suggested alternate means to produce the results I wanted.
If anyone of you positive people would like to put your positive comment/advice as an answer, I'd be happy to accept it as the answer.
Despite my grave misgivings about the whole idea, here's how I would do it if I were forced to do so:
index.cfm:
<cfswitch expression="#ListFirst(cgi.query_string, '=')#">
<cfcase value="BikeID">
<cfinclude template="Bikes.cfm">
</cfcase>
<cfcase value="MakerID">
<cfinclude template="Makers.cfm">
</cfcase>
<cfdefaultcase>
<cfinclude template="Welcome.cfm">
</cfdefaultcase>
</cfswitch>
I've got a need where each user can customize their own page on a replicated site. In grails it seems the most straightforward way to do this is:
somedomain.com/someController/JohnDoe
spelling out a controller, except this forces folks to type in a longer domain name, versus something like
somedomain.com/JohnDoe
Using sub-domains may be another approach, however they would need to be created automatically, i.e. when someone joins.
Can you please clarify the main ways Grails supports this kind of requirement/need (replicated site), and some of the pros/cons of each?
Thanks, Ray
Edit: Per Tomasz's edit below, the simplest course of action isn't clear. If you have insights on this please do share.
It is called UrlMappings in grails. You need to declare:
"/$username?" {
controller = 'someController'
action = 'user'
}
It redirects to someController, action user and optional variable called username.
This solution has one catch. Every one level path you visit passes this rule and takes you to someController. You cannot go to somedomain.com/books because it passes rule above and it follows you to someController#user with params['username']='books'. Then you can't use default actions. But if you decide that all your other paths have at least one slash, e.g. /books/list then you can follow this solution
Edit: I was wrong. It doesn't work as I've expected. I thought that UrlMappings are applied in order they are defined. That's not true, as explained here. Even worse - it's not documented (GRAILS-6246). Most specific explanation comes from Peter Ledbrook :
It uses a specificity algorithm, so the most specific match should apply
You must experiment then. I suggest you use safest solution and stick with /user/username solution.
This is a new application, and I have an index method on a Search controller. This also serves as the home page for the application, and I'm trying to decide if I am headed down the wrong path from a design pattern perspective.
The method is already 35 lines long. Here is what the method does:
3 lines of setting variables to determine what "level" of hierarchical data is being searched.
Another 10 lines to populate some view variables based on whether a subdomain was in the request or not.
A 10 line section to redirect to one of two pages based on:
1) If the user does not have access, and is signed in, and has not yet requested access, tell them "click here to request access to this brand".
2) If the user does not have access, is signed in, and has already requested access, tell them "so and so is reviewing your request".
Another 10 lines to build the dynamic arel.
I can't get it straight in my head how to separate these concerns, or even if they should be separated. I appreciate any help you can offer!
Summarizing what you've said in something codelike (sorry, don't know ruby; consider it pseudocode):
void index() {
establishHierarchyLevel();
if (requestIncludedSubdomain())
fillSubdomainFields();
else
fillNonsubdomainFields();
if (user.isSignedIn() && !user.hasAccess()) {
if (user.hasRequestedAccess())
letUserIn();
else
adviseUserOfRequestUnderReview();
}
buildDynamicArelWhateverThatIs();
}
14 lines instead of 35 (of course, the bodies of the extracted methods will lengthen the overall code, but you can look at this and know what it's doing). Is it worth doing? That really depends on whether it's clearer to you or subsequent programmers. My guess is it's worth doing, that splitting out little code blocks into their own method will make the code easier to maintain.
That's a lot of variables being set. Maybe this is a good opportunity for a module of some kind? Perhaps your module can make a lot of these decisions for you, as well as acting as a wrapper for a lot of these variables. Sorry I don't have a more specific answer.
Without your code it's somewhat difficult to suggest actual fixes, but it definitely sounds like a really wrong approach and that you're making things much harder than they need to be:
3 lines of setting variables to
determine what "level" of hierarchical
data is being searched
if there is a search form, I would think you would want to pass those straight from the params hash into scopes or Model.where() calls. Setup scopes on your model as appropriate.
Another 10 lines to populate some view variables based on whether a subdomain was in the request or not.
This seems to me like it should be at most 1 line. or that in your view, you should use if statements to change what you'd like your output to be depending on your subdomain.
A 10 line section to redirect to one of two pages based on:
the only thing different in your explanation of the 2 views is "whether the user has requested access" surely this is just a boolean variable? You only need 1 view. Wrap the differences into 2 partials and then in your view and write one if statement to choose between them.
Another 10 lines to build the dynamic arel.
It might be necessary to go into Arel, but I highly highly doubt it. Your actual search call can in most cases (and should aim to be) 1 line, done through the standard ActiveRecord query interface. You want to setup strong scopes in your models that take care of joining to other models/narrowing conditions, etc. through the ActiveRecord Query interface.