Доброго дня. У меня пара вопросов связанных с выбором CMS (на Java). 

Знаний по Java совсем мало (в процессе изучения), но по PHP их еще меньше. Задумался в нашем небольшом едва-ли-айтишном-коллективе проект социалки а-ля "бизнес-лепра"+с мощным поисковиком по участникам портала в духе LinkedIN+активное использование google wave (не критикуйте плиз). Рассудив за кружкой пенного напитка что движок на java будет справляться со всеми возможными нагрузками на порядок быстрее чем PHP и что само провидение виною тому, что я в данный момент сам изучаю язык (основы по Шилдту, J2SE 1.6.. надеюсь и до EE скоро руки дойдут) решили попробовать взять в качестве основы для всего проекта Java. На утро схватился за голову - задача показалась неподъемной для новичка, хотя в какой-то мере и позволит немного лучше понимать те проблемы с которыми сталкиваются EE-разработчики.

Самым благоразумным мне показалось попробовать использовать какую-нибудь из имеющихся CMS-ок на Java, однако и тут не все так просто. Во-первых даже во многим известном списке Open Source CMS in Java почти два десятка программных продуктов с приблизительно одинаковым описанием и без какой-то конкретно очерченной бизнес-задачей. С наскока так же не удалось нагуглить ни одного сравнения этих CMS-ок между собой. Результатом поисков стал только доклад Олега Сороки (луч доброты тебе, человек) выполненный в рамках курсовой на кафедре при университете ХНУРЭ. 
Оказалось что почти все cms-ки из списка java-source не имеют русских сообществ разработчиков, а как следствие и документации на русском языке. Английский для чтения у меня в принципе есть, но русская документация это очень существенный плюс для чайника. В итоге список возможных кандидатов был значительно сокращен до трех CMS:
- OpenCMS
- Magnolia CMS
- DotCMS

Alfresco, упоминаемый автором презентации, в этот список не попал от одного слова "система электронного документооборота". В прочих продуктах смутил меньший объем документации (хоть и на английском) и менее развитый форум.

Ребят, у меня всего два вопроса:
1. Какие основные преимущества разработки на базе Java CMS против PHP; (эээ...)
2. Какую cms-ку выбрать чайнику с учетом поставленной задачи. 

апендикс: Проект должен представлять из себя систему которая будет включать в себя коллективные блоги с подкастами, расширенные профили пользователей с большим количеством "интересов", по которым их смогут найти другие пользователи, многоуровневую систему ролей (пользователь, премиум-пользователь, партнер, модератор), форум, а так же свой wave-сервер. По задумке работать это все будет с PostgreSQL которую я в данный момент тоже изучаю, количество новых пользователей за первый год до 2000 человек. Если есть еще какие-то критические моменты которые могут повлиять на выбор CMS-ки, пожалуйста укажите на них - у меня все это пока у самого в голове не устаканилось.
А, ну и да.. в здравом уме и трезвой памяти целиком браться за двигло я бы конечно не стал, но для проекта сразу предложили финансовую помощь достаточную чтобы оплатить 2-3 месяца работы Java-программисту.. Поэтому решено было хотя бы "попробовать".

Спасибо, надеюсь на вашу помощь.

Это сообщение отредактировал(а) powerOn - 10.6.2010, 08:16

53x7u5, 

Посмотрите LifeRay. 

На твоём месте не сбрасывал бы PHP со счетов, а нашёл бы PHP CMS которая работает без проблем на Resin Quercus (java compiler for PHP). А потом, если нужно, дописывал / интегрировал туда java компоненты. 

53x7u5,

 С этим справится и VPS или выд. сервер начального уровня с системой на базе одной из CMS/CMF на PHP, Python, Ruby... На этих языках спрототипировать и проверить идею в раз 10-ть быстрее, чем на Java или том же C#. На Java же ведут разработку обычно более серьезных и сложных бизнес-систем, чем социальная сеть с коллективным блогом.

Если все же решитесь делать систему на Java, то столкнетесь с выбором:
1. Использовать последний стандарт Java EE 6, но придется писать все с нуля. Хотя при наличии опыта с нуля пишется довольно быстро.
2. Или использовать одну из CMS/CMF, которые максимум тянут на Java EE 5, а то и вовсе выдумывают собственные стандарты-велосипеды.

