| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java EE (J2EE) и Spring > Выбирая Java CMS... |
| Автор: 53x7u5 10.6.2010, 00:42 |
| Доброго дня. У меня пара вопросов связанных с выбором CMS (на Java). Знаний по Java совсем мало (в процессе изучения), но по PHP их еще меньше. Задумался в нашем небольшом едва-ли-айтишном-коллективе проект социалки а-ля "бизнес-лепра"+с мощным поисковиком по участникам портала в духе LinkedIN+активное использование google wave (не критикуйте плиз). Рассудив за кружкой пенного напитка что движок на java будет справляться со всеми возможными нагрузками на порядок быстрее чем PHP и что само провидение виною тому, что я в данный момент сам изучаю язык (основы по Шилдту, J2SE 1.6.. надеюсь и до EE скоро руки дойдут) решили попробовать взять в качестве основы для всего проекта Java. На утро схватился за голову - задача показалась неподъемной для новичка, хотя в какой-то мере и позволит немного лучше понимать те проблемы с которыми сталкиваются EE-разработчики. Самым благоразумным мне показалось попробовать использовать какую-нибудь из имеющихся CMS-ок на Java, однако и тут не все так просто. Во-первых даже во многим известном http://java-source.net/open-source/content-managment-systems почти два десятка программных продуктов с приблизительно одинаковым описанием и без какой-то конкретно очерченной бизнес-задачей. С наскока так же не удалось нагуглить ни одного сравнения этих CMS-ок между собой. Результатом поисков стал только http://www.slideshare.net/oleg40a/java-cms Олега Сороки (луч доброты тебе, человек) выполненный в рамках курсовой на кафедре при университете ХНУРЭ. Оказалось что почти все cms-ки из списка java-source не имеют русских сообществ разработчиков, а как следствие и документации на русском языке. Английский для чтения у меня в принципе есть, но русская документация это очень существенный плюс для чайника. В итоге список возможных кандидатов был значительно сокращен до трех CMS: - OpenCMS - Magnolia CMS - DotCMS Alfresco, упоминаемый автором презентации, в этот список не попал от одного слова "система электронного документооборота". В прочих продуктах смутил меньший объем документации (хоть и на английском) и менее развитый форум. Ребят, у меня всего два вопроса: 1. Какие основные преимущества разработки на базе Java CMS против PHP; (эээ...) 2. Какую cms-ку выбрать чайнику с учетом поставленной задачи. апендикс: Проект должен представлять из себя систему которая будет включать в себя коллективные блоги с подкастами, расширенные профили пользователей с большим количеством "интересов", по которым их смогут найти другие пользователи, многоуровневую систему ролей (пользователь, премиум-пользователь, партнер, модератор), форум, а так же свой wave-сервер. По задумке работать это все будет с PostgreSQL которую я в данный момент тоже изучаю, количество новых пользователей за первый год до 2000 человек. Если есть еще какие-то критические моменты которые могут повлиять на выбор CMS-ки, пожалуйста укажите на них - у меня все это пока у самого в голове не устаканилось. А, ну и да.. в здравом уме и трезвой памяти целиком браться за двигло я бы конечно не стал, но для проекта сразу предложили финансовую помощь достаточную чтобы оплатить 2-3 месяца работы Java-программисту.. Поэтому решено было хотя бы "попробовать". Спасибо, надеюсь на вашу помощь. |
| Автор: Vasay 10.6.2010, 11:50 |
| 53x7u5, Посмотрите LifeRay. |
| Автор: dobrolub 10.6.2010, 19:24 |
| На твоём месте не сбрасывал бы PHP со счетов, а нашёл бы PHP CMS которая работает без проблем на Resin Quercus (java compiler for PHP). А потом, если нужно, дописывал / интегрировал туда java компоненты. |
| Автор: Vasay 24.6.2010, 18:43 | ||||
Хорошие СMS есть и на С# и на Java. В Java есть еще и порталы удовлетворяющие JSR 168 и JSR 286 (тот же упомянутый выше liferay) А если говорить о фреймворках то тут Java вообще предоставляет отменный выбор качественных решений.
EE - не для разработки сайтов. Хотя при желании использовать можно, но очень осторожно. Гораздо удобней и продуманней в этом плане продукты Spring Source. Кстати, в плане скорости разработки web решений рекомендую Вам познакомится со Spring Roo и Grails (там, правда, активно используется Groovy, но это тоже язык для JVM, хоть и скриптовый) - думаю, после этого слова про медленную скорость web разработки на Java вы возьмете обратно. |
| Автор: AJetman 24.6.2010, 19:41 | ||
Но на ней можно и нужно разрабатывать веб-сайты.
Очень долго работал и продолжаю работать с 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, который сократил количество редеплойментов до минимума. Стоит недорого, а удовольствия много. Все имхо, конечно же. |
| Автор: Vasay 24.6.2010, 20:17 | ||||||
Отлично, посоветуйте вменяемый php фреймворк со скоростью разработки сопоставимой с Grails? Мне сейчас очень нужен.
Вы привели ссылку на мой пост, где я изложил требования которые предъявляются к web сайтам. Добавлю еще парочку - недорогой хостинг и простота смены дизайна. Так вот, недорогой томкэт хостинг найти не проблема, если Вы знаете английский и у вас нормальная кредитка. GlassFish хостинг в разы дороже. Так же для для TomCat-а можно взять недорогой VPS. GlassFish на таком Вы просто не запустите. Кроме того, сама по себе спецификация Java EE разрабатывалась с прицелом на корпоративный рынок, и многие моменты, как совместимости с СЕО, простота смены дизайна не входили в приоритетные задачи. Да, все решаемо (но какой ценой?), да ее6 уже не кажется чем-то, что сделали умные дяди очень далекие от реальной жизни. Но все равно, для web он тяжеловат и местами не удобен.
Это проблема? Или Вы не приемлите юнит тестирование? |
| Автор: AJetman 24.6.2010, 20:54 | ||||
Юнит-тестирование предпочитаю делать на той стадии, когда система приобретает какие-либо очертания. И ведь юнит-тестированием не разработать вменяемый дизайн.
Вполне приличный по структуре, документации и коду - Zend Framework. Любые другие фреймворки - уже по вкусу. Если вы будете разрабатывать какой-либо веб-сайт с конкретным ТЗ, то я очень и очень рекомендую поискать среди готовых систем(как-то Drupal и ему подобные) необходимый набор базовых функций и начать работу с ним. Получится сделать быстро, а внешний вид всегда легко изменить, что даже будет незаметно, что это сделано на базе какой-то распространенной системы.
|
| Автор: Vasay 24.6.2010, 21:24 | ||||||||
Но для этого и перезапуск сервера не требуется. Да, наверно, и запускать его не требуется.
Поковырял на днях - не в восторге от кода. Жуткая каша в "моделе".
Начал вчера с ним возиться. Структура и код вполне пришлись по вкусу. Но руками делать, похоже много надо, хотя может я еще не до конца разобрался. И еще прочитал, что далеко не на всяком хостинге будет работать.
Увы, но в данный момент ТЗ у меня весьма специфично. Вообще, "по-быстрому склепать сайтик" предпочитаю на Джумле. Раньше еще WP использовал - но последнее время с ним гонят с недорогих хостингов, очень уж прожорлив до ресурсов. А плагины - просто находка для хакера. У Джумлы, правда, тоже. Но если посмотреть на ТЗ озвученное в первом посте, то из всего с чем имел дело, LifeRay, несмотря на некоторые свои недоработки ИМХО лучший вариант. Все таки его функционал расширяется не с помощью специфичных для конкретного движка плагинов (а часто и конкретной версии движка), а с помощью стандартизованных портлетов (JSR 168 и JSR 286) Кстати, при разработке портлетов с использованием websynergy сервера (интересно, проект еще жив?) перезапускать как сервер так и портал не приходилось |
| Автор: AJetman 25.6.2010, 13:14 | ||
|
| Автор: COVD 26.6.2010, 18:29 |
| Почему CMS (плохо представляю, что это такое, наверное много чего можно так назвать - контент-то везде есть) не делают ( или делают? ) как набор независимых сервисов? Или набор независимых приложений (например, на GoogleApplicationEngine - GAE)? Способ общения "запрос-ответ" через HTTP к этому же вполне располагает. Зачем загружать all-in-one фреймворки и потом искать для них хостинг? Что препятствует добавлять функциональность по-немногу, о чем выше писал dobrolub ? |
| Автор: Vasay 26.6.2010, 20:23 |
| COVD, А не слишком ли накладно общаться по HTTP? По-моему, такой подход в разы увеличит потребление ресурсов приложения в целом. Т.е. 10 отдельных маленьких приложений, общающихся между собой, будут жрать ресурсы куда с большем аппетитом чем одно большое. |
| Автор: COVD 28.6.2010, 18:42 | ||
Это клиент соединяется по HTTP с 10 приложениями (серверные веб-приложения). А серверные приложения между собой могут обмениваться любым способом - на серверной стороне меньше ограничений. Однако если серверные приложения общаются между собой через интернет, то HTTP и здесь уместен. Безусловно, такое общение надо минимизировать. Но полностью внутреннего обмена на серверной стороне не избежать. Например, все приложения должны при первом запросе клиента связываться с приложением, отвечающим за авторизацию клиента. Что касается эффективности HTTP, то она падает в случае обмена большим количеством коротких сообшений. Но тогда синхронный "запрос- ответ" заменяют асинхронным вариантом (для тонкого клиента AJAX , например). Но это - тоже HTTP. Относительно "ресурсов" - конечно, все не бесплатно, но и врядли "в разы". |
| Автор: kaa 11.7.2010, 14:39 |
| Позволю себе вставить свои пять копеек. И как ни странно - в защиту PHP. До сих пор умиляюсь от CMS Drupal, хотя третий год работаю с Java. С русской документацией так себе, зато: 1. Дофига доков на родном портале (drupal.com) 2. Четко структурированный, актуальны и понятный API 3. Писать модули - одно удовольствие. 4. Туева хуча уже готовых модулей. 5. Смена шаблонов - проста до ужаса. (ну конечно от навороченности шаблона зависит) В своё время пришлось осваивать данную CMS, в том числе и написание модулей, с нуля и быстро Java имеет один безспорный плюс: когда надо дёргать клиента с сервера по серверному событию. Тут да - на PHP фоновый процесс не запустишь. |
| Автор: AJetman 11.7.2010, 19:08 | ||
Хорошо, конечно, но многое из того, что вы описали - это заслуги самого PHP, а не Drupal. Минусы разработки на Drupal, и ему подобных: 1. Отсутствует какая-либо ORM или другая абстракция доступа к базе данных. Все, чего достигают разработчики таких систем: подстановку параметров SQL запроса для защиты от SQL-инъекции. 2. Отсутствует какая-либо транзакционность. 3. Отсутствует юнит-тестирование. Самому пытаться прикручивать - это только трата времени, нужно чтобы это предлагали разработчики системы из коробки. 4. ... В итоге комплексная система на базе Drupal будет изобиловать ошибками. Исходя из опыта. Правда у PHP-разработчика по этой причине всегда есть работа. Конечно, на Java может быть точно такая же ситуация, как я привел в п.1-3, если постараться. |