Вопрос к программистам. Почему Drupal?

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

Аватар пользователя pepelac pepelac 10 октября 2010 в 10:49

Я понимаю, когда не_умеющие писать ни на каком языке программирования горят желанием наваять сайт - они выбирают друпал (или джумлу, или вордпресс, или...). Но вот вижу по этому форуму, что толковые прогеры тоже этими цмс балуются(ли не только балуются?). Почему вы не делаете сайты на ZF, Yii, Django, JSF и т.д.

Комментарии

Аватар пользователя v1adimir@drupal.org v1adimir@drupal.org 12 октября 2010 в 21:03

Beloretsk wrote:
Зачем изобретать велосипед, можно время потратить более полезно

Потому что программистам это приколько, тешит их самомнение, а, на самом деле, – не хватает IQ/квалификации разобраться в «чужой» системе. Более 90% процентов громких заявлений, что я напишу свой велосипед быстрее и лучше проистекают из последнего пункта. )

Аватар пользователя Full_acсess Full_acсess 10 октября 2010 в 11:11

"pepelac" wrote:
Но вот вижу по этому форуму, что толковые прогеры тоже этими цмс балуются

где вы на этом форуме видели ТОЛКОВОГО прогера балующегося джумлой, киньте ссылку
"pepelac" wrote:
Почему вы не делаете сайты на ZF, Yii, Django, JSF и т.д.

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

Аватар пользователя pepelac pepelac 10 октября 2010 в 11:15

где вы на этом форуме видели ТОЛКОВОГО прогера балующегося джумлой, киньте ссылку

Не цепляйтесь к отдельным фразам, ОК? Давайте в русле всего контекста.

Аватар пользователя pepelac pepelac 10 октября 2010 в 11:17

Full_acсess wrote:
Друпал подходит для большинства задач, но не для всех всетаки, тогда на помощь и приходят фреймворки.

Спасибо за ответ

Аватар пользователя pepelac pepelac 10 октября 2010 в 11:12

Стиль ответа в виде аллегорий или аналогий наверное красив(по мнению отвечающего), но если поподробней?
Но поддержу ваш стиль - Ваша ось занимает меньше места, делает меньше телодвижений при загрузке и/или работе, чем Windows или Linux. Плюс не надо тратить драгоценное время на вникание во всякие таксономии... Разве не прелесть?

Аватар пользователя volocuga@drupal.org volocuga@drupal.org 10 октября 2010 в 11:14

"<a href="mailto:Bullvar@drupal.org">Bullvar@drupal.org</a>" wrote:
Вопрос программистам: зачем вы используете Windows или Linux - можно ведь самому ОС написать?

С каких это пор Друпал приравнивается к ОС? Фанатики

Аватар пользователя Full_acсess Full_acсess 10 октября 2010 в 11:15

"pepelac" wrote:
Ваша ось занимает меньше места, делает меньше телодвижений при загрузке и/или работе, чем Windows или Linux. Плюс не надо тратить драгоценное время на вникание во всякие таксономии... Разве не прелесть?

Да на здоровье, если уложитесь в сроки которые отведены на проект, можете даже фреймворк не использовать а написать ось на асме сайт на php

Аватар пользователя pepelac pepelac 10 октября 2010 в 11:20

Full_acсess wrote:

Да на здоровье, если уложитесь в сроки которые отведены на проект, можете даже фреймворк не использовать а написать ось на асме сайт на php

Ясно. То есть причина выбора друпала - сжатые сроки.

Аватар пользователя Full_acсess Full_acсess 10 октября 2010 в 11:18

"<a href="mailto:volocuga@drupal.org">volocuga@drupal.org</a>" wrote:
С каких это пор Друпал приравнивается к ОС? Фанатики

Вы еретик! - как посмели оскорбить его друпалское величество

Аватар пользователя kodo kodo 10 октября 2010 в 12:15

Да, тема в какой-то бред превратилась. Причем ТС только добавляет масло в этот огонь бреда.
В двух словах по теме.
Считаю что разработчики Друпала создали очень грамотную архитектуру системы, грамотное АПИ - для меня это и были основными причинами. Пробовал до этого Джумлу - показалось бредом абсолютным, только удивился как столько народу могут работать на такой "системе".

Аватар пользователя kyky kyky 10 октября 2010 в 13:12

