10 октября 2010 в 10:49
Я понимаю, когда не_умеющие писать ни на каком языке программирования горят желанием наваять сайт - они выбирают друпал (или джумлу, или вордпресс, или...). Но вот вижу по этому форуму, что толковые прогеры тоже этими цмс балуются(ли не только балуются?). Почему вы не делаете сайты на ZF, Yii, Django, JSF и т.д.
Комментарии
Вопрос программистам: зачем вы используете Windows или Linux - можно ведь самому ОС написать?
Зачем изобретать велосипед, можно время потратить более полезно
Потому что программистам это приколько, тешит их самомнение, а, на самом деле, – не хватает IQ/квалификации разобраться в «чужой» системе. Более 90% процентов громких заявлений, что я напишу свой велосипед быстрее и лучше проистекают из последнего пункта. )
где вы на этом форуме видели ТОЛКОВОГО прогера балующегося джумлой, киньте ссылку
Ну во первых в друпале есть собственный фреймворк с помощью которого и решается большинство задач, а во вторых кто вам сказал что не делаем? Друпал подходит для большинства задач, но не для всех всетаки, тогда на помощь и приходят фреймворки.
где вы на этом форуме видели ТОЛКОВОГО прогера балующегося джумлой, киньте ссылку
Не цепляйтесь к отдельным фразам, ОК? Давайте в русле всего контекста.
Спасибо за ответ
Стиль ответа в виде аллегорий или аналогий наверное красив(по мнению отвечающего), но если поподробней?
Но поддержу ваш стиль - Ваша ось занимает меньше места, делает меньше телодвижений при загрузке и/или работе, чем Windows или Linux. Плюс не надо тратить драгоценное время на вникание во всякие таксономии... Разве не прелесть?
С каких это пор Друпал приравнивается к ОС? Фанатики
Да на здоровье, если уложитесь в сроки которые отведены на проект, можете даже фреймворк не использовать а написать
ось на асмесайт на phpЯсно. То есть причина выбора друпала - сжатые сроки.
Вы еретик! - как посмели оскорбить его друпалское величество
Да, тема в какой-то бред превратилась. Причем ТС только добавляет масло в этот огонь бреда.
В двух словах по теме.
Считаю что разработчики Друпала создали очень грамотную архитектуру системы, грамотное АПИ - для меня это и были основными причинами. Пробовал до этого Джумлу - показалось бредом абсолютным, только удивился как столько народу могут работать на такой "системе".
Потому что:
Доступно
Рационально
Удобно
Практично
Адекватно
Легко
Я пишу под App Engine на Django/Webapp. В плане удобства разработки Друпал и рядом не стоял.
Но если надо быстро наваять блоги+галереи, то Друпалу замены нет.
Потому что на друпале быстрее. )
Я начал использовать Друпал еще 5 версии, будучи простым пользователем. Тогда нужно было средство, которое позволило бы мне сделать сайт без знания программирования и развивать его в будущем. Я выбрал Друпал. Потом постепенно его изучал и в итоге программирую под него.
Сейчас, если бы изучал с нуля что-то как программист, возможно выбрал бы что-нибудь другое. Для программиста Друпал неудобен: конфигурация в базе и CMS-ориентированность модулей постоянно мешает. Сейчас изучать что-то другое влом: времени потратишь кучу, а преимущества получишь не настолько большие, если вообще получишь. Для моих задач Друпала пока что хватает.
в клане синкоры прибыло. чёрная сторона наступает
Надо запретить продажи Вандюка
Это не минуса Друпала, а минуса "программистов"
Месье Д'Артаньян ? Не узнаю вас в гриме
Вы хотите подвергнуть сомнению факт, что управлять конфигурацией из кода гораздо удобнее, чем плодить тонны говнокода в hook_update_N() и велосипеды с квадратными колесами (например, деплоймент с помощью диффа БД, который используется в некоторых проектах) ?
Я могу подвергнуть сомнению данный факт. )
Поддавшись на уговоры программиста, что он необходимый функционал сделает быстрее и удобнее... потом смотришь что получилось и рыдать хочется.
Уточняю, не от счастья!
Друпал -- сакс, но любой самопис сакс гораздо интенсивнее. )
Партос, зато вас узнать в любом гриме.
Удобнее понятие относительное, но не грамотно при построении любой серьезной информационной системы однозначно. Меня этому учили еще на первом курсе института лет 20 назад, а вас уже нет? Вообще, это вполне себе нормальный подход (впихнуть в код настройки) для "Сисадмин (Linux), сетевой инженер (CCNA)", но ни как ни для систем управления предприятием или системы управления сайтами.
Ну и "CMS-ориентированность модулей" вреде как необходима для модулей CMS. Хотя может быть она и мешает "программистам" ... обычно системным... У них несколько иной подход и красота кода так же оценивается несколько иными критериями.
v1adimir@drupal.org, ну да, конечно лучше создавать себе проблемы, а потом с ними бороться (Features, CTools exportables).
А в конце сказать: какие мы молодцы! )))
Конечно, гораздо правильнее кодить все проблемы с нуля на ZF и этим немерено гордится. )
Уже давным давно существуют высокоуровневые фреймворки, с нуля кодить ничего не надо. Друпал туда же идет, только с другой стороны. Конфигурация в базе - это "трудное детство" Друпала, от которого он постепенно избавляется
Пример, пожалуйста, конфигурационного параметра, который неоправдано сохранятся в базе?
См. выше
"См. выше"?? Слушай, я такого параметра не нашел, это из какого модуля?
Друпал вместо классических фреймворков используют по той же причине, что и Си вместо ассемблера
В CMS нужно допиливать готовое + писать свое, с фреймворком - в основном писать свое. Зачем писать, если то, что уже накодировано в виде CMS - в основном устраивает? Другое дело, если CMS придется слишком много допиливать - тогда логичнее взять фреймворк.
Что касается сравнения Друпала с другими CMS - у Друпала относительно грамотная структура, относительно красивый код, его многие используют (читай - бесплатно тестируют). В семерке в плане структуры еще несколько лучше.
Что вы имеете в виду под "конфигурацией из кода" и "деплойментом с помощью диффа БД"? И в каких проектах используется такой деплоймент?
В любых серьезных. Надеюсь, вы же не думаете, что все тыкают в веб интерфейсе на живом сайте ?
kodo, вы путаете хранение данных и конфигурации. К примеру, какие на сайте типы контента и какие у них поля - это конфигурация, а не данные, однако Друпал хранит это в базе. Если вы не уловили такую простую мысль, так и скажите, объясню )) Программист фреймворка на порядок быстрее и легче конфигурирует, деплоит такие вещи, потому что все что ему надо - это закоммитить новую версию файла в VCS.
v1adimir@drupal.org,
Из модуля Eyes. У вас он не установлен ?))
Crea, не совсем понимаю, в чем принципиальное отличие, где хранить конфигурацию - в коде или в БД? При развертывании и в том, и в другом случае нужно нечто скопировать на хост - только в одном случае это файлы, в другом - часть БД. Правда, я не понимаю, в чем принципиальная разница??
С другой стороны - с какими конфигами проще работать программно - с хранящимися в БД или в файлах? И для чего вообще придумали СУБД?
Не для того ли, чтобы иметь удобный механизм манипуляции данными, не заботясь при этом о совместном доступе к файлам, о транзакциях, парсинге этих файлов и т.д..?
Если мы уходим от любительских сайтов а-ля сайт-визитка конторы "рога и копыта" и "вася пупкин хоумпейдж", то речь идет как минимум о 2 окружениях: девелоперском, и продакшн. Код сначала отрабатывается на машине разработчика, а потом уже в рабочем состоянии деплоится на продашн. В зависимости от желания и кол-ва бабок (на тестеров) может добавиться еще как минимум 1 тестовое окружение, куда попадает код сайта перед продакшном. В таких случаях одним из требований является использование системы контроля версий, что дает не только управление кодом проекта, но и возможность легкого отката при деплойменте.
Работа с конфигурацией в коде дает преимущество контроля этой самой конфигурации вместе с кодом. С другой стороны, изменения в базе контролируются очень плохо.
Особенно преимущества работы с системой контроля версий хороши в команде программистов - можно легко выяснить, кто произвел то или иное изменение конфигурации. Другое дело, попробуйте отследить, например, кто поменял конфигурацию CCK поля в Друпале..
Транзакционность (атомарность) и совместный доступ к файлам обеспечивается системой контроля версий, и база ее не заменит. Разумеется, речь идет о продакшн окружении. У себя в девелоперском окружении вы можете редактировать конфигурацию как угодно. Суть в том, что на продакшне редактировать ничего не надо(и нельзя), равно как и тыкать в интерфейсе. Продакшн атомарно переключается между устойчивыми, удовлетворяющими нас состояниями.
Парсинг файлов - задача несложная, а в случае хранения конфигурации в коде - даже ненужная.
Базы хороши для работы с большими объемами данных, которые нужно обрабатывать программно и конфигурация, за редким исключением, в эту категорию не попадает. Есть конечно и граничные случаи. Взять, например, синонимы пути (path aliases) - я бы скорее отнес их к данным, т.к. они они зависят от данных в системе - а вот правила, каким образом эти синонимы генерируются - точно являются конфигурацией. Но Pathauto ведь хранит конфигурацию в базе.
Все это красиво изложено, только вот самописный проект абсолютно ничем не выигрышнее друпала в этом случае! Возникнут все те же самые проблемы при синхронизации продакшн и девелопмент версий. Один-в-один.
Только в самописном проекте есть напрасная иллюзия, что это будет проще. )
Никто и не утверждал, что проблем не будет совсем. Однако, их будет гораздо меньше.
Это не иллюзия, а реальный опыт многих команд разработчиков, многих проектов. Экспорт конфигурации в код - современная тенденция в мире Друпала - выдуман не академиками из институтов, а обычными программистами из веб-студий, которые давным-давно затрахались с деплойментом сайтов на Друпале. Такие студии, как правило, имеют опыт разработки и с использованием фреймворков, и на Друпале, так что им есть с чем сравнить.
Это работает и это эффективно.
Ну что и требовалось доказать – друпал реализует лучшие идеи из веб-разработки. А в самописном проекте всю эту шнягу придется сочинять с нуля самому, с косяками, багами, переделками и дедлайнами.
А ещё на самописе можно десятки тысяч онлайн, а на друпале нельзя, мне так [user=Sinkora] сказал
Crea, я с вами согласен, что на этапе разработки могут возникнуть такие сложности (кто изменил конфигурацию, как откатиться к такой-то версии и т.д.). Т.е. если бы конфигурация хранилась в файлах, можно было бы задействовать с-му контроля версий.
Но давайте не будем смешивать разработку и работу готового сайта. На продакшене хранить конфигурацию в файлах - имхо, бред хотя бы из-за проблем с совместным использованием данных, для решения которых, собственно, и придуманы СУБД.
Я имею в виду совместную запись несколькими приложениями одного файла с конфигурацией (как вы это разрулите, интересно?), а не доступ девелопера Пети и девелопера Васи к репозиторию
Делаем вывод: идеальный случай - иметь некий API, который позволит хранить конфигурацию где угодно - и в файлах, и в БД, при необходимости переключаясь между разными вариантами. А вы сразу в крайности - только в файлах
Работа "готового" сайта вообще не должна изменяться заказчиком напрямую, кроме изменений контента. Если заказчик хочет менять конфигурацию, у него для этого должен быть специалист. Проблем "с использованием данных" тут нет, потому что конфигурация - это не те данные, к которым нужен совместный доступ (за исключением доступа в режиме чтения, с которым проблем нет).
И этап разработки вообще-то не заканчивается на этапе сдачи проекта, потом могут быть постоянные доработки, включая изменения в конфигурации
О каких приложениях идет речь ? Повторяю, конфигурация на продакшн сайте не должна изменяться минуя тестовые окружения.
Друпал к этому и идет, только очень медленно. Из модулей лишь меньшая часть поддерживает экспорт конфигурации в код. Поэтому сейчас с деплойментом проблемы.
Во всех фреймфорках модели БД, конфигурацию урлов, основные параметры и ПЕРЕВОДЫ выносят в код.
v1adimir@drupal.org, вы хоть кроме Друпала с каким-нибудь фреймворком знакомы?
Кэш в БД, например? Функция l(), которая лазит в базу 50-100 раз за 1 страницу?
1. Отключить все модули кроме обязательных;
2. Написать свои модули, в которых будет описание типов нод и полей в коде;
3. Написать свои модули, реализуюшие вывод нужного контента по нужным урлам;
4. Перенести хранение параметров и переводов в settings.php;
5. .......
6. ПРОФИТ!
При этом не нужно заморачиваться с написанием системы с нуля. Не забывайте, друпал - CMF с огромным выбором модулей, превращающих его в CMS.
Crea, подходы в хранении конфигурации могут быть разными. Подход, который исповедуете вы очень подходит как раз для системного программирования, когда конфигурация хранится в файлах, глобальных переменных и т.п. Такая система передана в работу и ее конфигурация как правило не меняется, либо меняется только разработчиком, в использовании БД даже обычно и не идет речи, что и правильно.
Развитие любой информационно системы не заканчивается после передачи ее заказчику. В процессе работы системы конфигурация может меняться заказчиком. Для обеспечения целостности данных, одновременного доступа, транзакционности и используют хранения конфигурации в БД. По такому принципу построены системы упраления предпиятиями (ERP-системы), как пример - Oracle E-Business Suite.
Не могу с уверенностью сказать, не особенно интересовался биографией основных разработчиков Друпала, но вроде многие из них PhD. И именно академический подход в архитектуре друпала мне и понравился. А "обычными программистам из веб-студий" обычно не хватает времени "точить, им все время приходится пилить", после чего и видим данные конфигурации не только в отдельном файле конфигурации, а просто в коде функций - потому что ему так было УДОБНЕЕ
По поводу контроля версий - соглашусь, есть подобный недостаток в Друпале, но не в методе хранения конфигурации в БД вообще. Обычно подобные вещи решаются на уровне ядра системы, чтобы всегда имелась информация "кто, где, когда" сделал изменения конкретной настройки конфигурации. Надо ли это в Друпал, сильно сомневаюсь, но возможно.
Что то много гона на друпал последнее время. То по 700 запросов для генерации страницы он делает, то для программистов неудобен ....
Что это: несоответствие процедурного "старичка" современному времени или что то другое?
Окончание моей фразы пропустили ?
По поводу 700 запросов - приходится самому оптимизировать, что ж делать. Пока разработчики занимаются вкусностями, а до оптимизации руки не дошли. Может, когда-нибудь дойдут
Впрочем, в семерке и в этом плане немного получше.
Какое именно окончание?
shp@drupal.org
и выше я писал:
Что тут непонятного ?
Когда вам нужно поменять настройки мобилы, вы делаете это в тестовом окружении, или просто меняете, и все? Зачем заказчику знать про какие-то тестовые окружения или - еще хуже - вызывать специалиста, чтобы что-то настроить на сайте? Только не говорите, что заказчик не должен ничего настраивать - это тогда какой-то статический сайт на HTML получается
Сравнение абсолютно некорректно. В отличие от мобилы сайт - это сложная система, которую заказчик своими кривыми руками может запросто сломать. И большинство студий, которые берут сайт не только на разработку но и на поддержку, дают заказчику очень ограниченные права. Угадайте, почему ? Капитан, Ау.
Да, вынужден вас разочаровать, вообще профессиональная разработка сайтов не вписывается в концепцию CMS, где на живом сайте производятся какие то изменения конфигурации.
Ок, тогда не вижу смысла дальше дискутировать
Ты читал Вандюка? Говорят что все профессиональные программисты читают Вандюка
неа. я не проф.программер, мне такие книги читать не положено.
Чорт, кроме Синкоры никто не шарит больше