PHP vs RoR vs Django

> Я не говорил что код формы занимает больше,
он практически такой же. Я говорю про реализацию работы этой формы.
Потому что если ты говоришь про реализацию, то ты не знаешь сколько
она у меня заняла соответственно "Но у меня-то кода столько же!"
безпочвенно.

Ах вот ты о чём... Ну тогда извини, ты проиграл всухую. Я код обработки
формы вообще не писал, он готовый используется из нелюбимого тобой pear ;)
Это опять на тему "что нового есть в RoR" ;)

> Я код обработки формы вообще не писал, он готовый используется из нелюбимого тобой pear ;) Это опять на тему "что нового есть в RoR" ;)

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

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

> 1. Но это тоже дополнительный код

Тут только что выяснилось, что товарищ, пишущий на RoR сам пишет
какую-то обработку форм. Я её не пишу сам. Всё есть в pear. Так что тут
надо дальше расследовать ;)

> 2. То определение которое заложено в QuickForm будет дублироваться в ОРМ.

Здесь опять непонятки. В моём приведённом коде ORM интегрирован с
библиотекой форм. Описание одно и в одном месте. Передаётся всем
компонентам, участвующим в создании админ-интерфейса.

> 3. Все ОРМ, включая то что была приведена не дотягивают до ActiveRecord по функциональности и динамичности

И здесь надо разбираться. Вы уже несколько раз строили свои выводы либо
на ошибочных данных, либо на незнании чего-то. Доверия уже нет ;)

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

Не увиливаю. Разбил твой пост на две части. Темы слишком разные. Сейчас
отобедаю и отвечу ;) Но ты тоже не увиливай! Дай внятный ответ на первую часть.

>Ах вот ты о чём... Ну тогда извини, ты проиграл всухую. Я код бработки формы вообще не писал, он готовый используется из нелюбимого тобой pear ;)

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

Теперь насчет рельс. Да, я написал эту обработку сам. Тебе не пришлось писать. Здорово. Тем кто использует Джанго еще лучше, потому что у них админка вообще идет с коробки. Это сильная сторона пииира и Джанго.

> Не увиливаю. Разбил твой пост на две части. Темы слишком разные. Сейчас отобедаю и отвечу ;) Но ты тоже не увиливай! Дай внятный ответ на первую часть.

Жду ответа на свою вторую часть :).

> Но не на пхп :))) Просили пример что-нибудь масштаба вики не на пхп -- получите.

А я против перла ничего не имею. :)

> Это код, аналогичный представленному для RoR. Сопоставимый по размерам и по функциональности. IMHO лучше читаемый и прри этом несущий большую смысловую нагрузку.

Неа. Это у Криса такой код. В простейшем варинате кода не надо ВООБЩЕ создаём табличку (SQL) -> запускаем скрипт - админка готова.

> Что-что? Я не ослышался? Вы тот SQL один раз собрались использовать?

А для этого в Rails есть мегаинструмент котроля версий БД migrations . Т.е. уровень управления струтуры таблиц мы отадём другому инструменту. Очень чёткое решение в стиле unix-way, а не каша как в случае с QuickForm и PHP.

>Но во-первых, никто не заставляет жёстко определять размер строк/колонок.

Строки с столбцы только пример. Вообще все данные такие как тип поля формы и.т.д. Относящиеся к View не должны быть в модели. Они должны быть в контроллере и view. А в QuickForm опять же жуткая каша.

Прикольно. Почитал обзор Django.

Очень не понравились ограничения шаблонов. "В Django язык шаблона вообще не связан с Питоном, а шаблонная логика намеренно очень ограничена. Например в операторе {% if %} можно проверить только логическую истинность объекта, а произвольное условие типа “равна ли длина списка пяти” — не допускается. "

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

Идея с тем, что на каждый URL вешается свой обработчик - в своей CMS на PHP использую эту систему уже пару лет :D Хэндлеры, плагины, экшны - всё вешается на абсолютные и относительные URL...

> а как же newlisp тут хвалил.

Common Lisp правда:

Императивно:

(loop for i in '(1 2 3 4 5) for j = (* i i) when (> j 10) collect j )

Функционально:

(remove-if-not #'(lambda (x) (> x 10)) (mapcar #'(lambda (x) (* x x)) '(1 2 3 4 5)))

вот на лиспе понятное дело:)))Тут еще давай те рефал приплетем - там списки двухсторонние xml поразбирать самое то:))))

> До сих пор веришь, что язык становится лучше благодаря синтаксису? :)