"pepelac" wrote:
Почему вы не делаете сайты на ZF, Yii, Django

Я пишу под App Engine на Django/Webapp. В плане удобства разработки Друпал и рядом не стоял.
Но если надо быстро наваять блоги+галереи, то Друпалу замены нет.

Аватар пользователя Crea Crea 10 октября 2010 в 13:39

Я начал использовать Друпал еще 5 версии, будучи простым пользователем. Тогда нужно было средство, которое позволило бы мне сделать сайт без знания программирования и развивать его в будущем. Я выбрал Друпал. Потом постепенно его изучал и в итоге программирую под него.
Сейчас, если бы изучал с нуля что-то как программист, возможно выбрал бы что-нибудь другое. Для программиста Друпал неудобен: конфигурация в базе и CMS-ориентированность модулей постоянно мешает. Сейчас изучать что-то другое влом: времени потратишь кучу, а преимущества получишь не настолько большие, если вообще получишь. Для моих задач Друпала пока что хватает.

Аватар пользователя kodo kodo 10 октября 2010 в 15:48

"Crea" wrote:
Друпал неудобен: конфигурация в базе и CMS-ориентированность модулей постоянно мешает.

Это не минуса Друпала, а минуса "программистов"

Аватар пользователя Crea Crea 10 октября 2010 в 16:38

kodo wrote:

Это не минуса Друпала, а минуса "программистов"

Месье Д'Артаньян ? Не узнаю вас в гриме

Вы хотите подвергнуть сомнению факт, что управлять конфигурацией из кода гораздо удобнее, чем плодить тонны говнокода в hook_update_N() и велосипеды с квадратными колесами (например, деплоймент с помощью диффа БД, который используется в некоторых проектах) ?

Аватар пользователя v1adimir@drupal.org v1adimir@drupal.org 10 октября 2010 в 16:58

Crea wrote:
Вы хотите подвергнуть сомнению факт, что управлять конфигурацией из кода гораздо удобнее, чем плодить тонны говнокода в hook_update_N() и велосипеды с квадратными колесами (например, деплоймент с помощью диффа БД, который используется в некоторых проектах) ?

Я могу подвергнуть сомнению данный факт. )
Поддавшись на уговоры программиста, что он необходимый функционал сделает быстрее и удобнее... потом смотришь что получилось и рыдать хочется.
Уточняю, не от счастья!

Друпал -- сакс, но любой самопис сакс гораздо интенсивнее. )

Аватар пользователя kodo kodo 10 октября 2010 в 19:04

"Crea" wrote:
Месье Д'Артаньян ? Не узнаю вас в гриме

Партос, зато вас узнать в любом гриме.
"Crea" wrote:
управлять конфигурацией из кода гораздо удобнее

Удобнее понятие относительное, но не грамотно при построении любой серьезной информационной системы однозначно. Меня этому учили еще на первом курсе института лет 20 назад, а вас уже нет? Вообще, это вполне себе нормальный подход (впихнуть в код настройки) для "Сисадмин (Linux), сетевой инженер (CCNA)", но ни как ни для систем управления предприятием или системы управления сайтами.
Ну и "CMS-ориентированность модулей" вреде как необходима для модулей CMS. Хотя может быть она и мешает "программистам" ... обычно системным... У них несколько иной подход и красота кода так же оценивается несколько иными критериями.

Аватар пользователя v1adimir@drupal.org v1adimir@drupal.org 10 октября 2010 в 18:48

Crea wrote:
v1adimir@drupal.org, ну да, конечно лучше создавать себе проблемы, а потом с ними бороться (Features, CTools exportables).
А в конце сказать: какие мы молодцы! )))

Конечно, гораздо правильнее кодить все проблемы с нуля на ZF и этим немерено гордится. )

Аватар пользователя Crea Crea 10 октября 2010 в 18:52

<a href="mailto:v1adimir@drupal.org">v1adimir@drupal.org</a> wrote:

Конечно, гораздо правильнее кодить все проблемы с нуля на ZF и этим немерено гордится. )

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

Аватар пользователя v1adimir@drupal.org v1adimir@drupal.org 10 октября 2010 в 19:53

Crea wrote:
...Конфигурация в базе - это "трудное детство" Друпала, от которого он постепенно избавляется

