Портирование на grails

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

А формулировка "пишу с нуля" сама по себе красный сигнал.

>От объема работ руки поотпадают быстрее
да не сказал бы

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

>А формулировка "пишу с нуля" сама по себе красный сигнал.
почему? Модель пишется с нуля по БД, jsp-вьюшки реюзаются, над контроллерами нужно будет подумать.

Спервоначалу надо четко представлять, куда и что ты хочешь расширить.

grails достаточно легко расширяется практически в любую сторону... Взять тот же spring(acegi) security - ставим плагин одной командой и получаем логин/логаут, роли, рестрикшены и даже регистрацию с капчей! А сколько телодвижений нужно для прикручивания в обысном проекте?

У лора прямо сейчас уже реализовано ВСЕ названное. Да, через вон то место, но работает.

Чтобы революция обрела смысл, надо сперва ясно представить, что НОВОГО с этого поимеется. Не возможность поиметь новое, а что-то сверху. И это надо четко представлять в виде "сейчас реализация этой фишки займет три месяца/нереализуема в принципе, после революции мы ее сделаем в три недели + зафиксим без костылей те 8 багов, что всем надоели".

>У лора прямо сейчас уже реализовано ВСЕ названное.
spring security у них только в планах.

>Чтобы революция обрела смысл
революции пока не планируется.
Кстати о планах:
за сегодня-завтра планирую перенести функционал форума (секции-топики-группы-комменты) почти полностью ридонли и частично write (новые посты/комменты), и можно будет начать переносить дизайн/лэйаут. Ну, если кто вдруг захочет помочь, я буду рад заопенсорсить.

>И это надо четко представлять в виде "сейчас реализация этой фишки займет три месяца/нереализуема в принципе, после революции мы ее сделаем в три недели + зафиксим без костылей те 8 багов, что всем надоели".

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

Вопрос "нафига?" все еще в силе. Ну перенесешь, а потом?

Под "Потом?" я понимаю вещи типа мегаинтеграции с вики, подключаемо-отключаемой модерации в стиле /., проставляемых пользователями тэгов, автовыявления баянов в новостях и постах, блогов пользователей (+ вынос на главную интересных постов) и т. д.

А абстрактная архитектурная чистота нафиг никому не упала, это не цель, а средство, и добиваться только ее - это масло ради масла.

>Вопрос "нафига?" все еще в силе.
я уже говорил - в первую очередь для простоты дизайна

>Ну перенесешь, а потом?
сначала нужно перенести и посмотреть что у планах у maxcom'а

>А абстрактная архитектурная чистота нафиг никому не упала, это не цель, а средство, и добиваться только ее - это масло ради масла.

не сказал был. От такого ужаса точно нужно избавляться:
http://github.com/maxcom/lorsource/blob/52486211a1f85105d723c15d70893bbe1726a...

зы а нельзя ли взглянуть на ваши проекты, уважаемый теоретик?

итак, выложил первые наработки:

http://code.google.com/p/lor-grails/

Фу, бомжовский свн => ты лох.

"работающий" сервер можно посмотреть тут:

http://thevery.info:8080/lor_grails/

неадекват детектед

Дизайн мне нравиться, но второго такого view-message.jsp?msgid=3608812, извините, и даром не надо.

дизайна еще нет, а вместо второго будет

/message/show/3608812

> а вместо второго будет /message/show/3608812

Это, безусловно, намного "лучше".

ваши предложения?

сделать-то легко почти любой вариант...

thread/portirovanie-na-grails
thread/russkie-fiziki-vybirayut-slackware#15
thread/ZHZH-veschestva-ya-buhoi

и так далее.

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

А, кстати, а что в планах у maxcom'а?

Это хоть какое-то представление для Ъ дает, что там по ссылке. А то номера безликие вот...

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

хотя в каментах как-то писал, что не прочь на groovy пописать, может вместе на grails переносить будем:
http://www.linux.org.ru/view-message.jsp?msgid=3601701&page=1#3602473

практически перенёс секции-группы-комментарии на новый движок и скин white2:

http://thevery.info:8080/lor_grails/section/show/2
http://thevery.info:8080/lor_grails/group/show/126
http://thevery.info:8080/lor_grails/topic/show/1941562

теперь в планах на ближайшие пару дней доделать ридонли функционал этих страниц и чёрный скин.

переместил на ооочень медленный, но зато постоянно доступный хостинг, так что за скорость не ругать - это всего лишь дохлый eee pc 701

прикрутил вроде чёрный скин, правда пока только с ручным выбором:

http://thevery.info:8080/lor_grails/group/show/126?skin=black

