Grails для разработчиков PHP

>>А Message и Session бины не работают? Т.е мой Session бин ну никак в базу не залезет.

>JSP тоже может в базу лазить, но тогда это ни чем от PHP отличаться не будет.

Для сержанов повторяю ещё раз, из Session и Message бинов можно и нужно лазить в базу, раз уж вы взялись бины использовать.

Короче, вот тебе ссылка
http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Transaction3.html
черпай вдохновение.

>Для сержанов повторяю ещё раз, из Session и Message бинов можно и нужно лазить в базу, раз уж вы взялись бины использовать.

Ты что, честно считаешь, что транзакции могут быть только с БД?

>>Для сержанов повторяю ещё раз, из Session и Message бинов можно и нужно лазить в базу, раз уж вы взялись бины использовать.

>Ты что, честно считаешь, что транзакции могут быть только с БД?

С чего ты это взял?

Что-то поздно начал. Вообще-то 2007 год был годом, когда официально забили последний гвоздь в ROR и весь хайп, поднятый вокруг Ruby. 2008 год это год Groovy и Scala. Кто победит неизвестно. Предпочтения все отдают Scala

УУуууу. вендотролли в соседнем топике и то вменяемее...

P.S. Это ви таки мне будете гассказывать? http://java.sun.com/products/ejb/docs.html

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

>>Никаких ЖЕСТКИХ СТАНДАРТОВ именования классов ни в EJB ни в JEE нет.

>Это ви таки мне будете гассказывать? http://java.sun.com/products/ejb/docs.html

Нетолько буду, но и букву Р научу произносить ;-)
Пример "ЖЕСТКИХ СТАНДАРТОВ именования классов" в студию.

>>итого Spring - это _НЕ_ EJB.

>Да, я вроде так и сказал ;)

Нет, ты писал что Spring - это EJB.

строго не отражать, а строго данноориентированную.

мы немного говорим о разном. все что ты сказал здесь также можно сделать хешем. остальное просто реклама.

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

так вот, если вы отражаете строго данноориентированную структуру БД, то есть иначе говоря только данные на объекты, которые сущность более сложная, которой можно еще добавить функциональность для работы с этими данными. но!

по факту этого делать не нужно, хотя бы потому что в статических объектах и не добавить ничего, а если например воспользоваться динамическими, то куда потом обратно отразить в БД появившиеся методы?

а по примеру того же ActiveRecord совсем идея не ясна - тут данные, которые должны быть просто свойствами объекта (что кстати если при этом не будет методов то и будет аналогом хеша) обернуты в одноименные методы. для чего? чтобы терять время на вызове функции? чтобы усложнять сущности и напрягать сборщика мусора?

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

эээ. спорно, что использование хеша будет усложнением.

про рамки проекта ясно, скорее всего что и не надо, хотя многоязычность проекта - не редкость.

"Всё равно в БД формат необъектный" - вот ключевая фраза и я про это. тогда нафига?

"В-третьих, что у нас из языков соответствующего профиля (Web и работа с БД) - необъектное?"

этого много, даже можно указать 4ый ПХП (хоть и заявлен ооп) и вот мой любимый Луа к примеру (хотя там тоже можно извратиться как я уже писал в предыдущем посте), Перл, Си, да полно их, даже на самом деле можно работать и в Руби и не пользоваться везде именно объектностью, имхо и там хеш менее прожорлив, хотя допускаю что он эмулирован в ооп.

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

Да потому что на практике с объектами работать удобнее и проще, чем с хешем. Ну вот скажи на пальцах - чем хэш будет лучше? Тем, что потребует лишней писанины и не позволит вводить модификаторы данных в классах-наследниках? :)

Вот приведённый мною пример. Есть такая сущность, как "Новостийная запись". Реализован как класс на 157 строк. Есть сущность "Наша новостийная запись", которая фактически является новостийной, но за исключением того, что источник новости - с определённым (нашим) ID. У неё - другой формат ссылки. Немного отличается шаблон. В остальном - всё совпадает. Класс, описывающий эту сущность состоит из пяти строк, важные из которых - две (остальное - форматирование и т.п.). С хешем тебе придётся делать полную копию исходной сущности или вводить костыли в виде лишних условий.

Дальше. Данная сущность может редактироваться. Класс-редактор является только расширением базового класса, в который добавляются права, проверки на изменения, другой шаблон (редактируемый)... Ты это всё тоже будешь в базовый свой хэш запихивать? И вся эта хрень у тебя будет каждый раз грузиться? И тут ещё кто-то про ресурсоёмкость говорит? :D

...

>этого много, даже можно указать 4ый ПХП (хоть и заявлен ооп)

Вот у меня система упомянутый выше вид, как раз на PHP4 и приобрела :D Вполне там нормальный уже ООП был для таких целей. На PHP5 я буквально месяца два-три назад только окончательно переехал.

В интернетах поищите. На обычних хосингах php и перл входят апример в базовый тарифный план.

> Пример "ЖЕСТКИХ СТАНДАРТОВ именования классов" в студию.

Да запросто! С JMX работал? Тогда удивись, что интерфейс ОБЯЗАН заканчиваться на суффикс MBean. :))

http://java.sun.com/javase/6/docs/technotes/guides/jmx/tutorial/essential.htm...

вы про какие сущности в данном случае говорите? про модель?

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

вы скорее всего говорите про View.