Пример, пожалуйста, конфигурационного параметра, который неоправдано сохранятся в базе?

Аватар пользователя Crea Crea 10 октября 2010 в 19:54

<a href="mailto:v1adimir@drupal.org">v1adimir@drupal.org</a> wrote:

Пример, пожалуйста, конфигурационного параметра, который неоправдано сохранятся в базе?

См. выше

Аватар пользователя v1adimir@drupal.org v1adimir@drupal.org 10 октября 2010 в 20:06

Crea wrote:
<a href="mailto:v1adimir@drupal.org">v1adimir@drupal.org</a> wrote:

Пример, пожалуйста, конфигурационного параметра, который неоправдано сохранятся в базе?

См. выше

"См. выше"?? Слушай, я такого параметра не нашел, это из какого модуля?

Аватар пользователя shp@drupal.org shp@drupal.org 10 октября 2010 в 18:12

Друпал вместо классических фреймворков используют по той же причине, что и Си вместо ассемблера Smile В CMS нужно допиливать готовое + писать свое, с фреймворком - в основном писать свое. Зачем писать, если то, что уже накодировано в виде CMS - в основном устраивает? Другое дело, если CMS придется слишком много допиливать - тогда логичнее взять фреймворк.

Что касается сравнения Друпала с другими CMS - у Друпала относительно грамотная структура, относительно красивый код, его многие используют (читай - бесплатно тестируют). В семерке в плане структуры еще несколько лучше.

Аватар пользователя shp@drupal.org shp@drupal.org 10 октября 2010 в 18:16

"Crea" wrote:
Вы хотите подвергнуть сомнению факт, что управлять конфигурацией из кода гораздо удобнее, чем плодить тонны говнокода в hook_update_N() и велосипеды с квадратными колесами (например, деплоймент с помощью диффа БД, который используется в некоторых проектах)?

Что вы имеете в виду под "конфигурацией из кода" и "деплойментом с помощью диффа БД"? И в каких проектах используется такой деплоймент?

Аватар пользователя Crea Crea 10 октября 2010 в 18:24

<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:

Что вы имеете в виду под "конфигурацией из кода" и "деплойментом с помощью диффа БД"? И в каких проектах используется такой деплоймент?

В любых серьезных. Надеюсь, вы же не думаете, что все тыкают в веб интерфейсе на живом сайте ?

Аватар пользователя Crea Crea 10 октября 2010 в 19:54

kodo, вы путаете хранение данных и конфигурации. К примеру, какие на сайте типы контента и какие у них поля - это конфигурация, а не данные, однако Друпал хранит это в базе. Если вы не уловили такую простую мысль, так и скажите, объясню )) Программист фреймворка на порядок быстрее и легче конфигурирует, деплоит такие вещи, потому что все что ему надо - это закоммитить новую версию файла в VCS.

Аватар пользователя shp@drupal.org shp@drupal.org 10 октября 2010 в 21:28

Crea, не совсем понимаю, в чем принципиальное отличие, где хранить конфигурацию - в коде или в БД? При развертывании и в том, и в другом случае нужно нечто скопировать на хост - только в одном случае это файлы, в другом - часть БД. Правда, я не понимаю, в чем принципиальная разница??

С другой стороны - с какими конфигами проще работать программно - с хранящимися в БД или в файлах? И для чего вообще придумали СУБД? Smile Не для того ли, чтобы иметь удобный механизм манипуляции данными, не заботясь при этом о совместном доступе к файлам, о транзакциях, парсинге этих файлов и т.д..?

Аватар пользователя Crea Crea 10 октября 2010 в 22:39

<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:
Crea, не совсем понимаю, в чем принципиальное отличие, где хранить конфигурацию - в коде или в БД? При развертывании и в том, и в другом случае нужно нечто скопировать на хост - только в одном случае это файлы, в другом - часть БД. Правда, я не понимаю, в чем принципиальная разница??