Языки становяться лучше благодаря сематике...

> Здесь опять непонятки. В моём приведённом коде ORM интегрирован с библиотекой форм. Описание одно и в одном месте. Передаётся всем компонентам, участвующим в создании админ-интерфейса.

DB_Table - ORM? ну-ну. Где там возможность задания связей один-ко-многим, многие-ко-многим, Деревья? А другие фишки AR почитайте введение - очень интерестно? Еслибы он интегрировался с нормальной ORM кой то я бы ещё понял, но DB_Table вообще посути не ORM и не где про это не написано...

> "В Django язык шаблона вообще не связан с Питоном, а шаблонная логика намеренно очень ограничена. Например в операторе {% if %} можно проверить только логическую истинность объекта, а произвольное условие типа “равна ли длина списка пяти” — не допускается.

Дауж хреновенько. ERb определённо лучше

Кстати, спецы по Django есть? Хочу сравнить возможности своих обрабочиков URL и из Django.

У меня отдельный пакет может быть "плагином". Плагин кидается в специальную папку и в файле main.uri прописывается список URL, на которые он вешается.

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

Скажем, если я систему тикетов вешаю в /tickets/, то по
hts_data_prehandler("!^({$GLOBALS['cms']['plugin_parent_uri']})\w+/?$!" ;, array(
'body' => 'plugins_tickets_main_body',
'title' => ec('Заказ'),
));

повешу свой обработчик на выдачу контента и заголовка (в рамках дефолтового шаблона) на любые /tickets/xxxx/

Дополняю своими возможностями готовый форум, скажем, punbb. И ставлю плагин на /forum/.

hts_data_prehandler("!^(http://[^/]+{$GLOBALS['cms']['plugin_base_path']})t opic/\d+/(\d+)(,(\d+))?/?$!", array(
'title' => 'plugins_forum_unb_thread_title',
'nav_name' => 'plugins_forum_unb_thread_title',
'parent' => 'plugins_forum_unb_thread_parent',
));

В результате для объекта с URI /forum/topic/445/23445,7/ будут возвращаться соответствующие данные.

Есть ли такая фишка в Django, или все пути там должны быть чётко прописаны от корня сайта?

Как осуществляется индивидуальная подгрузка модулей для заданных хостов, путей?

Скажем, если какие-то модули нужны мне только для /forum/ и не нужны для /forum/15/new/ - можно мне их не грузить при обращении по второй ссылке?

> Ruby:
return string unless string.empty?

Я же говорил - сильно влияют личные пристрастия. Я подобную форму
терпеть не мог в perl. Сколько мусора, сколько вариантов записи
одной мысли... Можно написать:

if (x) y;
x if y;
x unless !y;
unless !y x;

Бррр. Свалка. Синтаксис избыточен.

> test = case (test)
when 1: 'odi'
when 2: 'dva'
else 'hz'
end

Согласен, лучше, чем switch. А так тоже неплохо:
test = (test == 1 ? 'odi': (test == 2 ? 'dva': 'hz'));
А lisp в данном случае всё равно уделывает твой ruby и по простоте и
по изящности... Нет, не убедил. Ради case я бы не стал менять
платформу разработки.

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

1. Это ФИЧА. И если её как следует вкурить, начинаешь по ней по-настоящему тащиться.

2. Про {% if %} любят спрашивать новички в джанговской рассылке. Ответ: сложным логическим выражениям в шаблонах делать нечего, ибо место им в коде, и только в коде. Хотя особые извращенцы легко могут написать свой тег {% my_cool_if %}, который будет всё это уметь (работы на 15-20 строчек кода). Что характерно, до сих пор никто не написал.

3. А если вы не постигаете этого дзена и непоправимо испорчены быдлопрепроцессорами типа PHP, то вместо джанговских шаблонов можно использовать любые другие. Хоть cheetah, хоть clearsilver какой-нибудь, хоть вообще зоповские шаблоны.

> Сейчас уже не могу точно сказать, из-за чего, просто не помню. Я отказался от этого. И написал свой набор пхп-библиотек.

Дык я и говорю: ниасилил ;)

> Тем кто использует Джанго еще лучше, потому что у них админка вообще идет с коробки.

И у меня из коробки. Я её не пишу.

> Кстати, спецы по Django есть? Хочу сравнить возможности своих обрабочиков URL и из Django.

