Drupal как интерфейс корпоративной БД

Главные вкладки

argd 14 февраля 2007 в 13:20

Отцы, помогите советом!
Назрела надобность переписать под корень внутреннюю БД кадрового агентства.
Собственно, в задачах: дешево и сердито организовать работу с анкетами людей (сосикателями и заказчиками; создание, редактирование, поиск, создание выборок, экспорт, печать etc), ну и собственно управление проектами, то бишь контроль работы сотрудников. Все, ессесно, в локалке.

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

Отсюда три вопроса к уважаемому all.

1. Как вы думаете - подойдет ли мне вообще Drupal (ну или какая-то другая готовая CMS)?
2. Существуют ли готовые или полуготовые модули под примерно мои задачи (тут не просто работа с каталогами, таксономию можно использовать конечно, но только как часть, скорее нужны готовые модули дизайна БД и управления юзерами сайта)? Что-то мне пока не удалось отыскать ничего похожего, что странно - задача-то в общем-то типовая, наверное не там искал.
3. Подскажите, плз, по возможности, какие из следующих типов модулей существуют под drupal?
- авторизация по ldap
- настраиваемое журналирование действий пользователей сайта (например с возможностью настройки по категориям действий)
- функции оповещения (e-mail, sms и т.д.)
- импорт (парсинг) вордовских (xml) документов

Заранее благодарю.

1. да
2. здесь искали http://drupal.org/project/Modules ? Управление юзерами http://drupal.org/project/Modules/category/76
3. - авторизация: http://drupal.org/project/Modules/category/74 вообще и в http://drupal.org/project/ldap_integration в частности.
- оповещение и почта http://drupal.org/project/Modules/category/66
- импорт xml надо поискать, а пользовательский ввод вордовских текстов copy&paste с сохранением разметки возможен через FCKeditor или timiMCE.

Я ставлю строчку "php_value error_reporting 7" в файл .htaccess, а вы?

Полный русский перевод Drupal 5.x и еще некоторых модулей.

seaji 14 февраля 2007 в 19:23

Категория немного не та.
Друпал предназначен для построения сайтов сообществ. Но...
В данном случае слово "предназначен" означает, что это сделать проще всего. Как раз, два, три.
Тем не менее, у Друпала есть своя отличительная черта - Супер Мега Гибкость. Это позволяет ему становиться идеальной платформой и для других решений. Не без геммороя, конечно, но в данном случае этого геммороя будет меньше (если уж Вам так критично использовать CMS).
При этом учтите, что 99.9% модулей предназначены для сайтов сообществ.
Еще один момент.
В Друпале есть своя единица информации - документ (node или нода). Этой единицей может быть все что угодно, статья, блог, изображение, анкета.
Модуль CCK создает новые типы документов, но он дает им свои, четко фиксированные имена полей базы.
Если Вы хотите использовать имеющуюся базу, то скорее всего нужно будет писать свой модуль. ИМХО что все равно проще чем писать самому все с нуля.

axel 15 февраля 2007 в 3:59

Да, подойдет. Хотя Drupal позиционируется как CMS статусу CMF он вполне соответствует. API позволяет строить в принципе различные вебприложения. Не соглашусь с seaji, хотя декларируемое направление - организация сообществ, но движок задействован уже на стольких разных сайтах, что решений набралось под разные случаи жизни.

В фирме где я работаю (ГЦБиТ - www.cbtc.ru) Drupal используется на внешнем сайте и в интранете для разных нужд. Мы используем Drupal 4.6-4.7 с постепенным переходом на Drupal 5. Drupal не охватывает всю инфраструктуру, но то что использует вебинтерфейс работает на Drupal или в процессе перевода под него. Из модулей мы используем CCK+Views - они позволяют сделать многое без программирования, а в интранете где системные ресурсы не являются таким критичнным местом как на хостинге, можно без ограничений плодить эти views, не парясь эффективностью реализации. Используем модуль работы с LDAP для авторизации через Active Directory. Блоги, форумы, постинг новостей - возможности касающиеся коммьюнити напротив практически не задействованы.

Дополнительно задействован CiviCRM (www.civicrm.org - CRM интегрированный с Drupal) + CiviMail (для почтовых рассылок). Но от этой системы впечатления двойственные. Вроде продуманная архитектура и в движок он вписывается хорошо, но запутанная настройка и множество мелких ошибок раздражают. Дописывать что-то свое к нему пока тоже непонятно как, там свой API и документации не густо. Но вообще, CiviCRM хороший пример системы, которая использует Drupal как презентационный интерфейс, имея при этом свою архитектуру. Мы похожим образом готовим сейчас под Drupal систему онлайн-бронирования билетов (авиа, ж/д, гостиницы), которая будет работать в интранете и на внешнем сайте.

Плюсы использования Drupal в интранете:

1. Drupal написан на PHP, который является очень популярным языком и под него легко найти готовые решения и программистов

2. Простой API, легко осваивается даже начинающими программистами.

3. Готовая реализация авторизации и работы с пользователями, построение форм, интеграция JS (AJAX, в Drupal 5 также JQuery), расширяемая модель документов (механизм node) и категорий к ним (taxonomy).

