RJS сейчас завязан на prototyepe например, и его не отключить. В то время как jQuery — очевидный выбор. В 3.0 это пофиксят.

на руби было 2 фреймворка-конкурента. Рельсы и Мерб. разработчики решили, что лучше обьединить усилия и обьединились. Рельсы 3.0 будет фреймворк включающий в себя лучшее из 2ух.

ПС. мы как-то с другом обсуждали когда-то (когда рельсы 2.0 только вышли), что рельсы на столько круты, что хз чего ещё там можно улучшить.

Охх

В кратце поясню: стандартный дистрибутив рельс поставляется с кучей всяких фишек, от веб-сервера до привязанного яваскрипт фреймворка, что безусловно удобно для нубской разработки, но бесполезно для продвинутой. Это было принято во внимание, и сейчас ведется работа над дополнительной модуляризацией фреймворка. Как я понимаю в РоР 3.0 можно будет набрать себе только необходимых компонент и не тащить за собой вагон того, чем не воспользуешься.

Так и в Руби. Автор руби был в большей степени заинтересован в качестве самого языка, чем в скорости его интерпретатора (что очень правильно, на мой взгляд). А теперь можно и по-оптимизировать;)

да и вообще;)

ну на подходе так же и Java 7 никто не совершенен )

в данный момент именно этим и занимаются

нет конечно. такие задачи стоят перед другими приложениями которые у нас пишут на Java, и соответственно для этих нужд используется Hibernate

ActiveRecord используется у нас довольно ограничено – тупо для заполнения базы данными для тестов, впринципе можно было бы и без него обойтись

named_scope-ы?
различные связи и ассоциации?
полиморфик модели?
валидация?
before_save/after_save?
обзерверы?

Это первое что в голову пришло.

нелюбовь к ORM? на не сказал бы что уж так радикально. Но особой тяги к таким штукам не испытываю, это верно.

Я не говорю что ActiveRecord это плохо. Напротив – на работе используем его, и всё нормально. Я просто для веб-а не программирую, поэтому у меня может быть немного извращённый взгляд на вещи

Это когда я такое говорил? Для себя я бы писал скорее всего только на Рельсах.

>>Если я не ошибаюсь PureMVC для ruby позволяет отвязаться от ActiveRecord и тем самым работать так же удобно с legacy базами. Так что счастье с ruby может быть и без ActiveRecord-a

использование рельсов вовсе не обязует использовать АктивРекорд.
омг, Антон, что за нелюбовь к ОРМ-мапперам?

* http://anton-arhipov.livejournal.com/60738.html
* http://alex-inside.livejournal.com/641402.html

Почитал комменты, и в общем-то вижу что как и любая новая относительно радикальная технология (RoR) вызывает желание похоливорить.

Для меня проблема RoR — это сложность legacy поддержки старой БД сайта и тем более апгрейда сайта — переписывать занова придётся. Да ещё и хостинг скорее всего другой и более дорогой придётся брать.

Это как с Джаваским Томкэтом — было сложно найти хостинг чтобы потестить live свои java-сервисы. Это сильно мешает распространению имхо.

Ну а если для работы, если клиент хочет, то можно всегда для него и не только на Ruby пописать =)

Ну, и как Ярик говорит, для себя проэкты я бы врят ли на Ruby писал =)

Но Руби мне понравился. Хотелось бы ещё продолжение, а так же подобную сессию программинга на Python.

> На каждом шагу мультиязычные
> данные, причём, для разных
> языков/стран одни и те же
> предложения могут меняться
> местами, а в предложения
> подставляются различные
> переменные
С некоторых пор проблемы с L10n в рельсах решены для хранения полей моделей на разных языках есть плагин globalize2

> у всех всё идеально, 1 модель
> – 1 форма, автоматическая
> валидация данных, никаких
> лишних условий… вот не верю!
Естественно частные случаи не покрываются ни в одном фреймворке. Задача любого фремворка это предоставить достаточное покрытие основных сценариев, а так же поддержать легкость кастомизации. Не возможно написать фреймворк который будет учитывать пожелания каждого. В добавок ограничения всегда стимулируют простые методы, и не дают бессмысленно раздувать интерфейс.

> Но клиент часто хочет всё
> засунуть на одну страницу
> в огромную форму, которая
> могла бы управлять шатлом.
А воспитывать клиентов не получается? Тогда сочувствую. недавно был инцидент, когда один чел наехал на сайт American Airlines – у них тоже любят сложные формы. Он предложил облегченный вариант, вы наверное в таком же положении как и дизайнер AA сайта который описал реальность.

> Наверное слишком жесткая
> привязка к ActiveRecord
> (да и вообщение продвижение
> идеи, что Модель – это слепок
> данных с прикрученной …

Вначале я тоже пытался бороться с фреймворком. Потом читал много кода, посмотрел как мои проблемы решают другие люди. Пересмотрел почти все скрикасты, после этого полегчало

> Отсутствие скринкастов по
> темам связанным с наследованием
> в ActiveRecord да и вообще с
> наследованием.

А для каких цедей нужно наследование? Может это не ruby way? На уровне моделей понятие полиморфизма вполне поддерживается. Если надо какой-то код между классами прошарить то можно всегда mixin сделать.

Большая проблема для рельсов – это legacy DB. Одно дело если ты базу с нуля рисуешь, другое дело если что-то досталось по наследству. Схема у базы как правило не ложится в концепции ActiveRecord, и его использование становится не возможным. Поэтому будет нужна миграция. В случае большого объема данных – это самоубийство.

Прошу прощения за длинный коммент, не было времени написать коротко.