Ruby On Rails 1.1

> Во как народ без пикля мучается!

Простите, без чего?

> Не надо малохольный руби сравнивать с питоном.

Аргументы малохольности будут?

РжуНиМагуОстановитьсяКатаюсьПоПолу

>> Во как народ без пикля мучается!

> простите, без чего?

http://docs.python.org/lib/module-pickle.html

А также:

http://www.gnosis.cx/download/gnosis/xml/pickle/doc/HOWTO

http://pyyaml.org/wiki/PySyck

:P

>Что в MVC сложного, я когда такой аббревиатуры не слышал, свой PHP фрэймворк писал оказываеться именно как MVC (криво конечно),

"Наше троекратное ура изобретателям велосипедов!"(C)Лозунги КПСС к 1 мая 1983года

Дятел! Без изобретателей велосипедов мир встанет раком под тяжестью решений от проприентарных монстров. хочешь войти в Рай стань ребенком. Десятый велосипед всегда почти Харлей-Девидсон.

Где вы видели ваш Пикль со стороны клиента?

Ага, вот оно что, обычный инструмент для сериализации ;)

>Без изобретателей велосипедов мир встанет раком под тяжестью решений от проприентарных монстров. хочешь войти в Рай стань ребенком. Десятый велосипед всегда почти Харлей-Девидсон.

Хочешь сказать MVC изобрел корпоративрый проприетарный монстр? Имя, сестра, имя! Назови его. Уж не Smalltalk ли это?

Кстати, а бутлоадер ты тоже каждый день изобретаешь, чтобы лялих загрузить? Или пользуешься готовым? А Unicode-таблица у тебя тоже своя, собственная?

Когда вы перестанете каждый день изобретать то, что уже изобретено, тогда может быть лялих и сдвинется с мертвой точки и у него появится гораздо больше бета-тестеров. А пока они предпочитают бесплатно тестировать Vista.

Что есть в руби на рельсах, чего нет в указанных проектах? Если нужно что-то сложнее, чем турбогеарс - это уже zope, но до него руби-на-рельсе будет ещё доооолго-долго ехать.

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

Например проекты типа twistedmatrix мне покажите на руби.

Ха-ха-ха ... !!! Смелсо! Это типу в пику жабе что ли? Типа моська в пику самолету?

> Что есть в руби на рельсах, чего нет в указанных проектах?

Нормальная релизация.

> Если нужно что-то сложнее, чем турбогеарс - это уже zope, но до него руби-на-рельсе будет ещё доооолго-долго ехать

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

> Питон как известно с батарейками, а уж сторонней фигни под него написано - названия одни можно недели две распечатав читать.

По сравнению с CPAN все одно сосет.

> Например проекты типа twistedmatrix мне покажите на руби.

А это что, считалка? Тогда смешно.

Хороший фреймворк. После php намного приятнее работать. Теперь насчет сравнения Руби и Питона.

Использовал оба языка и оба нравятся. Если взять объективно и непредвзято, Руби богаче возможностями, но фишка с отступами в Питоне очень пришлась по душе.

Сейчас программирую на Рейлс и очень приятная штука. Кода получается намного меньше чем в ПХП. ОРМ реально очень облегчает жизнь, написал уже треть проекта и еще не использовал ниодного SQl-запроса. Приэтом для использования этого ОРМ-а нужно указывать только самые общие связи. Нарпример, если модель новости хранит id пользователя, который ее добавил, это выглядит так:

class News < ActiveRecord::Base belongs_to :user end

class User < ActiveRecord::Base has_many :news end

Такое простое описание позволяет автоматически делать выборки, задействуя лефт-оутер-джойн примерно так:

list = News.find(:all, :include => 'user')

Выберет все записи из таблицы и сделает оутер джойн для таблицы users. Теперь, чтобы узнать имя пользователя достаточно написать: user_name = list.user.name

Еще пример. У меня обычно объекты не удаляются, а помечаются, как скрытые. В Рейлс для этого есть возможность указать область. Например, когда я буду делать выборки, мне не нужно писать всюду WHERE hide="N". Я могу указать в нужной области with_scope {} и работать без дублирующихся условий. Кроме того, очень много фишек связанных со сложными типами связей. Например один-ко-многим как раз в Рейлс 1.1 очень легко обрабатывается без лишней головной боли.