В Django примерно так всё и делается. Вы пишете файл ('urlconf') в джанговской терминологии, в котором определённым регэкспам сопоставляется либо функция-обработчик, либо другой urlconf. В дочернем uflconf'е все пути (точнее, регэкспы), естественно, указываются относительно родительского uflconf'а. Это обычно и используется для подключения плагинов.

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

> Ответ: сложным логическим выражениям в шаблонах делать нечего, ибо место им в коде, и только в коде.

Не факт. На самом деле есть два разных подхода или точки зрения на
шаблоны:

1) Шаблон прост, как дерево, и его должен понять самый тупой
верстальщик, не задавая вопросов.
2) Шаблон - это представление (view). На входе сырые упорядоченные
данные, на выходе - всё, что угодно, что только из этих данных можно сварить.

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

> Неа. Это у Криса такой код. В простейшем варинате кода не надо ВООБЩЕ создаём табличку (SQL) -> запускаем скрипт - админка готова.

Спешу огорчить. В моём коде не надо даже табличку руками создавать.
Она создаётся из определения класса. Чтобы заработала админка нужно
прописать только dsn для коннекта с базой и имя таблицы...

> А для этого в Rails есть мегаинструмент котроля версий БД migrations .
> Т.е. уровень управления струтуры таблиц мы отадём другому инструменту.

Значит у меня ещё одноой лишней сущностью меньше.

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

Ок, буду смотреть...

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

Кстати, если есть заинтересованные - приглашаю на http://balancer.ru/forum/punbb/viewforum.php?id=60

Система давно переросла возможности одного разработчика... Так что 90% последнего времени занимаюсь не вычисткой её ядра (что актуально, на код 3..4-летней давности местами без слёз смотреть нельзя) и базовых модулей и плагинов, а написанием оных для тех или иных проектов.

Не мешало бы коммьюнити собрать :) SVN-хостинг есть, с Trac'ом. Jabber-конференция есть. Форум, ссылка выше (хотя там толком ничего нет, в основном планы полуторалетней и т.п. давности, частью уже реализованные, частью пересмотренные).

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

> но DB_Table вообще посути не ORM и не где про это не написано...

В данном примере выполняет его роль. SQL в моём коде нет. А обозвать
его QueryBuilder рука не поднимается. Инструмент специфичный, не спорю.
Но делj-то не в названиях. Я отвечал на выпад про дублирования
определения в форме и в ORM. Возможно нет там ORM, но дублирования там
точно нет ;)

> Не факт. На самом деле есть два разных подхода или точки зрения на шаблоны

Верно. Второй вариант - это пресловутый макаронообразный стиль PHP. А джанговские шаблоны именно что просты, как дерево.

Идеология Django такова: представление (view в терминологии MVC) разделено на две слабосвязанные части: шаблон и код. Шаблон отдаётся дизайнерам-верстальщикам, код отдаётся программистам. Хотя никто, конечно, не запрещает дизайнеру править код, а программисту - шаблон, если есть такая необходимость.

Ещё. Благодаря этому разделению стала вожможна такая мощная фишка, как универсальные представления (generic views). То есть, в Django есть стандартный код для всяких рутинных операций, типа создания-просмотра-редактирования объектов, постраничного вывода списка объектов и т. д. От вас требуется только написать к нему свой простой шаблон. В реальной жизни процентов 30 всех страниц сайта чудесно укладываются в эти generic views.

>> А для этого в Rails есть мегаинструмент котроля версий БД migrations Т.е. уровень управления струтуры таблиц мы отадём другому инструменту.

> Значит у меня ещё одноой лишней сущностью меньше.

Чудной вы, право. Rails за вас изменяет структуру таблиц БД, а вам надо голыми руками делать ALTER TABLE blablablablabla. Вы считаете это своим преимуществом? А я считаю это безоговорочным сливом.

>разделено на две слабосвязанные части: шаблон и код.

Тем не менее - код внутри шаблона есть и у них. Это и if'ы, и генерация циклических данных. В результате, код всё же есть. Но - кастрированный.

>В реальной жизни процентов 30 всех страниц сайта чудесно укладываются в эти generic views.

Так мало? :)

>Rails за вас изменяет структуру таблиц БД, а вам надо голыми руками делать ALTER TABLE

А ты знаешь, я юзеру, от которого с БД работает сайт, право на ALTER TABLE не даю.

> Верно. Второй вариант - это пресловутый макаронообразный стиль PHP.

Ой ли? А xslt куда отнесём? А в php оба варианта представлены, кстати.

> Чудной вы, право. Rails за вас изменяет структуру таблиц БД, а вам надо голыми руками делать ALTER TABLE