Если мы уходим от любительских сайтов а-ля сайт-визитка конторы "рога и копыта" и "вася пупкин хоумпейдж", то речь идет как минимум о 2 окружениях: девелоперском, и продакшн. Код сначала отрабатывается на машине разработчика, а потом уже в рабочем состоянии деплоится на продашн. В зависимости от желания и кол-ва бабок (на тестеров) может добавиться еще как минимум 1 тестовое окружение, куда попадает код сайта перед продакшном. В таких случаях одним из требований является использование системы контроля версий, что дает не только управление кодом проекта, но и возможность легкого отката при деплойменте.
Работа с конфигурацией в коде дает преимущество контроля этой самой конфигурации вместе с кодом. С другой стороны, изменения в базе контролируются очень плохо.
Особенно преимущества работы с системой контроля версий хороши в команде программистов - можно легко выяснить, кто произвел то или иное изменение конфигурации. Другое дело, попробуйте отследить, например, кто поменял конфигурацию CCK поля в Друпале..

<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:

С другой стороны - с какими конфигами проще работать программно - с хранящимися в БД или в файлах? И для чего вообще придумали СУБД? Smile Не для того ли, чтобы иметь удобный механизм манипуляции данными, не заботясь при этом о совместном доступе к файлам, о транзакциях, парсинге этих файлов и т.д..?

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

Базы хороши для работы с большими объемами данных, которые нужно обрабатывать программно и конфигурация, за редким исключением, в эту категорию не попадает. Есть конечно и граничные случаи. Взять, например, синонимы пути (path aliases) - я бы скорее отнес их к данным, т.к. они они зависят от данных в системе - а вот правила, каким образом эти синонимы генерируются - точно являются конфигурацией. Но Pathauto ведь хранит конфигурацию в базе.

Аватар пользователя v1adimir@drupal.org v1adimir@drupal.org 10 октября 2010 в 23:16

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

Только в самописном проекте есть напрасная иллюзия, что это будет проще. )

Аватар пользователя Crea Crea 10 октября 2010 в 23:38

<a href="mailto:v1adimir@drupal.org">v1adimir@drupal.org</a> wrote:
Все это красиво изложено, только вот самописный проект абсолютно ничем не выигрышнее друпала в этом случае! Возникнут все те же самые проблемы при синхронизации продакшн и девелопмент версий. Один-в-один.

Никто и не утверждал, что проблем не будет совсем. Однако, их будет гораздо меньше.
<a href="mailto:v1adimir@drupal.org">v1adimir@drupal.org</a> wrote:

Только в самописном проекте есть напрасная иллюзия, что это будет проще. )

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

Аватар пользователя v1adimir@drupal.org v1adimir@drupal.org 11 октября 2010 в 0:16

Crea wrote:
<a href="mailto:v1adimir@drupal.org">v1adimir@drupal.org</a> wrote:

Только в самописном проекте есть напрасная иллюзия, что это будет проще. )

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

Ну что и требовалось доказать – друпал реализует лучшие идеи из веб-разработки. А в самописном проекте всю эту шнягу придется сочинять с нуля самому, с косяками, багами, переделками и дедлайнами.

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 10 октября 2010 в 23:29

"<a href="mailto:v1adimir@drupal.org">v1adimir@drupal.org</a>" wrote:
Только в самописном проекте есть напрасная иллюзия, что это будет проще. )

А ещё на самописе можно десятки тысяч онлайн, а на друпале нельзя, мне так [user=Sinkora] сказал

Аватар пользователя shp@drupal.org shp@drupal.org 11 октября 2010 в 0:33

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

Но давайте не будем смешивать разработку и работу готового сайта. На продакшене хранить конфигурацию в файлах - имхо, бред хотя бы из-за проблем с совместным использованием данных, для решения которых, собственно, и придуманы СУБД.

"Crea" wrote:
Транзакционность (атомарность) и совместный доступ к файлам обеспечивается системой контроля версий, и база ее не заменит.

Я имею в виду совместную запись несколькими приложениями одного файла с конфигурацией (как вы это разрулите, интересно?), а не доступ девелопера Пети и девелопера Васи к репозиторию Smile

Делаем вывод: идеальный случай - иметь некий API, который позволит хранить конфигурацию где угодно - и в файлах, и в БД, при необходимости переключаясь между разными вариантами. А вы сразу в крайности - только в файлах Smile

Аватар пользователя Crea Crea 11 октября 2010 в 9:56

<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:

Но давайте не будем смешивать разработку и работу готового сайта. На продакшене хранить конфигурацию в файлах - имхо, бред хотя бы из-за проблем с совместным использованием данных, для решения которых, собственно, и придуманы СУБД.

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