также воткнул все функциональные элементы(правда, пока не работающие, но это легко) на страницу с топиками:

http://thevery.info:8080/lor_grails/group/show/126

Неужели под Java нет качественных готовых фреймворков из категории - налепил базовых классов с шаблонами, налепил их привязок к URL и готово?

На своём PHP-фреймворке я бы аналог ЛОРа с нуля слепил за несколько дней не очень торопливой работы.

На Java те же принципы собираюсь реализовывать, но только после того, как руки до JBForth2 дойдут. А это будет не скоро. Т.к. проект получится чисто Just For Fun. Всё равно деньги сейчас мне только за PHP платят :)

>Неужели под Java нет качественных готовых фреймворков из категории - налепил базовых классов с шаблонами, налепил их привязок к URL и готово?

а grails, по-вашему, что тогда? ;)

>На своём PHP-фреймворке я бы аналог ЛОРа с нуля слепил за несколько дней не очень торопливой работы.

ну так и я вполне неторопливо пишу, просто приходится мапиться на легаси-базу

> Неужели под Java нет качественных готовых фреймворков из категории - налепил базовых классов с шаблонами, налепил их привязок к URL и готово?

Есть, и много. Grails, Trails (да и Tapestry воббще), Lift (хотя это и Scala), Rife, Seam, Naked Objects, чего там еще. Особенно если учесть, что Hibernate без проблем (ну почти) генерит доменные классы по существующей базе, а обобшенные компоненты для доменных классов на том же викете пишутся за пару часов... Вопрос-то не в написании аналога лора, а в улучшении/развитии сайта.

>Вопрос-то не в написании аналога лора, а в улучшении/развитии сайта.

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

>а grails, по-вашему, что тогда? ;)

Не знаю. Я нынешний фронт Java-фреймворков не ковырял пока. Но если
он - то самое, то откуда тогда сложности? :)

>просто приходится мапиться на легаси-базу

Ну да. У меня мапинг делается так:
class airbase_board_post extends base_page_db
{
...
    function main_table_fields()
    {
        return array(
            'id',
            'topic_id',
            'topic_page' => 'page',
            'create_time'   => 'posted',
            'edited',
            'edited_by',
            'owner_id'=> 'poster_id',
            'poster_ip',
            'poster_ua',
            'author_name' => 'poster',
            'answer_to_id' => 'answer_to',
            'post_source' => 'source',
            'post_body' => 'source_html',
            'hide_smilies',
            'have_attach',
            'have_cross',
        );
    }
...
}

Всё. В классе ничего писать больше для ORM не надо.
(Хотя понятно, что логики там ещё дофига).
После этого грузим постинг как:
$post = object_load('forum_post', $id);

группу постингов одного топика:
$posts = objects_array('forum_post', array('topic_id' => $topic_id, 'order' => '-create_time'));

и т.п.

И используем в тех же шаблонах:

{$post->author_name()}: <a href="{$post->url()}">$post->title()</a>...

Соответственно, ни проблем с мапингом на легаси-базы (собственно,
я на это изначально ориентировался, в массе проектов приходилось
старый код менять на новый поэтапно), ни трудностей с описанием :)

В Grails также (не буквально, но по краткости)? Если да, то
прекрасно, м.б. прямо на него и переведу часть своего кода.

Если нет (скажем, не хватает рефлексии для автоматического
расширения классов при описании полей ORM) - то придётся самому
писать :)

Скажу за себя. Лично мне с grails ковыряться не особенно интересно. В lift fun'a гораздо больше :) Ну нет особой разницы, на чем хибернейт со спрингом обвязывать, правда. На trails оно даже быстрее получается, да и тапестри - вещь непредсказуемая.

>Всё. В классе ничего писать больше для ORM не надо.

если б всё так просто было - так в базе, например, текст сообщений/топиков лежит в msbase с тем же id, что и сам топик/сообщение, а это нетривиальный маппинг

>В Grails также (не буквально, но по краткости)?
Grails - штука умная, она ещё и генерить базу умеет, равно как и валидейтить, поэтому чуть более многословна:
http://code.google.com/p/lor-grails/source/browse/trunk/grails-app/domain/Com...

ну и опять же орм берёт на себя, например, вызов comment.author.name, умеет делать eager/lazy, кэширование, пейджинг итд. - и всё это без строчки sql'я.

>Ну нет особой разницы, на чем хибернейт со спрингом обвязывать, правда.

ну, если в возможность написать ORM проще и лучше динамического языка я ещё как-то верю, то в возможность сделать spring проще у лучше самого springsource верю уже с трудом ;)
впрочем, я со скалой/лифтом не работал и ничего конкретного сказать не могу, да и скала - это всё-таки не java.