Хм... А я ведь и в третий раз могу повторить, что структуру таблицы
я описываю в классе, и никогда её не создаю и не изменяю руками.
Похоже поборники RoR вошли от этого факта в перманентный ступор ;)
Не использую я ни ваш детский phpmyadmin, ни "мегаинструмент котроля
версий БД".

> Тем не менее - код внутри шаблона есть и у них. Это и if'ы, и генерация циклических данных.

Нет, ну можно, конечно, пойти до конца и вообще оставить в шаблонах только простые подстановки. Но разработчики Django, всё-таки, не фашисты, а мудрые прагматими. Практика показала, что конструкции if и foreach - это очень удачный компромисс. Меньше было бы глупо, а больше - вредно.

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

Ну так и мы вас в третий раз спросим: когда вы свой класс меняете, таблицы у вас сами собой изменяются под него? Или вы таки делаете руками ALTER TABLE?

> А ты знаешь, я юзеру, от которого с БД работает сайт, право на ALTER TABLE не даю.

А что, кто-то даёт? Не понимаю вашего справедливого гнева. Сервер работает с БД от одного юзера, а migration делает ALTER TABLE от другого. Было бы странно, если бы это было не так.

> Бррр. Свалка. Синтаксис избыточен.

Дык я и говорю: ниасилил ;) (c) ты сам

> Согласен, лучше, чем switch. А так тоже неплохо: 
> test = (test == 1 ? 'odi': (test == 2 ? 'dva': 'hz'));

Согласен, лучше, чем switch.

Идем дальше.

Изящная работа по созданию массивов, строк, регулярных выражений.
1) Массив:
PHP:
$arr = range(1,100);
$arr = array(1,2,4,5);
$arr = array('apple', 'orange', 'banan');

Ruby:
arr = [1..10]
arr = [1,2,3,4]
arr = %q( apple orange banan )

Тут пока различие некритично.

2) Строки:
PHP:
$str = "Test bla bla {$var} bla"; 
Ruby:
str = "Test bla bla #{construction} bla"

А вот здесь уже видно разницу. В ПХП можно вставить только переменную:
объект, массив, скаляр.
В Руби можно вызвать функцию или метод, по сути поставить любую 
конструкцию.

Heredoc
PHP
$str = <<<__TEXT__
Бла, бла, константы не понимать!
Могу использовать только переменные {$var}.
Отступ тоже не понимать.
__TEXT__;

Ruby
  str = <<-__TEXT__
  Понимаю всевозможные конструкции внутри #{2 + 2}.
  Понятно, что и константы могу выводить #{CONST}
  Да, и как насчет нормального отсупа?
  __TEXT__

3) Удобная запись регулярных выражений:
PHP
$regexp = '/hell \/\' with symbol';

Ruby
regexp = %r(hell /' ne tut)
regexp = %r-hell /' ne tut-

Эти вкусности дают возможность лехко делать DSL - что наглядно продемонстрировано
в Rake. О, раз тут так вспоминалось о готовом на Руби, дайте мне пример
Rake-а на пхп? :)))

Кто не в теме - читаем классика - http://www.martinfowler.com/articles/rake.html .

> А xslt куда отнесём?

Отнесём его в приёмное отделение биореактора, и там положим.

А вместо этого мертворождённого уродца асиль-ка лучше CDuce, чукотка.

> %q( apple orange banan )

Да уж, изящнее некуда. Поэтому мы и говорим, что у Руби мусорный синтаксис. "apple orange banan".split() - так говорим мы, брат.

> В ПХП можно вставить только переменную: объект, массив, скаляр.

Гыгыгы! А если посмотреть на вопрос с другой стороны? blablabla <?php foo($bar) ?> blablabla again. Хотя оба метода отстой. Нехрен вставлять свои штуки куда попало.

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

А, да, чуть не забыл. Rake сасёт, SCons рулит.

>Но разработчики Django, всё-таки, не фашисты, а мудрые прагматими. Практика показала, что конструкции if и foreach - это очень удачный компромисс.

Как на Django решается такой вопрос.

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

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

Как передавать в него данные из вызывающего шаблона? Есть ли аналог assign из Smarty?

Т.е. я могу закрутить цикл:
{section loop=$data name=i}
{assign var=my_var value=data[i]}
{include announce}
{/section}

А announce уже использует назначенную переменную для вывода:
<a href="{my_var.uri}">{my_var.title}</a>

Есть аналог в Django? Или придётся соблюдать для всех шаблонов высокого уровня общиие соглашения на имена, а цикл упрятывать в субшаблон?

