Ruby On Rails 1.2 Released

Scooter[AMMO] writes "David Heinemeier Hansson sent a post to the Rails 1.2. This new version adds a slew of buff and polish to the rest of the system, as well several new features like RESTful interfaces, response formats, improved multi-byte support, and more. If you haven't checked out the web application framework that aims to renew joy within its users, give it a look. You may be amazed at how easy it makes things without sacrificing power or functionality."

Comments

Re:Improved multi-byte support?

[jrumney]

If you'd RTFA instead of rushing to get first post, you would have seen this:

So since Ruby won't be multibyte-aware until this time next year, Rails 1.2 introduces ActiveSupport::Multibyte for working with Unicode strings. Call the chars method on your string to start working with characters instead of bytes.

Re:No Mongrel

[dam.capsule.org]

Maybe you can have a look at JRuby: http://jruby.codehaus.org/.

They aim for 100% Rails compatibility (I think they are nearly there) and there are developments to allow deployment of your rails application using Java's war web archive system to a Java application server.

Rails 1.2 & Engines

[What the Frag]

For all guys currently using engines, you might want a look at this:

http://rails-engines.org/news/2007/01/03/engines-a re-dead-long-live-engines/

Comparision between Rails and Django

[Anonymous Coward]

http://jesusphreak.infogami.com/blog/why_django

Whew

[tcopeland]

It's getting installed at a furious rate... we're doing around a gem a second now.

Re:I never quite understood the benefit of Rails

[tcopeland]

> All it seems to do is offer a way to do very similar
> and simplistic web apps without any real-world functionality.

You may want to look closer; it offers ways to do very complex web apps with lots of real-world functionality.

> I also wonder about the performance and memory profile; seems
> that the way it handles databases is exactly what DBA's hate to see.

In practice, ActiveRecord works out very well.

> none of the websites it can create is worthwhile.

To the contrary, the websites a programmer can create with Rails are very worthwhile.

Re:Improved multi-byte support?

[dwerg]

Thanks for the vote of confidence. You might be surprised to know that we thought about all this before we started working on AR:Multibyte.

AR:Multibyte is currently mostly used internally in Rails to make methods multibyte safe. It will be really easy to phase it out when internal support arrives.

Ruby is getting more multibyte support 'in a year', which means that it's at least going to take a few years for everyone to actually get the new version in their OS.

Re:Improved multi-byte support?

[tcopeland]

> I would have thought that multi-byte languages
> would have been a big deal from the start.

Yup, they are. Ruby supports UTF-8, JIS, and various other multi-byte encodings. It just doesn't have support for all the Unicode encodings.

Keep in mind that other languages have to change as Unicode changes as well. For example, Java's char primitive is 16 bits, which for a while was enough to store all the Unicode characters. But with Unicode 3.1, supplementary characters can be 21 bits. That's why Java 1.5 introduced a bunch of new Character methods that accept an int, not a char.

Re:No Mongrel

[tcopeland]

> It's too bad Rails 1.2 wasn't released with mongrel

Well... maybe. I agree, Mongrel rocks, we use it for indi and it's quite solid.

But does Rails really need to depend on it? I think the current solution - using Webrick for development and then deploying to a full-up Apache+mod_proxy_balancer_Mongrel - works pretty well.

Django does't use SQLObject

[tabo_peru]

Django doesn't use SQLObject. You can, as a programmer, use it of course, since everything in Django is nicely decoupled, but Django uses it's own ORM. The main advantage of using this ORM is of course the production ready administration interface that you get for free, but if you don't need that, there is nothing stoping you from using SQLObject or even better, SQLAlchemy. In fact, there is even a branch in Django to have SQLAlchemy support in the framework.

Using a different ORM, template engine, etc in Django is just a import statement away.

Re:Improved multi-byte support?

[aldheorte]

If I remember correctly, there is a cultural issue here in that Unicode is apparently considered with some disdain in Japan and local multi-byte encodings are used, one of which Ruby supports. If you do some searches, you can probably find the full background story.

On the purpose of a framework.

[Spaceman40]

A framework forces everyone to "stay in bounds."

I've worked on several different webapps, from small and personal to large and corporate, using several different frameworks (J2EE, Django, Rails) as well as just straight PHP/ASP/static HTML. Frameworks don't really force anyone to stay in-bounds.

All of frameworks I've used allow you to drop down to straight SQL for database work, ignore their models and templating (or substitute others), and completely mess up the MVC pattern, if you want. Django goes the farthest towards restricting your options in the latter respect, but it's still possible.

I know you're somewhat kidding, but I just wanted to note that the reason for a framework is above all to have a starting point. Some frameworks do a much better job at that than others, but that's the purpose. If the only purpose was to restrict, they'd be more annoying than not, and people wouldn't use them by choice at all.

Re:Improved multi-byte support?

[iluvcapra]

There was a good AC post about it in the "Ruby as a Lisp" posting a few days ago:

It basically has to do with the fact that Unicode uses Han Unification to cause Chinese and Japanese ideograms to share codepoints, and Japanese aren't down with that, so they use Shift-JIS. Check the postings that reply to it for a big digression on the issue ;)