This question may seem a little bit stackoverflow-implementation specific, but I have seen a similar pattern on other websites that are using REST-friendly URL rewriting as well.
For example, a link to a particular question looks like this:
ASP.NET MVC - Passing redundant arguments to actions
1388703 apparently being some kind of unique ID and the rest being the Title of the question.
The ID itself should be enough, so what may be the advantage of putting the question title (in this particular case, one can see that stackoverflow uses this almost everywhere, e.g. for badges, user profiles etc.) as second parameter?
When you remove the last part of the URL, the same page is displayed, which is expected. But when you change the last part to any other string, the same result is still displayed.
Is this only a cosmetic issue, allowing easier management of links (e.g. when storing bookmarks?) or does it have any other advantages?
It's for search engine optimization.
The link ASP.NET MVC - Passing redundant arguments to actions doesn't mean much to a search engine but ASP.NET MVC - Passing redundant arguments to actions allows a search engine to match the words "asp net mvc" etc which they will normally give more weight to as it's in the URL.
It's also more user friendly as it gives more meaning to the content of the page form the URL.
It is cosmetic and it's also better search engine optimization to keep easily readable names in the url as that will make the search engines find it easier.
The biggest advantage that the extra text has is for SEO. The extra text in the link gives google a lot more help understanding what's in the page.
I'd also mention that if a title is changed (i.e. for spelling, etc), the ID number still works.
Related
I have an Episerver site with a JobDetailsPageController with a Index method that takes a jobId parameter and creates a view with some details about that job. The urls looks something like this: https://hostname/<root-depending-on-site-tree>/jobs/?jobid=44.
What I would like is having urls on the form .../jobs/manager-position-telco-44, essentiallly creating a slug of the job title and appending the id. I have done this in the past using standard ASP.NET MVC Attribute Routing on a non-Episerver site, but EpiServer has a routing of its own that I don't know too well and can't figure out.
Also, adding non-query strings after the slash consistently sends me (no surprise) to a 404 page, so I would need to somehow customise this behaviour. I need to use EpiServers standard routing to end up at the right "parent", but ignore the latter part (the pretty bit).
Is it possible to create such urls on a normal page in page tree in EpiServer? I do understand it is possible to create static routes, but this node can be moved around like any other page so I cannot avoid EpiServer.
Please see this blog post. What you're looking for is partial routing.
#johan is right, partial routing is one way of doing this. Just wanted to add other possible solutions that might or might not match your needs.
Import data as content
Instead of serving content dynamically, you could consider importing your job ads from whatever source you have directly in content tree as separate pages below particular root page. That would give you a lot benefits - pages would be cached, it would support multiple languages, editors would see content directly in EPiServer CMS, data could be adjusted manually, etc.
This would be a good solution if your data does not change often and you need to provide a way for editor to create a new job ad manually as well.
Implement you own content provider
Another way to serve your dynamic data to EPiServer is to write your own custom content provider. You can find documentation here: http://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/7/Content-Providers/Content-Providers/
This solution requires more coding and is more complex, but it has some benefits as well. If one wanted, it would be possible to not just serve content from external data source, but also update that data by changing values directly in EPiServer UI.
I've been curious about this for a while so I thought I would ask it here on stack. I was told to always lowercase my Sitecore placeholders by a consultant helping out on one of my projects.
I was new to Sitecore at the time, so I took it in stride and never really questioned it. However, as I've become more familiar with the system and how extensible and modular it can be, I really can't imagine why this would be a requirement..?
There doesn't appear to be any documentation on the subject, however, Sitecore themselves seem lowercase their placeholders in every example site I've ever seen.
The topic is metioned a few times on the web including right here on stack, however, the question remains: WHY?
You may be referring to a specific version of Sitecore that had a bug in it. There is currently no requirement for using only lowercase. I suspect when Sitecore's dependency injection / layout engine runs, is compares the placeholder keys on the layout to the controls bound and ignores the cases when matching up placeholder keys.
I isn't a requirement that I've ever heard about and on multiple projects I've had placeholders that aren't all lower case, typically I use camel casing for those.
Stackoverflow members,
How do you currently find the balance between javascript and code behind. I have recently come across some extremely bad (in my eyes) legacy code that lends itself to chaos (someHugeJavafile.js) which contains a lot of the logic used in many of the pages.
Let's say for example that you have a Form that you need to complete.
1. Personal Details
2. Address Information
3. Little bit more about yourself
You don't want to overload the person with all the fields at once, so you decide to split it up into steps.
Do you create separate pages for Personal Details, Address Information and a Little bit more about yourself.
Do you create controls for each and hide and show them on a postback or using some update panel?
Do you use jQuery and do some checking to ensure that the person has completed the required fields for the step and show the new "section" by using .show()?
How do you usually find the balance?
First of all, let's step back on this for a moment:
Is there a CMS behind the site that should be considered when creating this form? Many sites will use some system for managing content and this shouldn't be forgotten or ignored at first glance to my mind.
Is there a reason for having 3 separate parts to the form? I may set up a Wizard control to go through each step but this is presuming that the same outline would work and that the trade-offs in using this are OK. If not, controls would be the next logical size as I don't think a complete page is worth adopting here.
While Javscript validation is a good idea, there may be some browsers with JavaScript disabled that should be considered here. Should this be supported? Warned about the form needing Javascript to be supported?
Balance is in the eye of the beholder, and every project is different.
Consider outlining general themes for your project. For example: "We're going to do all form validation client-side." or "We're going to have a 0 refresh policy, meaning all forms will submit via AJAX." etc.
Having themes helps answers questions like the one you posted and keeps future developers looking in the right places for the right code.
When in doubt, try to see your code through the eyes of someone who has never seen it before (or as is often the case, yourself 2 to 3 years down the road), and ask yourself: "Based on the rest of the code, where would i look for this function?"
Personally, I like option number 3, but that's just because it fits best with the project I'm currently working on and I have no need to postback or create additional pages.
I noticed today that SO uses magic URLs in the form. For example, a question is ".../questions/[nnn]/[description]. As an experiment when showing a question I changed the description and hit enter. As expected, it did not affect the request and the question showed just fine, only with a garbage URL:
http://stackoverflow.com/questions/1933822/flksdjfkljlfs
I assume, but could be wrong, that this reflects a RESTful approach to URLs. Since I am in the process of build a new web app, I was wondering, why is this better than than some of the more "traditional" alternatives?
http://stackoverflow.com/questions/1933822
http://stackoverflow.com/questions?Question=1933822
It seems wrong to me, for reasons I can't define, to have a URL with completely redundant and ignored information (the question name).
It's for SEO (Search Engine Optimization) reasons. Google favors URLs that have in them the text of the search query. It's a bit cheating (that is just my personal opinion) but most websites do it, including mine* :)
The URL for this question is:
What's the advantage of URLs with semantically dead components?
Let's say you search for "urls with semantically dead components". Google uses many factors in deciding the order in which results are shown; but let's say that another site has the same exact factors but an URL like www.site.com/question/1000. Google would display stackoverflow first.
*I go a bit further and 301 (permanently redirect) the most popular search engines that crawl /url/id without /text.
This is done for both the reasons mentioned above and also to have only one valid (canonical) URL for search engines.
If you choose to include extra text in your URLs I suggest you follow the same approach since google somewhat penalizes websites with duplicate content, always have one canonical URL, at least for search engines!
Well with the title as part of the URL, it has meaning when read by humans, too.
I think SO uses a nice approach here. It's a combination of user-friendly and computer-friendly information. The service is able to efficiently locate the correct question because of the ID number, while humans can quickly get an understanding of what the web page is about just by looking at the URL before even clicking on it.
I am using a rich text editor on a web page. .NET has feature that prevent one from posting HTML tags, so I added a JavaScript snippet to change the angle brackets to and alias pair of characters before the post. The alias is replaced on the server with the necessary angle bracket and then stored in the database. With XSS aside, what are common ways of fixing this problem. (i.e. Is there a better way?)
If you have comments on XSS(cross-site scripting), I'm sure that will help someone.
There's actually a way to turn that "feature" off. This will allow the user to post whichever characters they want, and there will be no need to convert characters to an alias using Javascript. See this article for disabling request validation. It means that you'll have to do your own validation, but from the sounds of your post, it seems that is what you are looking to do anyway. You can also disable it per page by following the instructions here.
I think the safest way to go is to NOT allow the user to create tags with your WISYWIG. Maybe using something like a markdown editor like on this site or available here. would be another approach.
Also keep the Page directive ValidateRequest=true which should stop markup from being sent in the request, you'll of course need to handle this error when it comes up. People will always be able to inject tags into the request either way using firefox extensions like Tamper data, but the ValidateRequest=true should at least stop ASP.NET from accepting them.
A straight forward post on XSS attacks was recently made by Jeff here. It also speaks to making your cookies HttpOnly, which is a semi-defense against cookie theft. Good luck!
My first comment would be to avoid using JavaScript to change the angle brackets. Bypassing this is as simple as disabling JavaScript in the browser. Almost all server-side languages have some utility method that converts some HTML characters into their entity counterparts. For instance, PHP uses htmlentities(), and I am sure .NET has an equivalent utility method. In the least, you can do a regex replace for angle brackets, parenthesis and double quotes, and that will get you a long way toward a secure solution.