> Да уж, изящнее некуда. Поэтому мы и говорим, что у Руби мусорный синтаксис. "apple orange banan".split() - так говорим мы, брат.

Мы, это кто, брат? Питоновцы?

> А если посмотреть на вопрос с другой стороны? blablabla <?php foo($bar) ?> blablabla again.

Видно вы или не в теме или не знаете, что такой синтаксис не позволяет присвоить значение строке без костыльного варианта сбора через ob_start ...

> А heredoc ваще давить, а тех, кто пользуется - кастрировать в молодости.

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

> SCons рулит.

Таки, да, месье питонист. Извините, но я обсуждал не Руби и Питон, а Питон с ПХП. К сожалению мои знания языка Питон не дают мне возможности вступить с вами в полноценные дебаты.

> Ну так и мы вас в третий раз спросим: когда вы свой класс меняете, таблицы у вас сами собой изменяются под него?

Ладно, в четвёртый раз отвечаю: да, сами меняются, согласно описанию в классе. Это действительно так сложно понять? ;) Не ожидал.

Угу, для ppp bsd_compression и т.д. и будут страницы на скорости ~9-12kb грузиться.

> В данном примере выполняет его роль. SQL в моём коде нет.

Ну и где твоя модель будет легко применяться только там где к ней нужно привязать форму, а в остальных местах придёться тупой DB_Table юзать - что совсем некошерно. КОнечно если вся логика состоит из редактирования сущностей то так просто, но так не бывает. Вот тут негобкость то где.

> Как на Django решается такой вопрос.

Вам уже пора на http://www.djangoproject.com/documentation/templates/, друк! :) Всё там есть.

А мне не нравятся синтаксческие конструкции на Ruby, все unless и т.д. это не удобно и не читабельно, и не вижу чем короче чем if (!empty($string)) return $string;

ЗЫ Кто бы говорил про слив, пока слышно только то что на PHP пишут так, а на Ryby вот так, при чём никаких аргументов что писать как на Ryby удобнее.

А если поля класса "размазаны" по нескольким таблицам?

Ну и чем это хуже? Тем что только Вы считаете что на Ryby это лучше? Конкретнее.

PHP: if (!empty($string)) return $string;

Ruby: return string unless string.empty?

И как будет выглядеть этот код test = case (test) when 1: 'odi' when 2: 'dva' else 'hz' end

когда мне надобудет после when 1 выполнить затем when 2 ?

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

Я там был. Ответа на свой вопрос не видел. Кстати, если это вся документация - то она довльно скудная, на Smarty побогаче будет.

А, вообще, конструкции вида {% ifequal user.id comment.user_id %} ... {% endifequal %} в XXI веке - это маразм. Я предпочту писать {if $user.id == $comment.user_id} .. {/if}

Это, как минимум, нагляднее и компактнее :D

> Теперь насчет рельс. Да, я написал эту обработку сам. Тебе не пришлось писать. Здорово. Тем кто использует Джанго еще лучше, потому что у них админка вообще идет с коробки. Это сильная сторона пииира и Джанго.

Мы уже выяснили что тут RoR и Django велосипедописатели, всё пишут только сами, по 10 раз. А про "автоматическую админку" столько сказок слышно, особенно если учесть что до админки это никак не дотягивает.

Кстати, RoR уже научили локализации? А межязыковому взаимодействию?

test = case(test)
       when 1,2: 'odin i dva'
       when 3,4: 'tri i 4etyre'
       when 100..200: 'mejdu sto i dvesti'
       else 'ne znayu'

Так годится? =))))

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

А я ведь еще не добрался до ООП. Ведь на ООП в пхп можно такую пляску 
по мозолям сделать... Ключевые слова: неймспейсы, автоматические 
генераторы сеттеров, геттеров. Метапрограммирование. АОП. Миксины :)))

> А, вообще, конструкции вида {% ifequal user.id comment.user_id %} ... {% endifequal %} в XXI веке - это маразм. Я предпочту писать {if $user.id == $comment.user_id} .. {/if}

Пишите свой тег, сказали же вам. Будет вам и ==, и <>. Или продолжайте пользоваться ПХП, раз вам нравится ПХПшный стиль.

> А про "автоматическую админку" столько сказок слышно, особенно если учесть что до админки это никак не дотягивает...

...сказал эксперт по Django gloomdemon. Бросте уже позориться. Если есть реальные претензии - марш на django-developers@googlegroups.com, если только язычком баля-баля - фсат к детишкам.