<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:

"Crea" wrote:
Транзакционность (атомарность) и совместный доступ к файлам обеспечивается системой контроля версий, и база ее не заменит.

Я имею в виду совместную запись несколькими приложениями одного файла с конфигурацией (как вы это разрулите, интересно?), а не доступ девелопера Пети и девелопера Васи к репозиторию :)

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

<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:

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

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

Аватар пользователя kyky kyky 11 октября 2010 в 2:14

Во всех фреймфорках модели БД, конфигурацию урлов, основные параметры и ПЕРЕВОДЫ выносят в код.
v1adimir@drupal.org, вы хоть кроме Друпала с каким-нибудь фреймворком знакомы?

"<a href="mailto:v1adimir@drupal.org">v1adimir@drupal.org</a>" wrote:
Ну что и требовалось доказать – друпал реализует лучшие идеи из веб-разработки.

Кэш в БД, например? Функция l(), которая лазит в базу 50-100 раз за 1 страницу?

Аватар пользователя riyuzakki riyuzakki 11 октября 2010 в 3:31

"Crea" wrote:
К примеру, какие на сайте типы контента и какие у них поля - это конфигурация, а не данные, однако Друпал хранит это в базе.

"kyky" wrote:
Во всех фреймфорках модели БД, конфигурацию урлов, основные параметры и ПЕРЕВОДЫ выносят в код.

1. Отключить все модули кроме обязательных;
2. Написать свои модули, в которых будет описание типов нод и полей в коде;
3. Написать свои модули, реализуюшие вывод нужного контента по нужным урлам;
4. Перенести хранение параметров и переводов в settings.php;
5. .......
6. ПРОФИТ!
При этом не нужно заморачиваться с написанием системы с нуля. Не забывайте, друпал - CMF с огромным выбором модулей, превращающих его в CMS.

Аватар пользователя kodo kodo 11 октября 2010 в 7:15

"Crea" wrote:
kodo, вы путаете хранение данных и конфигурации. К примеру, какие на сайте типы контента и какие у них поля - это конфигурация, а не данные, однако Друпал хранит это в базе. Если вы не уловили такую простую мысль, так и скажите, объясню )) Программист фреймворка на порядок быстрее и легче конфигурирует, деплоит такие вещи, потому что все что ему надо - это закоммитить новую версию файла в VCS.

Crea, подходы в хранении конфигурации могут быть разными. Подход, который исповедуете вы очень подходит как раз для системного программирования, когда конфигурация хранится в файлах, глобальных переменных и т.п. Такая система передана в работу и ее конфигурация как правило не меняется, либо меняется только разработчиком, в использовании БД даже обычно и не идет речи, что и правильно.
Развитие любой информационно системы не заканчивается после передачи ее заказчику. В процессе работы системы конфигурация может меняться заказчиком. Для обеспечения целостности данных, одновременного доступа, транзакционности и используют хранения конфигурации в БД. По такому принципу построены системы упраления предпиятиями (ERP-системы), как пример - Oracle E-Business Suite.
"Crea" wrote:
выдуман не академиками из институтов, а обычными программистами из веб-студий

Не могу с уверенностью сказать, не особенно интересовался биографией основных разработчиков Друпала, но вроде многие из них PhD. И именно академический подход в архитектуре друпала мне и понравился. А "обычными программистам из веб-студий" обычно не хватает времени "точить, им все время приходится пилить", после чего и видим данные конфигурации не только в отдельном файле конфигурации, а просто в коде функций - потому что ему так было УДОБНЕЕ
По поводу контроля версий - соглашусь, есть подобный недостаток в Друпале, но не в методе хранения конфигурации в БД вообще. Обычно подобные вещи решаются на уровне ядра системы, чтобы всегда имелась информация "кто, где, когда" сделал изменения конкретной настройки конфигурации. Надо ли это в Друпал, сильно сомневаюсь, но возможно.

Аватар пользователя Kur Kur 11 октября 2010 в 9:23

Что то много гона на друпал последнее время. То по 700 запросов для генерации страницы он делает, то для программистов неудобен ....
Что это: несоответствие процедурного "старичка" современному времени или что то другое?

Аватар пользователя shp@drupal.org shp@drupal.org 11 октября 2010 в 11:53

