I'm a student of web development (and college), so my apologies if this comes off sounding naive and offensive, I certainly don't mean it that way. My experience has been with PHP and with a smallish project on the horizon (a glorified shift calendar) I hoped to learn one of the higher level frameworks to ease the code burden. So far, I looked at CakePHP Symfony Django and Rails.
With PHP, the URLs mapped very simply to the files, and it "just worked". It was quick for the server, and intuitive. But with all of these frameworks, there is this inclination to "pretty up" the URLs by making them map to different functions and route the parameters to different variables in different files.
"The Rails Way" book that I'm reading admits that this is dog slow and is the cause of most performance pains on largish projects. My question is "why have it in the first place?"? Is there a specific point in the url-maps-to-a-file paradigm (or mod_rewrite to a single file) that necessitates regexes and complicated routing schemes? Am I missing out on something by not using them?
Thanks in advance!
URLs should be easy to remember and say. And the user should know what to expect when she see that URL. Mapping URL directly to file doesn't always allow that.
You might want to use diffrent URLs for the same, or at least similar, information displayed. If your server forces you to use 1 url <-> 1 file mapping, you need to create additional files with all their function being to redirect to other file. Or you use stuff like mod_rewrite which isn't easier then Rails' url mappings.
In one of my applications I use URL that looks like http://www.example.com/username/some additional stuff/. This can be also made with mod_rewrite, but at least for me it's easier to configure urls in django project then in every apache instance I run application at.
just my 2 cents...
Most of it has already been covered, but nobody has mentioned SEO yet. Google puts alot of weight on the URL itself, if that url is widgets.com/browse.php?17, that is not very SEO friendly. If your URL is widgets.com/products/buttons/ that will have a positive impact on your page rank for buttons
Storing application code in the document tree of the web server is a security concern.
a misconfiguration might accidentally reveal source code to visitors
files injected through a security vulnerability are immediately executable by HTTP requests
backup files (created e.g. by text editors) may reveal code or be executable in case of misconfiguration
old files which the administrator has failed to delete can reveal unintended functionality
requests to library files must be explicitly denied
URLs reveal implementation details (which language/framework was used)
Note that all of the above are not a problem as long as other things don't go wrong (and some of these mistakes would be serious even alone). But something always goes wrong, and extra lines of defense are good to have.
Django URLs are also very customizable. With PHP frameworks like Code Igniter (I'm not sure about Rails) your forced into the /class/method/extra/ URL structure. While this may be good for small projects and apps, as soon as you try and make it larger/more dynamic you run into problems and have to rewrite some of the framework code to handle it.
Also, routers are like mod_rewrite, but much more flexible. They are not regular expression-bound, and thus, have more options for different types of routes.
Depends on how big your application is. We've got a fairly large app (50+ models) and it isn't causing us any problems. When it does, we'll worry about it then.
Related
I'm trying to host multiple rails apps for my blog. Kind of like www.blog.com/app1 will have one rails app, www.blog.com/app2 will have another. How do I do it?
Although I agree with downvotes as pointed out by the first comment, I had this problem myself several months ago and actually didn’t even try to solve it as I realized how many implications this has. Existing answers on Stack Overflow address either slightly different or narrower issue so they may use some things mentioned here but don’t elaborate on implications or alternatives, yet there’s an interesting overview (and also other answer to that question). Anyway, I took it as a challenge and dived in.
First, there are multiple approaches depending on your scenario:
All applications are code which you maintain – it’s probably the best to explore something called engines. They are like mini RoR applications mountable to certain path within normal RoR application. It has many benefits like sharing the same runtime or simple isolation configured in on place.
If there are no AJAX with URL or similar dynamisms or that they are actually AHAH (i.e., asynchronous HTML and HTTP – returning HTML fragments instead of XML or JSON data) which is very natural for Rails although often not used, you can use sophisticated proxy modules like mod_proxy_html which rewrite links inside HTML documents while proxying. Similar modules exist for nginx but are not part of standard distribution.
RoR has a configuration option relative_url_root which allows deployment to subdirectories. It’s very fragile and often buggy, many gems or engines break when you use it, so beware. When you get it right, it looks like magic. However, your configuration relating to subdirectory will be scattered throughout different software configs and your code.
I created an example repository while exploring the last option. README should say everything necessary to run the code.
The most important observation from this small project is that when using relative URL root, you almost certainly want to scope all your routes. There are different setups possible, but they are even more complicated (which doesn’t mean they don’t make sense). For examples see the answer with overview mentioned above.
By default (without scoped routes), only asset paths are prefixed with relative URL root, but not action route paths even though it makes URLs generated by helpers useless unless translated by mod_proxy_html or probably more custom solution.
Other important observation, which relates to official guide, code “out there” and answers to similar questions here on Stack Overflow, is that it’s good to avoid forward slash at the beginning of relative URL root. It behaves inconsistently between tests and the rest of the code. Yet it can be used nicely around your code – see scope definition in routes config or dummy controller test case.
I got to these and other observations by creating two very simple and almost identical Rails 5.2 applications. Each has one action (dummy#action) which has a route scoped to relative URL root. This action, or its view specifically does two important things to verify that everything works:
it outputs the result of calling root_path helper which shows we have correctly setup URL/path helpers (thanks to scoped route in config/routes.rb)
it loads static asset which isn’t served by Rails application but directly by Apache HTTP Server and which is referenced by image_path helper
You can see that virtual host configuration has rather extensive list of URLs which shouldn’t be passed via proxy and rely on aliased directories. However, this is application specific and very configurable, so simpler setup with different directory layout is definitely achievable but entirely separate topic.
If you like Passenger and don’t want to use proxying in your HTTP server, you can find more information in their deployment tutorial.
I am a rails developer working on a cakephp site. The more work they send me, the more php code I write and thus the more dependence on php we introduce. What I want is to stop writing new features in php and start writing them in rails. Our resources are limited and the existing php site is huge so a full port from cake to rails is not possible.
Is there some way to write new features in a rails app while maintaining and allowing access to all the functionality of the old php (and vice-versa)?
It seems I would need a route aware app to traffic requests to either php or rails, but then we run into the issue of, for example, existing user functionality written in php not being available to the rails app and vice-versa.
What about something to translate ruby into php? That way I could start writing my model stuff in ruby/rails rather than php.
I feel like my question is muddled by the fact I do not know how to ask the questions I want to answer, so hopefully this is understood.
As always, thanks in advance!
One approach that you may find useful is to leverage the power of your web-server to properly re-write and delegate requests to two different systems. If you can design your new Rails application to use the same database records as the old one, with models mapping to the old tables directly, and ensuring that sessions established by one are valid in the other, you have a lot of latitude in how you go about doing this.
Apache has a very full-featured URL rewriting and proxying system that can be configured to direct "legacy" parts of your site to an existing set of PHP scripts while directing all other traffic to the new Rails application. You will need to be careful to ensure the design of both applications are nearly identical or it may seem strange to users.
Another approach that helps ensure a consistent appearance is to strip out a lot of the theme from your PHP application. By creating very bare-bones pages that only expose the required functionality on each page, Rails can fetch these by passing through any relevant session authentication information and re-frame them in the right layout.
This way you can preserve existing functionality and have it embedded inside your new application. You can use something as simple as open-uri or the curb gem to handle this HTTP-level delegation.
You would end up with controllers that look like this:
class PaymentController < ApplicationController
def index
#content = fetch_legacy_url('/payments/index.php'))
end
end
The fetch_legacy_url method would create an HTTP fetch request that includes the required headers, cookies, and so forth, and return the response body. Your view then ends up looking something like this:
<%= #content =>
From there you can shunt parts of the PHP layout over to the Rails app piece by piece. For instance, ripping out large chunks of static HTML and putting them in the Rails template would reduce the amount of actual PHP code you have to port.
It's a bit messy to maintain two applications in parallel, but as you point out the alternative is to keep accumulating technical debt and making the inevitable re-write that much more significant an undertaking.
The first step would be to experiment and see if you can create a Rails environment that uses your existing data, or at least the data relevant to the new functionality you intend to build out.
Most of the time, whenever I hit a website that looks "bubbly" in nature, and all prettified in those pastel-like colors, I think to myself, "This was probably done with Rails." And, lo and behold, after some digging into the site's information pages I discover this is actually true. So, I pose the question, not knowing much about Rails but enough about Django to understand how the database stuff works:
Does RoR have any display-specific qualities that affect how a web page looks? Or do all RoR devs naturally use the same Adobe tools to make everything look so ubiquitous?
Ruby on Rails is a server side technology, so it doesn't lend any specific quality to the user visible design. That said, it is a "trendy" technology so people who are likely to write their back-end code with RoR are likely to choose a particular "Web 2.0" style for their views.
As a Ruby on Rails developer, I can tell you that most Ruby on Rails developers are passionate about their work and we pay a lot of attention to details when building websites as much backend as front end. Its not just a trend, its a way of thinking and working.
No, it hasn't any display-specific qualities.
The theory is that RoR makes that backend stuff easier, so more time can, and apparently is, spent on the front end stuff.
Its all done with Mirrors. And CSS. :)
Rails is a very popular Web framework, it's just be coincidence that all the ones you've looked at have been rails apps.
What kind of sites have you been looking at to draw this hypothesis?
that's a funny question with a funny description :) ... bubbly!
As a madman, I develop with RoR, it's kind of rule in our area. We learn madness from the beginning, as a result of http://railsforzombies.org...
May wise men follow a wise path!
Short Answer: NO
However...
As a Rails developer I can say that due to the Agile nature of Rails and the speed in which you can develop web applications with Rails I do find myself having more time freed up on a project to spend polishing the user interface. I believe this may be a reason you often see more polished looking Rails sites.
So in my mind I believe your choice of framework can have a direct correlation to the end product that is produced!
Rails does add some stuff to the front end. Like to every html form, it will add a hidden input element authenticity_token.
You can also tell because rails URLs and form actions will never end with suffixes like .aspx or .php or .html or .jsp, and they won't usually append ?query=book&encoding=utf8 like you see on google. And they won't usually have superlong crufties like you see on amazon (eg http://www.amazon.com/Agile-Web-Development-Rails-Ruby/dp/1934356549/ref=sr_1_1?ie=UTF8&qid=1297922135&sr=8-1). Instead Rails prefers simple routing URLs. If amazon were written in rails, you might instead expect amazon.com/books/Agile-Web-Development-Rails-Ruby
So there are ways to spot a Rails app. I expect other web frameworks, especially the ones that emulate rails, would duplicate some or all of these features, so this isn't a sure-fire method, but it helps.
I am looking at implementing URLMapping for a personal project. I am already aware that solutions exist so please do not answer suggesting I should use one.
What I want is to harvest the opinions of fellow developers and web users on URL mapping implementations. Specially I would like you to answer:
Which is your favourite implementation?
What do you like about your favourite implementation?
What do you not like about your favourite implementation?
How would you improve it?
I would like you to answer from two points of view:
As a developer
As a user
I would be grateful for any opinions on this matter, thanks!
I've only worked with django's URLConf mechanism. I think the way it relies on the urlpatterns variable is a bit flimsy, but I like its expressiveness in specifying patterns and dispatching to other url configurations. I think probably the best thing is to figure out your URL scheme first, and then try out a couple of solutions to see what matches best. If you're going hard-core REST using the full complement of GET/POST/PUT/DELETE, and checking the user agent's Accept headers, and all that, django will, by default, have you splitting your logic between URL config files and view files, so it might not be the cleanest solution.
However, since it's all Python, you might be able to do some more complex processing before you assign to urlpatterns.
Really, you want a system that does what you need. Your URL scheme is your API, so don't compromise on it based on the tools you use. Figure out your API, then find the tools that will let you do that and get out of your way.
Edit: Also do a google search for "URL scheme design." I found this without much effort: http://www.gaffneyware.com/urldesign.htm. Not comprehensive, but some good advice gotten from looking at what flickr does.
Well, I should have noticed the url-routing tag shouldn't I? :-) Sorry about that.
jcd's experience mimics mine - Django is what I use too.
I like the fact that the routes for an app reside within the app (in urls.py) and can just be included into any projects that might make use of that app. I am comfortable with regular expressions, so having the routes be specified in regex doesn't phase me (but I've seen other programmers scratch their heads at some more uncommon expressions).
Being able to reverse a route via some identifier (in Django's case by route's name) is a must. Hardcoding urls in templates or controllers (view in Django) is a big no-no. Django has a template tag that uses the reverse() method
The one thing I wish I could do is have the concept of default routes in django (like Rails does or even Pylons). In Django every route has to map to a view method, there is no concept of trying to call a certain view based on the URL itself. The benefit is that there are no surprises - your urls.py is the Table of Contents for your project or app. The disadvantage is that urls.py tend to be longer.
Given my new understanding of the power of "includes" with PHP, it is my guess that ALL of my pages on my site will be .php extension.
Would this be considered strange?
I used to think that most pages would be .htm or .html, but in looking around the net, I am noticing that there really isn't any "standard".
I don't really think I have a choice, if I want to call my menus from a php file. It is just going to be that way, far as I can see... so just bouncing off you all to get a feel for what "real programmers" feel about such issues.
The thing that actually matters to the browser isn't the file's extension; it's the MIME Type that it gets sent in the HTTP headers. Headers are data that gets sent before the actual file and tell what kind of data it is, how big it is, and a bunch of other unimportant junk. You can configure your server to send any file extension as an HTML page, but the most common extensions for HTML pages are .htm, .html, .php, .asp, .aspx, .shtml, .jsp, and several others.
As for it looking "strange", a surprisingly small number of users will actually look at the address bar at all, let alone notice that the file extension is .php instead of .html. I wouldn't worry about it if I were you; it really doesn't make a difference.
generally - make sure your URLs are easily read, reflect the content beneath them, and don't change. the "not changing" part can be tricky, especially when you shift technologies over time (html>php>aspx).
to achieve this just ensure that each area of your site appears to reside in its own subdirectory.
mysite.com/news/
mysite.com/aboutus/
mysite.com/products/
etc.
you can either do this by physically structuring your site in this fashion and using default documents (default.html/php/aspx), or using something like mod rewrite, ISAPI rewrite, or similar to rewrite these paths to the appropriate docs.
someone who's keen on SEO or marketing might have a different idea about what constitutes a "good" URL, but as a developer this is how i see it.
Ending URLs in .php is fine technically, but I think these days many people are trying to make the urls independent of the actual code/file structure.
I actually think that's a good thing from a software engineering perspective as well. URLs are conceptually different (read: not related at all) to the file/directory structure used to organize the system powering the website.
The "resource" that a URL "locates" is not the .php or .asp file that contains the code to display it.
Look at stackoverflow for example, the URL of this question is /questions/322944/uql-etiquette, there's nothing in it that can be used to "guess" the underlying framework/system. The resource in this case is the question and all the answers to it, as well as the comments, votes, edits, and various other stuff.
It doesn't matter what your URLs end with, .php is fine, and fairly common. The only thing people care about these days when it comes to URLs is making them pretty for Search Engine Optimisation, but that's a whole new question.
Real programmers use URLs like /noun/verb/id/ & don't show file extensions at all :p
Personally I use Apache's mod-rewrite.
(on a slightly less tongue-in-cheek note) It's worth mentioning, specifically for includes, that you should ensure your actual files have the extension .php. I've seen more than one site where programming logic can be viewed in-browser 'cos the developer ended their files .inc (or insert non-auto-parsed extension of choice here).
As far as url etiquette goes - I really don't think etiquette is involved; however if you have sophisticated users visiting your website who have strong views on platforms and technologies, using .php or .aspx extensions could put off users - perhaps subconsciously.
If you use apache, it's fairly easy to make a .php be read as a .py and vice versa by changing the httpd.conf file. My current practice is to use .html extensions (or no extensions at all) and treat all files as .php.
Whatever you decide, do make sure that you never break an existing url. It's possible to achieve that even if you keep .php as the extension and decide to change the technology later.