It does not support Unicode. No unicode strings, no unicode regexps.
Wrong. Regexes support Unicode, and the standard library provides Unicode string functions. A lot of Rails apps are using UTF-8 without any problems. Switching my app to UTF-8 took two lines of code.
Rails sucks because David thinks security is your problem, and leaves in functionality that can easily be misused to create a security problem
Where? Tell me.
Rails sucks because its development is incredibly mysql centric, and doing anything beyond the basics with real databases will result in tons of bugs, and then you are told "try again in a few weeks when there's a new version, it should be fixed by then".
FUD. Where is Rails missing scalability or distributability? You can distribute it over as many servers as you like.
What's wrong with Rails' caching? Please explain.
Once you start getting into the nitty gritty of things where an entity uses multiple tables and has dynamic and/or very strict error/format checking... will this type of framework actually help you at all?
It will... but I agree that it's hard to tell from the simple examples.
It doesn't prevent you from mixing static with dynamic content. You can put any kind of static files in the "public" directory, which is the document root for the server. Only when a request cannot be satisfied directly from the document root it is forwarded to Rails (with mod_rewrite); Rails then extracts the information which controller/action is responsible for handling the request from the URL. For example if you request "/forum/list" from the server and there isn't a file with this name in the "public" dir, Rails calls the action "list" in the controller "forum". (The template file for this controller would be in "/app/views/forum/list", but you can easily override the template path, render a template from the database, return plain text, the content from a file or redirect to another page.)
This also offers some nice possibilities for caching: save the result from the dynamic "/forum/list" request to a file called "/forum/list" in the "public" directory, and the web server won't bother Rails with this request at all, but will deliver the file directly. If the list content is expired, delete and recreate the file. Rails also provides methods to automate this.
I suggest you just try the tutorial; I'm sure you will find that Rails is extremely flexible and doesn't set any limits to your development style.
Seperating the code structure from the website directory structure is the whole point of the MVC concept. The webserver doesn't need to deliver files with DB access code or configuration files.
Slashdot Mirror
Care to explain what these subtle aspects are? I prefer to deal with the problems when they appear; for me unicode + ruby works fine.
It does not support Unicode. No unicode strings, no unicode regexps.
Wrong. Regexes support Unicode, and the standard library provides Unicode string functions. A lot of Rails apps are using UTF-8 without any problems. Switching my app to UTF-8 took two lines of code.Rails sucks because David thinks security is your problem, and leaves in functionality that can easily be misused to create a security problem
Where? Tell me.Rails sucks because its development is incredibly mysql centric, and doing anything beyond the basics with real databases will result in tons of bugs, and then you are told "try again in a few weeks when there's a new version, it should be fixed by then".
You know what the term "beta version" stands for?What happens to the users in the middle of doing something on one server when it goes down?
Nothing happens, because the application state is contained in the database.And rails caching is per server
Wrong. You can choose between 2 distributed caching systems (DRb and MemCached).FUD. Where is Rails missing scalability or distributability? You can distribute it over as many servers as you like. What's wrong with Rails' caching? Please explain.
It will... but I agree that it's hard to tell from the simple examples.
This also offers some nice possibilities for caching: save the result from the dynamic "/forum/list" request to a file called "/forum/list" in the "public" directory, and the web server won't bother Rails with this request at all, but will deliver the file directly. If the list content is expired, delete and recreate the file. Rails also provides methods to automate this.
I suggest you just try the tutorial; I'm sure you will find that Rails is extremely flexible and doesn't set any limits to your development style.
Seperating the code structure from the website directory structure is the whole point of the MVC concept. The webserver doesn't need to deliver files with DB access code or configuration files.