"Crea" wrote:
Повторяю, конфигурация на продакшн сайте не должна изменяться минуя тестовые окружения.
Приведите пример хоть одного динамического сайта, где нет нужды конфигурировать сайт в процессе работы Smile Сайты-визитки, которые один раз сделали и забыли, в расчет не берем.

Аватар пользователя Crea Crea 11 октября 2010 в 12:13

<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:
"Crea" wrote:
Повторяю, конфигурация на продакшн сайте не должна изменяться минуя тестовые окружения.
Приведите пример хоть одного динамического сайта, где нет нужды конфигурировать сайт в процессе работы Smile Сайты-визитки, которые один раз сделали и забыли, в расчет не берем.

Окончание моей фразы пропустили ?

Аватар пользователя shp@drupal.org shp@drupal.org 11 октября 2010 в 11:59

"Kur" wrote:
Что это: несоответствие процедурного "старичка" современному времени или что то другое?
Я бы не сказал, что Друпал процедурный: http://drupal.org/node/547518 С-ма именования ф-ий/переменных неудобная, это да.

По поводу 700 запросов - приходится самому оптимизировать, что ж делать. Пока разработчики занимаются вкусностями, а до оптимизации руки не дошли. Может, когда-нибудь дойдут Smile Впрочем, в семерке и в этом плане немного получше.

Аватар пользователя shp@drupal.org shp@drupal.org 11 октября 2010 в 13:59

"Crea" wrote:
Окончание моей фразы пропустили ?

Какое именно окончание? Smile "Если заказчик хочет менять конфигурацию, у него для этого должен быть специалист?"

Аватар пользователя Crea Crea 11 октября 2010 в 14:35

shp@drupal.org

Quote:

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

и выше я писал:
Quote:
У себя в девелоперском окружении вы можете редактировать конфигурацию как угодно.

Что тут непонятного ?

Аватар пользователя shp@drupal.org shp@drupal.org 11 октября 2010 в 15:00

Когда вам нужно поменять настройки мобилы, вы делаете это в тестовом окружении, или просто меняете, и все? Зачем заказчику знать про какие-то тестовые окружения или - еще хуже - вызывать специалиста, чтобы что-то настроить на сайте? Только не говорите, что заказчик не должен ничего настраивать - это тогда какой-то статический сайт на HTML получается Smile

Аватар пользователя Crea Crea 11 октября 2010 в 16:14

<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:
Когда вам нужно поменять настройки мобилы, вы делаете это в тестовом окружении, или просто меняете, и все?

Сравнение абсолютно некорректно. В отличие от мобилы сайт - это сложная система, которую заказчик своими кривыми руками может запросто сломать. И большинство студий, которые берут сайт не только на разработку но и на поддержку, дают заказчику очень ограниченные права. Угадайте, почему ? Капитан, Ау.
<a href="mailto:shp@drupal.org">shp@drupal.org</a> wrote:

Зачем заказчику знать про какие-то тестовые окружения или - еще хуже - вызывать специалиста, чтобы что-то настроить на сайте? Только не говорите, что заказчик не должен ничего настраивать - это тогда какой-то статический сайт на HTML получается :)

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

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 12 октября 2010 в 21:14

"<a href="mailto:v1adimir@drupal.org">v1adimir@drupal.org</a>" wrote:
Потому что программистам это приколько, тешит их самомнение, а, на самом деле, – не хватает IQ/квалификации разобраться в «чужой» системе. Более 90% процентов громких заявлений, что я напишу свой велосипед быстрее и лучше проистекают из последнего пункта. )

Ты читал Вандюка? Говорят что все профессиональные программисты читают Вандюка

Аватар пользователя v1adimir@drupal.org v1adimir@drupal.org 12 октября 2010 в 21:37

RxB wrote:
"<a href="mailto:v1adimir@drupal.org">v1adimir@drupal.org</a>" wrote:
Потому что программистам это приколько, тешит их самомнение, а, на самом деле, – не хватает IQ/квалификации разобраться в «чужой» системе. Более 90% процентов громких заявлений, что я напишу свой велосипед быстрее и лучше проистекают из последнего пункта. )

Ты читал Вандюка? Говорят что все профессиональные программисты читают Вандюка

неа. я не проф.программер, мне такие книги читать не положено.