Хорошие СMS есть и на С# и на Java. В Java есть еще и порталы удовлетворяющие JSR 168 и JSR 286 (тот же упомянутый выше liferay) 


 А если говорить о фреймворках то тут Java вообще предоставляет отменный выбор качественных решений.  




EE - не для разработки сайтов. Хотя при желании использовать можно, но очень осторожно. Гораздо удобней и продуманней в этом плане продукты Spring Source.  Кстати, в плане скорости разработки web решений рекомендую Вам познакомится со Spring Roo и Grails (там, правда, активно используется Groovy, но это тоже язык для JVM, хоть и скриптовый) - думаю, после этого слова про медленную скорость web разработки на Java вы возьмете обратно. 


 

 Но на ней можно и нужно разрабатывать веб-сайты.

 Уже общались на эту тему здесь: http://forum.vingrad.ru/topic-285228.html   

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

Именно из-за этого и  обратил не так давно внимание на Java EE 6(конкретно контейнер Glassfish 3 - других пока нет и появятся не скоро). Почему? А дело в следующем.

Разработка сайта на Java являет собой процесс постоянной перекомпиляции и редеплоймента в контейнер. Это само по себе очень долго. В Java EE 6 же контейнерах содержится весь необходимый функционал, который уже дотягивает до Spring Framework: EJB 3.1, DI, а также JPA 2.0, Веб-сервисы и так далее, поэтому нет необходимости при каждом редеплойменте их перезагружать. В итоге процесс запуска солидного приложения в Tomcat или Jetty с Spring(DI + обертки к JPA и пр.) + Hibernate(JPA) + ... занимает на среднем компьютере до 1 минуты, а в Glassfish 3 всего-лишь 10-15 секунд - все библиотеки уже загружены и инициализированы. Да и самих редеплойментов удается делать до 100 штук, после чего необходим конечно же перезапуск.
Спасает меня также и JRebel, который сократил количество редеплойментов до минимума. Стоит недорого, а удовольствия много.

Все имхо, конечно же.

Отлично, посоветуйте вменяемый php фреймворк со скоростью разработки сопоставимой с Grails? Мне сейчас очень нужен.




Вы привели ссылку на мой пост, где я изложил требования которые предъявляются к web сайтам. Добавлю еще парочку - недорогой хостинг и простота смены дизайна.

Так вот, недорогой томкэт хостинг найти не проблема, если Вы знаете английский и у вас нормальная кредитка. GlassFish хостинг в разы дороже.  Так же для для TomCat-а можно взять недорогой VPS. GlassFish на таком Вы просто не запустите.


Кроме того, сама по себе спецификация Java EE разрабатывалась с прицелом на корпоративный рынок, и многие моменты, как совместимости с СЕО,  простота смены дизайна не входили в приоритетные задачи. Да, все решаемо (но какой ценой?), да ее6 уже не кажется чем-то, что сделали умные дяди очень далекие от реальной жизни. Но все равно, для web он тяжеловат и местами не удобен.




Это проблема? Или Вы не приемлите юнит тестирование? 



Это сообщение отредактировал(а) Vasay - 24.6.2010, 20:22

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

 Со скоростью разработки - Symfony. Но он довольно медленный.
Вполне приличный по структуре, документации и коду - Zend Framework.
Любые другие фреймворки - уже по вкусу.

Если вы будете разрабатывать какой-либо веб-сайт с конкретным ТЗ, то я очень и очень рекомендую поискать среди готовых систем(как-то Drupal и ему подобные) необходимый набор базовых функций и начать работу с ним. Получится сделать быстро, а внешний вид всегда легко изменить, что даже будет незаметно, что это сделано на базе какой-то распространенной системы.

 Да, вы правы, просто но привык к тому, что сервер имеет по умолчанию 1ГБ памяти и выше, поэтому не принимал это во внимание.

Но для этого и перезапуск сервера не требуется. Да, наверно, и запускать его не требуется.




Поковырял на днях - не в восторге от кода. Жуткая каша в "моделе". 



Начал вчера с ним возиться.  Структура и код вполне пришлись по вкусу.  Но руками делать, похоже много надо, хотя может я еще не до конца разобрался. И еще прочитал, что далеко не на всяком хостинге будет работать.