Короче, если логика приложения нетривиальная, вам сюда http:://www.rubyonrails.com/ .

Теперь насчет Джанго. Я много слышал про него и посмотрел возможности. Они впечатляют. Мне к примеру пришлось потратить две недели, чтобы сделать описание админ-интерфейса с помощью простого ассоциативного массива для Рейлс. Тоесть стандартные операции CRUD. Судя по описанию в Джанго это с коробки. Я раньше слышал про него позитивные отзывы и думаю попробовать его в своем следующем проекте :).

В любом случае, тот кто читает этот топик, и Джанго и Рейлс много лучше чем что либо созданное для ПХП до сих пор. И я думаю, что уже ничего путнего для него не сделают, потому как в западло делать для такого ограниченного языка что-то мощное... Переходите на вещи, которые позволят вам писать реально намного быстрее, а главное с УДОВОЛЬСТВИЕМ.

> Условие тз - есть у клиента софт, который по фтп забирает файлы. Эти файлы должны динамически создаваться. 

XML?

>> News.find(2).to_xml

>> puts News.find(2).to_xml
<?xml version="1.0" encoding="UTF-8"?>
<news>
  <title>sdf</title>
  <body>dsagl</body>
  <id type="integer">2</id>
  <summary>dpfkasd</summary>
  <created-at type="datetime">2006-03-07T18:42:52+01:00</created-at>
</news>


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


А то что большая часть приведённого кода есть макровызовы, которые 
генерируют необходимые функции для данного вида данных. Например у нас
 есть дерево категорий. Создаём таблицу categories: id, title, parent_id.

class Category < ActiveRecord::Base
   acts_as_tree
end

Всё. Теперь класс автоматически отмэписля на таблицу categories, при 
чём у него есть методы children, parent, ancestors, root и другие. 
Причём например удаление элемента влечёт по умолчанию удаление всех 
потомков. Т.е. и это только маленький пример. Разарботка на Рельсах 
состоит в использование и создание различных DSL для веб разработки.

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

>Во как народ без пикля мучается!

Пикль - втопку. Не юникс вэй. Человеко-редактируемая сериализация рулит.

>Например, когда я буду делать выборки, мне не нужно писать всюду WHERE hide="N". Я могу указать в нужной области with_scope {} и работать без дублирующихся условий.

А луче не изобретать велосипеды и прописать в класс acts_as_paranoid и всё.http: //ar-paranoid.rubyforge.org/

Кхе-кхе. А можно по-подробнее, какие языки лучше? И если можно полный список.

Немного не то. Например, админ пишет новость, но время, чтобы ее выложить еще не пришло. Или человек пишет статью, но не сразу ее выкладывает, а еще доводит некоторое время. Он ее хайдит, а потом, когда нужно выкладывает. А в параноике я не смогу даже в админке вывести эти записи. Но в целом возьму на заметку если понадобится именно удаление безопасное :).

> Ну и по возможностям Питоновские аналоги слабее.

Чувак, открой для себя django.

Common Lisp, Scheme, Haskell (TH), Nemerle, Ocaml (metaocaml)

> Пикль - втопку. Не юникс вэй. Человеко-редактируемая сериализация рулит.

Я тут уже давал ссылки на gnosis-utils и pysyck. =) Это тот же пикль, только в формате XML и YAML, соответственно. А родной пикль использует бинарный формат сугубо ради производительности.

А чего спорить что лучше RoR vs python based? Каждый выбирает что луше для него.

Мне например очень подошел джанго - очень быстро перевел на него пару аппс которые до того были в зопе -причем перевел буквально за один день пока изучал джанго - единстенный минус документации маловато.

Тот же вики - который в райлс и TG рекламируется за 20 мин - в джанго можно склепать за 10мин

счас на джанго пробую что-то тинп oscommerce сделать

Что народ скажет на счет http://www.myghty.org/ ?

Ну дык этож обычная тулза для рендеринга страниц, ака presentation layer.

> Пикль - втопку. Не юникс вэй. Человеко-редактируемая сериализация рулит.

Это правда. Portage если убить в неподходящее время, то он этим пиклем некорректно гадит в некоторые файлы (/var/cache/edb/mtimedb например). Был бы нормальный формат - было бы легко поправить, а так - ipython в руки и ищи-свищи.

Кстати нужно тут тоже попиарить:)

Emacs Rails:

