Нужен фреймворк (или полу-готовая система ) со следующими характеристиками:
1) Давал бы быстрый старт для мини-социальной сети: личное пространство для пользователей, где можно выкладывать данные о себе, личные фото и т.п. и общее пространство (группы, форум).
2) CRUD для создания и хранения информации.
3) Быстрый цикл разработки, без тяжелого тестирования.
4) Простейная CMS для управления сайтом.

Склоняюсь к Liferay (+ Grails для разработки портлетов). Смущает тяжесть портала и, по слухам, множество багов. Grails для разработки портлетов - тоже смущает. Плюс сомнения в п.3.

Есть также мысли просто стартовать с Grails или посмотреть на готовые open source CMS.

Слышал также, что Django превосходит Grails почти по всем параметрам (скорость и качество разработки).

Кто что может посоветовать?

Это сообщение отредактировал(а) Andrey1 - 25.3.2011, 23:53

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

Grails мне очень нравится. Сейчас я бы не брался за LifeRay а сделал бы все на Grails.

Насчет Django, я его слегка поковырял, но он не пошел... С Grails со знанием Spring было все легко и просто. Прочитал "Grails гибкость groovy и надежность Java" не делая примеров - просто как какой-то роман, потом сел программировать и почти не возникало вопросов. 

Не все, конечно, нравилось... Пришлось отказаться от привычного NETBeans в пользу STS (нетбинс отвратительно работал с Groovy кодом, жутко тормозил, подчеркивал правильный код). В STS очень бесила неработающая отладка в замыканиях (В NETBeans тоже не работала). Говорят в Идее работала. 

Это было пол года назад. Что изменилось с тех пор - не знаю. Но вот тут нужно будет сделать один бэкэнд к БД, вопросов о фреймворке не возникает  

Да, еще вчера я хотел все делать на Grails. А сегодня подумал, зачем изобретать велосипед, если можно взять почти готовый и по-быстрому допилить. Тем более, что примеры использования Liferay под какой-никакай нагрузкой таки есть http://www.emforge.net/web/russian-liferay...%B5%D1%82%D0%B5

Andrey1, 



С lifeRay у меня по-быстрому не получилось (из-за багов и проблем с документацией). Но в целом LifeRay интересный проект, на мой взгляд - самый продуманный портальный фреймворк.  

Насчет изобретения велосипеда.... смотрите, чтоб с LifeRay у Вас не получилось как в известном анекдоте - "а теперь напильником, напильником...". 

Честно говоря, уже выбираю между Grails, OpenXava и Spring Roo для разработки CRUD интерфейса, который можно будет постепенно "наращивать". Хотелось бы на основе разработанной схемы базы (которую удобно разрабатывать, в примеру, в MySQL Workbench), можно было просто (в идеале - автоматом) получить готовый CRUD интерфейс c security (авторизация и ограничения прав), на основе JPA сущностей (которые можно легко сгенерировать, в том же NetBeans).
А дальше, логику доделывать используя GenericDao для JPA сущностей.

Так же вызывает интерес глюченность стыковки Grails, OpenXava и Spring Roo с Liferay (дабы выбрать наименее глюченный фреймворк для разработки под Liferay).

Это сообщение отредактировал(а) Andrey1 - 31.3.2011, 22:43

Andrey1, 

Про OpenXava первый раз слышу 

Когда пол года назад копал Spring Roo - пришел к выводу что его еще рано использовать. Возникало много вопросов, решения на которые я не находил. 




Имхо, если Вы все делаете с "нуля" лучше отталкиваться не от БД, а от классов. Т.е. создать объектную модель Ваших данных, а потом замапить ее на таблицы.  И Grails и Roo сделают это автоматически.  И построят простенький CRUD, который после некоторой доработки напильником может быть вполне приличным ( пол года назд Roo требовал гораздо большей доработки напильником ).

Я отталкиваюсь от диаграммного представления моделей, которые будут мепится в базу понятным и оптимальным образом. Из последнего условия я делаю вывод, что модельную структуру нужно делать таки в базе (как скажем нужно оптимально мепить String тип? ). Хотя возможно есть удобный UML редактор классов, из которого можно сгенерировать нормальную схему для базы и мне нужно просто о нем узнать . 

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

Текущая проблема с Grails: как задать способ отображения связанных сущностей для конкретной сущности (то есть, например, отображать  в dropbox не id связанных сущностей, а уникаельное имя, например), без переписывания scalfodling сгенерированных вещей...?

Могут быть проблемы с использованием этих моделей. Как я понял с версиями у Вас уже возникли.




В dropbox-ах отображается инфа из метода toString() . Т.е. можно в классе модели переопределить метод toString(). 

Да, от JPA cущностей для Grails пока отказался. Заново создал groovy модели через Grag плагин по схеме базы.


Ага... Ну как вариант. Только это не совсем правильно, так как в toString нужно выдавать как раз id для точного восстановления объекта после и/или при сериализации. Плюс, иногда хочется в разных моделях отображать связанные модели чуть по другому (скажем, показывать и прятать дополнительную информацию).

Сейчас интересно понять, реализована эта возможность в Grails в принципе. Для меня scalfolding не является целью само по себе, так как scalfolding решает только одну задачу. А в реальности наслаивающихся задач всегда много и хотелось бы автоматом или просто удобным способом решать их как можно больше.

Добавлено через 4 минуты и 16 секунд

Да, меня тоже смущает неизвестность фреймворка. Хотя идея и концепция проекта на 100% правильная. Вопрос только в качественной реализации.
ЗЫ: можешь меня на "ты" называть .

Grails оказывается умеет делать scalfolding для неопределяющих связей: когда ссылка из сущности к сущности может быть пустой (NULL). Это порадовало .

Это сообщение отредактировал(а) Andrey1 - 6.4.2011, 12:47

Andrey1, 




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

http://grails.org/doc/latest/ref/Command%2...-templates.html
http://www.jakusys.de/blog/2008/12/grails-...lding-in-depth/




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

Хотелось бы оттянуть этот момент на как можно более поздний срок . В идеале хотелось бы иметь возможность управлять scalfolding (ну или как люди пишут, вместо scalfolding получать готовое приложение): управлять порядком столбцов, добавлять вычисляемые столбцы, добавлять фильтры, управлять правами на действия (скажем, delete и edit разрешать только группе admin).

Добавлено через 2 минуты и 48 секунд
А на тему Liferay и Roo, они похоже еще не очень дружат, так так roo не поддерживает JSR 286: http://www.liferay.com/community/forums/-/...CAED2860.node-1

Ну так тут надо уже программировать... немного    Все же Grails - фреймворк, а не CMS. Хотя и в CMS, как только нужно что-то выходящие за рамки, приходится лезть в код.

Возможно уже поздно или не в тему, но есть свеженький, развивающийся фреймворк http://www.playframework.org/

Посмотрите демо, может вам подойдет