Интеграция веб-приложения с Drupal

Я работал больше года, широко используя drupal, но в конце концов отказался от него. Drupal и другие системы CMS имеют очень жесткие ограничения и правила. Я бы использовал Drupal для проектов, где у вас простые требования и мало бизнес-правил или их нет. Drupal усложняется почти сразу, когда вы хотите делать сложные вещи (особенно обратите внимание на систему меню, формы и систему перевода, если вам нужно быть многоязычным).

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

Но совет: никому не доверяйте :) Загрузите его и поиграйте с ним неделю. Вы сможете принять решение и быть более уверенным в своем выборе!

Поскольку Drupal имеет открытый исходный код, вы можете делать с ним все, что захотите. Пара замечаний:

Изменение структуры пользователей / ролей в Drupal было бы утомительным и ненужным. Вам нужно будет, чтобы ваше настольное приложение аутентифицировалось из базы данных MySQL Drupal.

Drupal имеет сотни плагинов практически для всего, поэтому Drupal, без сомнения, может запускать всю "веб-часть" вещей, включая статистику посетителей и т. Д. Вам просто нужно опять же, чтобы подключить ваше настольное приложение к правильным таблицам MySQL и отобразить данные по желанию.

Не забудьте проверить другие системы управления контентом, такие как Joomla! (и многие другие). У каждого есть свои плюсы и минусы. www.opensourcecms.com позволяет вам легко тестировать CMS, и в прошлом я активно использовал его.

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

Краткий ответ: Drupal хорошо подходит для создания чего-то подобного, особенно если вы хотите интегрировать свое приложение / логику в Drupal как набор пользовательских модулей. Другой способ, интеграция Drupal во внешнее приложение, также может быть осуществлен, но это даст вам больше трений, поскольку архитектура Drupals в значительной степени ориентирована на то, чтобы быть самостоятельной структурой.

Более длинный ответ: У меня есть в значительной степени противоположное мнение / опыт по сравнению с Palantirs. Я работаю почти исключительно с Drupal в течение года в контексте двух довольно сложных / «предприимчивых» проектов (после нескольких лет использования «на стороне» для более мелких вещей). Хотя я согласен с тем, что это накладывает некоторые жесткие правила (но не ограничения!), Я считаю это преимуществом, поскольку эти правила дают четкое руководство и предоставляют проверенные способы того, как что-то делать. Три части, упомянутые Palantir, являются хорошими примерами для этого:

• Система меню - Обеспечивает хорошо структурированный и эффективный механизм диспетчеризации, который легко расширяется вашими собственными материалами, обеспечивая при этом огромную гибкость для настройки / управления существующими путями / путями по умолчанию. (Обратите внимание, что «система меню» в Drupal обозначает всю тему управления пространством URL-адресов, а не только подмножество «видимых» меню, которые обычно ассоциируются с этим термином)
• Forms API - декларативный подход к веб-формам с хорошо продуманный рабочий процесс и множество встроенных функций безопасности, о которых вам в противном случае пришлось бы позаботиться самостоятельно. Также очень расширяемый, с прямыми опциями для настройки / расширения уже существующих форм по запросу, добавлять новые правила проверки к любому полю или целым формам, многоступенчатым формам, корректировкам форм на основе javascript и т. д.
• Система перевода - это довольно сложно, просто потому, что интернационализация чертовски сложна. Но он встроен и снова дает четкое руководство о том, как что-то делать, чтобы работать в общем виде (хотя есть проблемы с некоторыми добавленными модулями, которые не используют / не поддерживают его должным образом).

I мог бы привести больше примеров для частей, в которых я ценю «правила», но этот пост уже становится длинным, и мне все еще нужно рассказать о некоторых недостатках;)

Итак, чтобы подвести итог положительной части - если я дал черновые спецификации, которые вы опубликовали, я бы сказал «нет проблем» и выбрал бы Drupal, будучи уверенным, что он станет прочной основой для пользовательских частей, обеспечивая при этом все стандарты, такие как форум, блоги, интеграция twitter / facebook и многие, многие другие в виде уже существующих решений (даже если они могут нуждаться в некоторой адаптации / настройке).

Недостатки: Как всегда, есть недостатки, и некоторые из них существенны, в зависимости от требований / обстоятельств.

• Кривая обучения - Drupal довольно сложен, и «разобраться» в его концепциях нужно время. «Поиграть с ним в течение недели», как предлагает Palantir, безусловно, даст вам общее ощущение / широкое впечатление, но этого никоим образом не достаточно, чтобы серьезно судить о его плюсах и минусах, поскольку они будут обнаруживаться только во время кодирования в / для него. Поэтому, если вы уже хорошо знакомы с установленной структурой веб-разработки, это может быть проблемой. Если вам все равно нужно выучить один, это не должно быть проблемой. Drupal 7 перейдет на PDO, что должно (наконец) положить конец этому сомнительному состоянию.
• Миграции Test / Stage / Production - Части нестандартной гибкости Drupals обусловлены тем, что многие вещи настраиваются в административном бэкэнде, который подразумевает, что многие важные параметры конфигурации хранятся в базе данных. Это делает перенос данных и / или конфигурации между несколькими экземплярами довольно сложным / утомительным, если вы покинули (ранние) стадии разработки, когда вы можете уйти с полными операциями дампа / восстановления (см., Например, этот вопрос и ответы )

Для меня это основные, но вы наверняка найдете больше :)