I can't understand the benefit(s) that I can get from Url.Content() method in ASP.NET MVC. For example, you see src='#Url.Content("~/Contents/Scripts/jQuery.js")'. Why should I use it? What reasons might exist for using it? What benefits, advantages, etc. over using plain old simple references like src='/scripts/jquery.js?
Update: Based on the answers, I'd like to know if there is any other reason for using it, other than handling virtual folders? Because I haven't seen using virtual applications that much (which of course doesn't mean that it hasn't been used that much).
Usually, your web application is published as: www.yoursite.com/. The ~ character matches the root of the site /.
However, if you publish your site withing a virtual directory www.yoursite.com/mywebapp/, the the ~ character would match "/mywebapp/".
Hard-coding Urls with "/" character would cause wrong page references.
Mapping virtual paths is it's only purpose.
If you do not ever need to map them and are sure your app or it folders will not sit under other apps then it won't serve you any purpose.
From the docs note if you don't use ~ you get no change in the result anyways:
"Remarks
If the specified content path does not start with the tilde (~) character, this method returns contentPath unchanged.
"
It is usefull if your applications root path is not the root path of your server. Url.Content("~/") returns the root folder of your application.
Related
I am developing a Clojure/ClojureScript SPA based on http-kit, compojure and tiny bits of hiccup on backend and mainly reagent on frontend. Project is done with leiningen, based on hand-wrecked chestnut template.
When I tried to make more complex URLs than just "/" the following setup created a mess for me:
When producing the initial hiccup to serve HTML and adding includes for CSS and JS files I followed the examples and added them as relative urls like
(include-css "css/style.css")
;and
(include-js "js/compiled/out/goog/base.js")
(include-js "js/compiled/myproject.js")
(note absence of slash in the beginning)
In the chestnut template I got default :asset-path option for cljsbuild set to "js/compiled/out"
Of course, when I tried to add a route to the same page with the http://my-domain/something URL in addition to root http://my-domain/ and load it, the thing failed to get any of my assets (trying to fetch them under e.g. /something/js/compiled/myproject.js).
I was able to fix this issue for explicitly included assets by making those urls relative to root (prepending a slash to each of them). It left me with the same problem with the script tag with src="js/compiled/out/cljs_deps.js" injected by cljsbuild, but this one I fixed by making :asset-path relative to root as well.
It all seems to work properly now, but the fact that I had to make some head-scratching and a surprisingly large amount of googling to finally resolve this makes me feel this is not the default approach. Hence the questions:
Did I do the right thing by converting all asset urls to relative-to-root ones? (Keeping in mind that I'm working on an SPA)
If yes, why isn't this a default approach and why I keep seeing relative-to-current location URLs everywhere (including all the examples on the web as well as lein templates)?
Update:
The relevant part of my app's compojure routes looks like this:
(defroutes home-routes
(resources "/")
(GET "/" _
(friend/authenticated
(html-response
(app-page))))
(GET "/something*" _
(friend/authenticated
(html-response
(app-page)))))
This should be pretty simple I need know what dots mean in a url such as "../../../Program Files (x86)/Filed/examples/tmw_desert_spacing.png"
I'm assuming this is some kind of shorthand that means "the same as the current directory"/etc/folder/file.png a link to an article that explains this would be nice too, my google search turned up nothing since im not even sure this is called a url. thanks
more info: the program im writing won't except this as the file name, I need to konw what need to change to become acceptable.
According to RFC 3986:
The path segments "." and "..", also known as dot-segments, are
defined for relative reference within the path name hierarchy. They
are intended for use at the beginning of a relative-path reference
(Section 4.2) to indicate relative position within the hierarchical
tree of names.
The takeaway is that they have the same meaning as in paths on a linux or windows system - single dot means "the directory specified by the preceding part of the path", two dots mean "the parent directory of the directory specified by the preceding part of
I think (correct me if I am wrong) that it is better to put a / at the end of most of url. Like this: http://www.myweb/file/
And not put / at the end of filenames: http://www.myweb/name.html
I have to correct that in a website with a lot of links. Is there a way I can do that in a fast way. For instance in some programs like Dreamweaver I can use find and replace.
The second case is quite easy with Dreamweaver:
- Find: .html/"
- Replace: .html"
But how can I say something like:
- Find: all the links that end with a directory. Like http://www.myweb/file
- Replace: the same link but with a / at the end. Like http://www.myweb/file/
Your approach may work but it is based on the assumption that all files have a file extension.
There is a distinct difference between the urls http://www.myweb/file and http://www.myweb/file/ because the latter could resolve to http://www.myweb/file/index.php, or any other in the default set configured in your web server. That URL could also reference a perfectly valid file which doesn't contain a file extension, such as if it were a REST endpoint.
So you are correct insofar as you should explicitly add a "/" if you are referring to a directory, for example if you are expecting the web server to look up the correct index page to respond, or doing a directory listing.
To replace the incorrect URLS, regular expressions are your friend.
To find all files which have an erroneous "/" you could use /\.(html|php|jpg|png)\//, adding as many different file extensions into that pipe-separated list as you like. You can then replace that with .$1 or .\1 depending on your tool.
An example of doing this with Perl would be:
perl -pi -e 's/\.(html|php|jpg|png)\//.\1/g' theFileYouWantToCheck.html
Of (if you're using a Linux-based system) you can automate that nicely with find:
find path/to/html/root -type f -name "*.html* | xargs perl -pi -e 's/\.(html|php|jpg|png)\//.\1/g'
which will find all html files in the directory and do an inline find and replace. Assuming you're using version control, it's then easy to see the changes it's applied :)
Update
Solving the problem for adding a slash to directories isn't trivial. The approach I'd take:
Write a script to recurse through your website structure locally, making a list of all files
Parse the HTML files to extract all href=".*" and replace them with href=".*/" only if the end of the URL isn't present in the list extracted by the first script.
Any text-based find and replace is not going to be aware of whether the link is actually to a file or not.
I'm almost finished developing my large project, however I would love it if I could make it so instead of having the users profile pages at: http://example.com/profile/username/USERNAME
(i'm currently using .htaccess to rewrite the GET data into forward slashes and profile(.php) being read as just 'profile' profile.php also parses the url correctly to retrieve the GET data)
But it would be some much better if I could do it so that it's like http://www.example.com/USERNAME (preferred) or http://www.USERNAME.example.com
Any ideas or resources?
Thanks,
Stefan
In your .htaccess in the root, add
RewriteRule ^/([^/]+)/? /profile/username/$1
This matches paths that don't include a slash (so no directories in the path) and suffixes the path to /profile/username/. The path can include an optional final slash.
(+1 for the comment about namespaces - it's a little dangrous having usernames in the root of your site. I've tried to limit the impact of this by only giving out the namespace comprising a single directory. Paths with multiple directories will be handled as normal.)
We have a requirement that every piece of code that makes it into production will be reviewed by a senior developer.
The way I have envisioned this working is by a naming convention for branches that regular developers cannot check code into.
Following the SVN recomended directory structure this translates into something like.
[project-name]/trunk/
[project-name]/branches/
[project-name]/branches/development-01
[project-name]/branches/development-02
[project-name]/branches/task-increasefontsize
[project-name]/branches/release-01
[project-name]/branches/release-02
[project-name]/tags/
So in the authz file I would like to have something like the following
[/]
#developers = rw
[/*/branches/release-*]
#developers = r
#senior_developers = rw
However I can't find any evidence that SVN supports * (or any other wildcard character).
Is such a thing possible or do I need a pre-commit hook?
It is possible to do a directory structure of
[project-name]/trunk/
[project-name]/branches/development-01
[project-name]/branches/development-02
[project-name]/branches/task-increasefontsize
[project-name]/branches/release-01
[project-name]/branches/release-02
[project-name]/tags/
[project-name]/releases/
and deny access to releases but that still leaves you having to do one denial listing per project and worse its not adhering to the SVN standard project structure.
It is not possible to have wildcards as you like to use them. For this purpose you should take a look at svnperm.py script (just google for it) it will match exactly this purpose.