>>>>>>EJB - Enterprise JavaBeans - компонентная архитектура для построения приложений. Включает в себя жёсткие стандарты именования классов, что позволяет им взаимодействовать друг с другом.
>>>>>Никаких ЖЕСТКИХ СТАНДАРТОВ именования классов ни в EJB ни в JEE нет.
>>>>Это ви таки мне будете гассказывать?
>>>Нетолько буду, но и букву Р научу произносить ;-)
>>Пример "ЖЕСТКИХ СТАНДАРТОВ именования классов" в студию.

>Да запросто! С JMX работал? Тогда удивись, что интерфейс ОБЯЗАН заканчиваться на суффикс MBean

Убедись сначала, что ты понял о чем идет спор ;-)
Речь идет о EJB, и JEE(см верх сообщения). JMX - это javaSE.

PS Конкурс на жесткие стандарты именования в EJB да в прочем и JEE спеках отсается открытым ;-)

>для чего? чтобы терять время на вызове функции?

Если ты думаешь что поиск в хеше при каждом обращении к атрибуту супербыстврая операция по сравнению с обращению к свойству объекта....

>а объект - это еще и методы для работы с ними. можно в приницпе и в хеш засунуть методы, но это уже извращение.

Вот именно. Если у меня есть юзер у которого есть имя и фамилия а мне нужны инициалы и полное имя - у меня есть объект где появятся эти методы которые из своих данных их извлекут. Что ты сделаешь с хешом? Далее - в статических языках все будет отвалидировано компилятором и маппером - объект не соответствующий заявленной структуре просто незамапиться во время буда аппликейшена и маппер скажет все что он думает об этом программисте. А с хешом как?

>вы скорее всего говорите про View.

Не смотря, что говоря "модель" я не имел в виду категории MVC, тем не менее, в моём случае имеется в виду отображение Model на Controller.

В общем, так и запишем, вопрос роста реюзабельности кода Вами не рассматривался :D

>Если ты думаешь что поиск в хеше при каждом обращении к атрибуту супербыстврая операция по сравнению с обращению к свойству объекта....
не супер, но быстрее вызова функции как минимум на одну операцию.
>...у меня есть объект где появятся эти методы которые из своих данных их извлекут.
вот откуда он взялся этот самый объект?
>Что ты сделаешь с хешом?
и у меня "...появятся эти методы..."
просто они не будут привязаны к конкретным данным не в ООП стиле просто и всего
>Далее - в статических языках все будет отвалидировано компилятором и маппером - объект не соответствующий заявленной структуре просто незамапиться во время буда аппликейшена и маппер скажет все что он думает об этом программисте. А с хешом как?
точно также
вобщем имхо ты не очень вчитываешься в вопросы (без наезда, я действительно хотел услышать дельные аргументы)
могу только как то предположить необходимость наследования, но мне не дали нормальных примеров к сожалению
коротко я предполагаю что все что делает ORM - это аналог View из реляционных баз, которое просто оборачивает (зачем так и не понял) строки в объекты, и соответственно данные в функции. и если это так то хеш в качестве рабочей струкутуры локальной работы с View логичнее и проще

вернее конечно не Model это аналог View БД
и не понял зачем я про обертку в функции, а не обертку строк

>не супер, но быстрее вызова функции как минимум на одну операцию.

В каком языке? как реализован хеш? Фантастика. Чтобы хеш был быстрее функции как минимум фызов должен быть реализован через этот же хеш и не оптимизирован компилятором/vm или поддержка твоего хеша должна быть компилятором. Если обращение по стрингу в хеш быстрее вызова - это какой-то торсионный хеш наряду с гномами которые обрабатывают вызов.

>вот откуда он взялся этот самый объект?

НАписан/сгенерирован/иструменчен.

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

Если ты хочешь доказать что больших и сложных приложений не существует и достаточно портабельного ассемблера - так не стоит. "просто и всего" можно и на ассеблере делать. Все эти технологии и фреймворки созданы для упрощения и ускорения работы, а не по космическим причинам. А сколькугодно велосипедно можно сделать все. зачем тебе вообще функции? Сделай хеш который будет хранить точки входа и делай джамп по значениям из хеша.

>точно также

Поподробнее. Как это точно так же? Статический обект должен однозначно соответствовать структуре маппинга. Хеш соотествует любой структуре.

> Нет. Помотрел Django Database API на предмет тех же костылей, что обнаружил в ActiveRecord. Если ORM в ROR это позапрошлый век, то ORM в Django всего лишь прошлый.

юзайте sqlalchemy -- будет вам щастье.

> Глядя на реализацию рубиевских вебсервисов хочется рыдать настолько она бедная для динамического языка.

Просто вебсервисы оставь .нету и яве, используйте xml-rpc и json/rest/http ;)

Хмм, может быть загрузить какого-нить студента на курсовик реализацией yet another WS-library for ruby/python? Жаль, что ничего путного боюсь не напишут :)

Умник, читаем JSR.

http://jcp.org/en/jsr/detail?id=077 http://jcp.org/en/jsr/detail?id=151

А потом сливаем в лужу.

Это только в 5-й версии они перенесли это в SE. Сан сейчас вообще активно часть апи перетаскивает из EE в SE.

> Авторы спринга активно рекомендуют не использовать EJB ни где

Там, где не надо, вообще-то.

Этим гвоздем, наверное, goldspike был?

>Просто вебсервисы оставь .нету и яве, используйте xml-rpc и json/rest/http ;)

Мне не отдвать а вызывать донтетовские сервисы:)