Обзор: http://rubyforge.org/docman/view.php/1484/353/description-ru.html

Сам проект: http://rubyforge.org/projects/emacs-rails/

Качать лучше через SVN.

>Нормальная релизация.

Что конкретно ненормального в TG?

>Гвоздь, вкрученный отверткой, держится хуже, чем шуруп забитый молотком.

И что из этого следует? Что руби на рельсе рулит? ИМХО из этого следует, что у вас нарушено ассоциативное мышление.

>По сравнению с CPAN все одно сосет.

И опять-же, что из этого? Типо если по сравнению с СРАН либ в питоне маловато, то пофик - давайте юзать руби у которого их вообще нет? Если это к тому, что давайте юзать перл - он имеет уроцкий синтаксис и не юзабелен на чём-либо кроме мелких скриптов.

>А это что, считалка? Тогда смешно.

Ты сначала покажи что-либо хоть отдалённо напоминающее твистед или зопу - потом вместе посмеёмся.

>XML?

Ему говорят фтп, он ХМЛ.... Ты сам за бесплатно будешь софт у клиента переписывать? Надо __динамически__ (те без всяких выгрузок) иметь доступ к обьектам в твоём проекте, в нашем случае по фтп. Свои экспорты в ХМЛ можешь пихать плашмя куда додумаешься.

>А то что большая часть приведённого кода есть макровызовы, >которые генерируют необходимые функции для данного вида данных. >Например у нас есть дерево категорий. Создаём таблицу categories: >id, title, parent_id.

Непонял я что ты хочешь... Если маппинг - SQLObject.org (ну или sqlalchemy), если про метапрограммирование - гугль тебе всё расскажет и покажет.

>Ему говорят фтп, он ХМЛ.... Ты сам за бесплатно будешь софт у клиента переписывать? Надо __динамически__ (те без всяких выгрузок) иметь доступ к обьектам в твоём проекте, в нашем случае по фтп. Свои экспорты в ХМЛ можешь пихать плашмя куда додумаешься.

SQLite я уже говорил хранишь sqliteные файлы на ФТП. Вот тебе и динамически.

>Непонял я что ты хочешь... Если маппинг - SQLObject.org (ну или sqlalchemy), если про метапрограммирование - гугль тебе всё расскажет и покажет.

Я хочу маппинг на основе метапрограммирования с такими штуками как acts_as_tree, belongs_to :blah, :has_many :foos, и не только встроенными но и легко добавляемыми типа как acts_as_paranoid. Посмотрел твои мапперы до ActiveRecord как до Китая раком -- весьма всё примитивно, намного ниже уровнем абстракции.

>SQLite я уже говорил хранишь sqliteные файлы на ФТП. Вот тебе и динамически.

Я тебе тоже уже говорил, не прикидывайся шлангом. Надо иметь файл, вполне определённого формата (допустим тот же хмл), который будет доступен динамически. Какой в *опу SQLite? Ты на все тз такие решения предлагаешь?

>Я хочу маппинг на основе метапрограммирования с такими штуками как acts_as_tree, belongs_to :blah, :has_many :foos, и не только встроенными но и легко добавляемыми типа как acts_as_paranoid. Посмотрел твои мапперы до ActiveRecord как до Китая раком -- весьма всё примитивно, намного ниже уровнем абстракции.

Читаешь документацию по диагонали? До Join-ов не дошёл?

Вобщем так, читать ты не умеешь, поэтому для тебя зацетирую доку.

>acts_as_paranoid that makes sure that things aren&#8217;t actually deleted, but instead are marked for deletion. I&#8217;ll talk more about this when I discuss auditing.

Реализация сего дела - всего лишь дополнительное поле, обозначающее был ли удалён обьект. Дополнительная обвязка позволяет находит удалённые обьекты етц.

Те, всё твое мегарасширение сводится к добавлению доп. поля. Хочешь в одну строку всё твоё расширение сведу?

workflow = IntCol() - это для внутренностей, снаружи создать методы для внешнего интерфейса. Всё.

> Те, всё твое мегарасширение сводится к добавлению доп. поля. Хочешь в одну строку всё твоё расширение сведу?

Ладно а теперь давай acts_as_tree, добавишь одно поле, а дальше? Будешь реализовывать методы childred, root, parent, siblings, self_and_siblings. Потом ещё будешь писать методы которые удаляют всех потомков при удалении предка. А я просто напишу acts_as_tree. И там куча таких возможных связей, не надо вручную указывать через какие поля это всё связываеться. Вобщем смотри здесь: http://api.rubyonrails.com/classes/ActiveRecord/Associations/ClassMethods.html