4. Много готовых модулей, много документации собранной централизованно на drupal.org

Недостатки:

1. Drupal написан на PHP, который по безопасности, реализации объектной модели и скорости вызывает много нареканий и во многих случаях эффективней оказывается реализация вебсистем на других языках (как альтернативы: Java, Python, Ruby). Под PHP программируют очень многие и сложилась прослойка разработчиков, называющих себя "PHP-программистами" - PHP их первый и единственный язык, отсюда нередки кривые архитектуры и низкое качество кода.

2. Могут быть случаи неприятия API - Drupal практически не использует объектную модель PHP (ввиду ее слабости в PHP4, но может быть Drupal постепенно задействует новые возможности появившиеся в PHP5), многим такое отсутствие объектности не нравится. Если программист пишет код интегрируясь с API лишь формально, то Drupal из среды для ускорения разработки превращается в тормоз - вместо привычных конструкций, программисту приходится обращаться к непонятным ему функциям.

3. Слабая реализация работы с несколькими БД, поддержка БД кроме MySQL есть, но в настоящее время готовый вариант только для PostgreSQL.

4. Документации на русском недостаточно и до сих пор нет единой структуры документации на drupal.ru.

argd 15 февраля 2007 в 12:57

Прежде всего, всем отклинувшимся - огромное спасибо за развернутые ответы! Буду разгребать представленную информацию

vadbars@drupal.org, отдельное спасибо за ссылки, особенно порадовало наличие практически всех нужных вспомогательных модулей.

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

axel, если не трудно, не могли бы вы пояснить в общих чертах - что в таком случае должно означать "написание кода, интегрированного с api НЕ лишь формально" - то бишь, может есть боле-менее четкое руководство, как эффективнее использовать API друпала?

axel 15 февраля 2007 в 16:21

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

--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!

vadbars@drupal.org 15 февраля 2007 в 12:25

Удачи в разработке! Сообщайте о достигнутых успехах и обнаруженных проблемах. Мне это особенно интересно, поскольку вскорости нужно будет делать сайт для кадрового агентства. Может быть, и вашу разработку внутренней БД удастся им продать.

Я ставлю строчку "php_value error_reporting 7" в файл .htaccess, а вы?

Полный русский перевод Drupal 5.x и еще некоторых модулей.

argd 15 февраля 2007 в 13:05

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

SiR 16 февраля 2007 в 15:04

Ответ на вопрос 1.
Drupal - есть практически идеальный интерфейс для подобного рода задач

В плюсе
- свобода использования php c любыми дополнениями (ImageMagik, fpdf и остальное, что придет в голову)
- Отсутствие проблем с аудентификацией пользователей, оформлением страниц и прочих вопросов, не связанных с конкретной задачей

В минусе
- Form API - предоставляет не очень много возможностей
- Усложнение Form API при переходе от версии 4.7 -> 5.1

Ответ на вопрос 2.
Ответы были выше

Ответ на вопрос 3.
- ldap - существует, но лично я его не пробовал
- журналирование - можно использовать штатное, можно написать свое (кому как нравится). Трудозатраты примерно одинаковы.
- функции оповещение - аналогично журналированию
- xml + php -> google search работает

Dan 16 февраля 2007 в 21:55

>- Form API - предоставляет не очень много возможностей
>- Усложнение Form API при переходе от версии 4.7 -> 5.
Может усложнилось из-за повышения возможностей?

SiR 16 февраля 2007 в 23:43

> Может усложнилось из-за повышения возможностей?
Очевидная выгода конечно в том, что теперь для одинаковых форм в разных hook'ах можно использовать одну форму. Кроме того появилась возможность "отлавливать" нажатие разных кнопок через $form_values_op_, а не через $_POST.
Усложнение состоит в том, что пропадает наглядность кода выводимой страницы.

А самая засада, для меня лично, состоит в том, что надо переписать все формы в 27 модулях.

Кстати, ради прикола, публикую список модулей, которые крутятся на внутреннем корпоративном сайте.
Думаю сообщество позабавит то, для чего можно приспособить drupal

audio_control - Аудио контроль менеджеров	
contact - Адресная книга	
contact_admin - Адресная книга - Администрирование	
contact_bd - Дни рождения сотрудников	
contact_boss - Начальники и подчиненные в компании	
contact_comment - Адресная книга - Комментарии Call Center	
contact_mail - Адресная книга - Отправка почтовых сообщений	
courier - Заявка на курьера	
сredit - Заявка на предоставление кредита клиенту	
education - Опросники	
groupt - Учет работы группы распределения рекламных телефонных звонков.	
lunch - Заказ обедов	
mar - Почтовый архив	
mar_partner - Почтовый архив - Работа с партнерами	
msign - Установка подписи в Outlook Express	
phone - Поиск звонка клиента	
photobank - Фото-Банк	
policy - Выписка полисов 
repayment - Заявка на возврат денег клиенту	
timeboard - Учет рабочего времени	
sssssadm - Служебные функции	
xxxxx - Служебные функции для работы системы учета рабочего времени.	
adm_pbx - Служебные функции для обработки логов телефонной станции
to - Интеграция с корпоративной системой