>если б всё так просто было - так в базе, например, текст сообщений/топиков лежит в msbase с тем же id, что и сам топик/сообщение, а это нетривиальный маппинг

Это если id одинаковые:
function fields() { return array('DB1' => array('table1' => array('fields', list'), 'table2' => array('field', 'list'))); }

Если id разные, а нужен join, то чуть сложнее, нужно join вписывать. Когда-то такой механизм делал и до сих пор в старом коде работает, но со временем отказался - если ID разные, то это разные объекты.

>ну и опять же орм берёт на себя, например, вызов comment.author.name, умеет делать eager/lazy, кэширование, пейджинг итд. - и всё это без строчки sql'я.

Всё перечисленно кроме «eager/lazy» (я не знаю этого термина) у меня есть :)

>ну, если в возможность написать ORM проще и лучше динамического языка я ещё как-то верю

А с производительностью у Grails как? А то по http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=jruby&... общего вывода сделать не получается.

>function fields() { return array('DB1' => array('table1' => array('fields', list'), 'table2' => array('field', 'list'))); }

ужасный код, никакого ООП :(

>я не знаю этого термина

lazy - это "ленивая" загрузка, т.е. при запросе селектятся только ID'шки, а сами данные вытаскиваются только по обращении к ним.

>А с производительностью у Grails как?
весьма неплохо - потери по сравнению с "чистым" спрингом около 20%.

> весьма неплохо - потери по сравнению с "чистым" спрингом около 20%.

Если много раз повторять "сахар", слаще от этого не становится. Потери на реальном приложении больше. Еще на момент добавления в груви MOP об этом писали. Ну и, благодаря тому же MOP, потери по памяти (той, что не чистится, или чистится очень редко) вполне существенны.

Спринг нужен далеко не всегда. Если речь только о DI, то Guice или Hivemind лучше спринга с точки зрения производительности (хотя бы). Скала, кстати, отлично интегрируется с явой.

>Потери на реальном приложении больше.
пруфлинк?

>Если речь только о DI, то Guice или Hivemind лучше спринга с точки зрения производительности (хотя бы).

но есть-то ещё MVC, WebFlow, Security и много чего другого полезного.

>Скала, кстати, отлично интегрируется с явой.

было бы странно, если бы это было не так. Однако я говорил о том, что синтаксически и по смыслу groovy значительно ближе к java.

> Grails - штука умная, она ещё и генерить базу умеет, равно как и валидейтить

Это не Grails умеет, это Hibernate умеет :)

NDA? :)

> но есть-то ещё MVC, WebFlow, Security и много чего другого полезного.

Ага, и в симе есть все то же самое. Только без спринговских прослоек, и авторизация куда как более навороченная.

> Однако я говорил о том, что синтаксически и по смыслу groovy значительно ближе к java.

И что?

>Это не Grails умеет, это Hibernate умеет :)
к счастью, при использовании Grails знание Hibernate практически не нужно ;)

>NDA? :)

э, так не годится...
ну вы хоть конкретные цифры назовите...

import org.apache.commons.lang.StringUtils  

String.metaClass.capitalize = {
   StringUtils.capitalize(delegate)
}

String.metaClass.normalize = {
   delegate.split("_").collect { word ->  
      word.toLowerCase().capitalize()  
   }.join("")
}

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

>ужасный код, никакого ООП :(

Это _метод_ внутри класса :) А как ты предлагаешь описывать поля БД? В параллельном XML с описанием струкруры? Легко (и прозрачно для имеющегося кода). Всего переопределить метод fields(). Но быстродействие упадёт в разы.

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

Что такое lazy я знаю :) Но не понимаю, о чём речь. Приведи примеры. Или имеется в виду, что при запросе объектов дёргаются только ID, а заполнение полей объекто происходит по запросу? Это же будут _чудовищные_ тормоза.

Чтобы выдернуть 100 объектов мне нужен один запрос к БД (естественно, скрытый за ширмой ORM, сам я просто вызову метод). А если дёрну только ID, то всё равно нужен тот же самый запрос, плюс 100 (или даже 100*N, где N - число запрашиваемых свойств объекта) запросов со временем, по мере использования. Я правильно понимаю? :)

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

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

seam - это всё-таки немного другая штука, со своими плюсами и минусами...

>И что?

как минимум то, что найти scala-девелоперов на порядок сложнее, чем java/groovy-девелоперов

впрочем, может хватит уже тут оффтопика, можно и тут пообсуждать:

http://www.linux.org.ru/view-message.jsp?msgid=3614170

> впрочем, может хватит уже тут оффтопика

As you wish, my lord.