Увы, но в данный момент ТЗ у меня весьма специфично. 
Вообще, "по-быстрому склепать сайтик" предпочитаю на Джумле. Раньше еще WP использовал - но последнее время с ним гонят с недорогих хостингов, очень уж прожорлив до ресурсов. А плагины - просто находка для хакера. У Джумлы, правда, тоже. 


Но если посмотреть на ТЗ озвученное в первом посте, то из всего с чем имел дело, LifeRay, несмотря на некоторые свои недоработки ИМХО лучший вариант.

Все таки его функционал расширяется не с помощью специфичных для конкретного движка плагинов (а часто и конкретной версии движка), а с помощью стандартизованных портлетов   (JSR 168 и JSR 286) 
Кстати, при разработке портлетов с использованием websynergy сервера (интересно, проект еще жив?) перезапускать как сервер так и портал не приходилось 


Это сообщение отредактировал(а) Vasay - 24.6.2010, 21:42

 Попробовал вчера последнюю версию 6.0.0 RC2, действительно ее можно порекомендовать автору топика. Только нужно причесывать очень много - отключать лишние модули, поля в профилях и так далее, иначе у пользователей будут разбегаться глаза от разнообразия(имхо главная ошибка современных "стартаперов").

Почему CMS (плохо представляю, что это такое, наверное много чего можно так назвать - контент-то везде есть) не делают ( или делают? ) как набор независимых сервисов? Или набор независимых приложений (например, на GoogleApplicationEngine - GAE)? Способ общения "запрос-ответ" через HTTP к этому же вполне располагает. Зачем загружать all-in-one фреймворки и потом искать для них хостинг? Что препятствует добавлять функциональность по-немногу, о чем выше писал dobrolub ?

COVD, 

А не слишком ли накладно общаться по HTTP? 

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

Это клиент соединяется по HTTP с 10 приложениями (серверные веб-приложения). А серверные приложения между собой могут обмениваться любым способом - на серверной стороне меньше ограничений. Однако если серверные приложения общаются между собой через интернет, то HTTP и здесь уместен. Безусловно, такое общение надо минимизировать. Но полностью внутреннего обмена на серверной стороне не избежать. Например, все приложения должны при первом запросе клиента связываться с приложением, отвечающим за авторизацию клиента. 

Что касается эффективности HTTP, то она падает в случае обмена большим количеством коротких сообшений. Но тогда синхронный "запрос-
ответ" заменяют асинхронным вариантом (для тонкого клиента AJAX , например). Но это - тоже HTTP.

Относительно "ресурсов" - конечно, все не бесплатно, но и врядли "в разы".

Позволю себе вставить свои пять копеек.
И как ни странно - в защиту PHP.

До сих пор умиляюсь от CMS Drupal, хотя третий год работаю с Java.

С русской документацией так себе, зато: 
1. Дофига доков на родном портале (drupal.com)
2. Четко структурированный, актуальны и понятный API
3. Писать модули - одно удовольствие.
4. Туева хуча уже готовых модулей.
5. Смена шаблонов - проста до ужаса. (ну конечно от навороченности шаблона зависит)

В своё время пришлось осваивать данную CMS, в том числе и написание модулей, с нуля и быстро  Впечатления - только положительные. На Java такого не встречал. Правда, если быть объективным, я на н еочень джавовые CMS-ки ковырял, но тем-не менее. Трёх попыток мне хватило 

Java имеет один безспорный плюс: когда надо дёргать клиента с сервера по серверному событию. Тут да - на PHP фоновый процесс не запустишь.

Хорошо, конечно, но многое из того, что вы описали - это заслуги самого PHP, а не Drupal.

Минусы разработки на Drupal, и ему подобных:
1. Отсутствует какая-либо ORM или другая абстракция доступа к базе данных. Все, чего достигают разработчики таких систем: подстановку параметров SQL запроса для защиты от SQL-инъекции.
2. Отсутствует какая-либо транзакционность.
3. Отсутствует юнит-тестирование. Самому пытаться прикручивать - это только трата времени, нужно чтобы это предлагали разработчики системы из коробки.
4. ...

В итоге комплексная система на базе Drupal будет изобиловать ошибками. Исходя из опыта. Правда у PHP-разработчика по этой причине всегда есть работа.

Конечно, на Java может быть точно такая же ситуация, как я привел в п.1-3, если постараться.