Потом валидации. Проверяем наши данные до внесение в БД Например проверяем на email: validates_format_of :email, :with => /^([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})$/i, :on => :create, :message => "Хреновое Мыло!" http://api.rubyonrails.com/classes/ActiveRecord/Validations/ClassMethods.html

Потом можно в тех ORM создать легко функции before_create, before_update. Потом скорпинг, тоже мегафича короче почитай про актив рекорд, а потом уже говори.

>Я тебе тоже уже говорил, не прикидывайся шлангом. Надо иметь файл, вполне определённого формата (допустим тот же хмл), который будет доступен динамически. Какой в *опу SQLite? Ты на все тз такие решения предлагаешь?

Терь понял. Делаешь такой класс который удовлетворет твоим потребностям и ставишь вместо активрекорда:) И всё ОК. Я думаю что-то такое уже есть.

>Act_as_tree

Я сильно сомневаюсь, что это употребимо. 1) Если у тебя просто дерево (3-4 листа), то на удаление просто добавляется чекер - удаляет детей и всё. Писать 5 строк кода - не вижу проблем. 2) В обще случае графа это не применимо ибо логику зависимостей компьютер за тебя не придумает, всё=равно надо будет руками делать.

Я отчасти понимаю почему тебе это так понравилось, если бы я не видел zope - я бы тоже был в восторге. А так - обьектная база рулит. Для серьёзных (с навороченой логикой, о которой ты говоришь) решений всё-равно и TG и RoR не подойдут - тут что-нибудь типо Plone.org пойдёт.

>Потом валидации.

Formencode в TG, да и сам TG ещё валидаторов добавляет.

>Терь понял. Делаешь такой класс который удовлетворет твоим потребностям и ставишь вместо активрекорда:) И всё ОК. Я думаю что-то такое уже есть.

Вот фиг, __не надо__ делать это через бэкэнд. Модель у тебя уже есть (грубо говоря у тебя и база с миллионом обьектов уже создана), надо новую контроллер-view связку прикрутить просто. У того же turbogears можно вместо cherrypy другой брокер обьектов прикрутить на ту-же модель. В зопе - вообще out-of-box таки фигни (и процесс замечу продолжается).

Насчёт объектной базы не соглаен, объекты все хорошо ложаться на реляционную модель. А вообще конечно зопа будет по умолчанию мощнее(но и громозче и сложнее в изучении и наааамного менее прозрачее) потомучто это сервер приложений,а RoR фрэймвор, вообще разные вещи. Я смотрел на на Plone, он меня вообще не впечатлил, очень сложно сдалть так как хочет заказчик, настройка через задницу вообще не ложиться в классическо представлени о разарбоке ПО. Объектная БД хреново преноситься между версиями, опять же файлы в ней храняться, вмето того чтобы лежать в файловой иерархии, короче я конечно может ещё мал и глуп, но абсолютно не проникся идеями туда заложенными. А вот рельсы как раз обладают многими качествами хорошо спроектированного Unix приложения, что я приемлю намного лучше, чем монстров как Zope.

Haskell уже смотрел, хорошая штука. Если будет возможность, попробую что-то на нем написать. А про Немерль еще не слышал, нужно будет глянуть, что за зверь.

Кстати, насколько я понял, эти языки не имеют какого-то приличного фреймворка для Веб?

>Кстати, насколько я понял, эти языки не имеют какого-то приличного фреймворка для Веб?

Приличные(по качеству) то есть, но у них поддержка и комьюнити маааленькое.

содержательный пост, спасибо.

мне тоже нравится и python и ruby. и php тоже ничего, когда есть отработанная система.

для системы публикации я думаю django замечательно пойдет, когда нужно разраничение прав доступа, и админ интерфейс для управления контенто.

когда же нужна единая система (без разграничения на front/back), или к примеру intranet система, где всё надо делать по требованиям, а не "подпиливать" существующее решение, то здесь Rails хорошо подходит, т.к. позволяет сконцентрироваться именно на задаче, которую надо сделать, а не отвлекаться на борьбу с очередным ограничением, в случае использования какого-либо "коробочного" решения.

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