DrupalWay Необходимые модули

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

Аватар пользователя ХулиGUN ХулиGUN 10 декабря 2012 в 12:53

Довольно часто вижу на форуме сообщения типа "какой модуль поставить, чтобы была карусель или сворачивающийся блок". И часто в ответах ставят ссылки на модули с орга, которые выполняют данные функции.
Так вот хотелось бы спросить: DrupalWay под собой подразумевает по каждой хотелке инсталить новый модуль или же можно обойтись парой строчек кастомного кода. На своих проектах я использую только минимальный набор модулей, необходимый для базового функционала + некоторые серьёзные модули, которые расширяют возможности движка в конкретном направлении (например, если это магазин, то я ставлю commerce и не собираю на коленке данный функционал, если это какой-нить crm то проще поставить maestro).
Всякие модули галерей, слайдеров и прочих финтиплюшек идут в треш автоматически, ибо их функционал можно заменить небольшим кастомным кодом. Ведь один хрен каждый из них придётся подгонять под себя, делать темизацию...
Так каков всё-таки drupalWay? Я поступаю правильно или всё же я еретик, и чем больше модулей установлено в проекте, тем он считается круче?

Комментарии

Аватар пользователя adubovskoy adubovskoy 10 декабря 2012 в 13:40

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

Аватар пользователя Antoniy Antoniy 10 декабря 2012 в 14:42

Иногда да, проще прикрутить что-нибудь ручками.. Тем более, если более менее подходящего модуля нет.

"Crea" wrote:
много друпалеров не являются программистами

И кстати даже по этой причине иногда проще прикрутить ручками, если модуль писать не умеешь. Вот недавно прикрутил ajax калькулятор для webform, а коды в Гугле нарыл и адаптировал.. но еще допиливать надо.

Аватар пользователя gorr gorr 10 декабря 2012 в 15:06

Разработчики друпал решили, что будут делать свою систему, как одновременно и CMS и фреймворк. Соответственно оба подхода являются друпалвей, Crea тут прав.
У пользователей, не программистов просто нет выбора, они используют то, что доступно, либо заказывают у программистов новый модуль.
Для программистов все несколько иначе - если есть полностью подходящее решение на друпал.орг, то конечно надо использовать его. Если же оно не удовлетворительно, то либо допиливать его и слать патчи разработчикам, либо делать свое решение.
Быстрые решения в лоб сначала хороши, но если занимаешься поддержкой проекта и он растет, то более универсальные решения уже могут оказаться предпочтительнее.
Кроме того у разработчиков уже есть опыт работы с каким-то набором модулей, наработанные схемы, сборки, которые ускоряют разработку на стандартных решениях и время разработки на таких решениях оказывается примерно таким же, как написание пары строк кода.
Еще есть разные требования по производительности и тут возможно нужно отказаться от использования каких-то модулей, которые в противном случае можно использовать, если это существенно экономит время разработчика и средства заказчика.

И так можно долго рассуждать, но в итоге, как говорят по-англицки it all depends.

Аватар пользователя Crea Crea 10 декабря 2012 в 15:20

Quote:
Быстрые решения в лоб сначала хороши, но если занимаешься поддержкой проекта и он растет, то более универсальные решения уже могут оказаться предпочтительнее.

Наоборот. Кастомное решение более простое и снижает издержки на поддержку.

Аватар пользователя adubovskoy adubovskoy 10 декабря 2012 в 16:33

"Crea" wrote:
Наоборот. Кастомное решение более простое и снижает издержки на поддержку.

Контр-пример: в 90% случаев через год существования проекта, переопределение темизации в tpl.php сложнее и дороже поддерживать, чем то же самое, через ds и panels. У меня есть выборка сайтов, количественно это статистически значимые уже результаты, минимум по 30 сайтов с обеими вариантами реализации.
Контр-контр-пример: визуальный вывод слайдеров, галереи и т.п. проще поддерживать когда это views+js plugin, нежели модуль с d.org, включающий в себя этот js плагин и настройки вывода.

Аватар пользователя Crea Crea 10 декабря 2012 в 17:07

adubovskoy wrote:
"Crea" wrote:
Наоборот. Кастомное решение более простое и снижает издержки на поддержку.

Контр-пример: в 90% случаев через год существования проекта, переопределение темизации в tpl.php сложнее и дороже поддерживать, чем то же самое, через ds и panels. У меня есть выборка сайтов, количественно это статистически значимые уже результаты, минимум по 30 сайтов с обеими вариантами реализации.

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

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

Аватар пользователя q2_faith q2_faith 10 декабря 2012 в 16:36

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

Аватар пользователя Crea Crea 10 декабря 2012 в 17:17

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

Нелюбовь к чужому коду у программстов - явление известное. Проблема в том, что модуль с drupal.org - это тоже чужой код.
Считается, будто решение с Drupal.org позволяет не заботиться о его внутренностях. А заглянешь в код и волосы становятся дыбом.
Мое мнение - это обычный самообман. Модули с drupal.org позволяют только разным специалистам говорить на одном языке. Они не обеспечивают снижение издержек автоматически, если только у вас проект не функционирует в стиле цыганского табора - когда над ним работают постоянно новые разработчики. Но это бы означало, что у вас уже большие проблемы.
Здесь все, как обычно, упирается в прокладку между стулом и монитором. Если свой модуль написан экспертом, он будет гораздо проще, надежнее и сэкономит кучу нервов. И по качеству будет лучше 90% говна с Drupal.org

Аватар пользователя q2_faith q2_faith 10 декабря 2012 в 17:17

"ХулиGUN" wrote:
Решение: 2 вьюхи (одна с просмотренными, другая без) выводим на одной странице, кастомный модуль с hook_menu() где в калбеке вьюха 2 и js который апдейтит только 2 вьюху + функция отметки просмотра сущности и переноса элемента в 1 вьюху
Итог: 20-30 строчек кода в общем зачёте(.info + .module + .js). максимум час на реализацию всего функционала(без html)

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

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

q2_faith wrote:

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

Вьюху. экспортированную в код, не удалить через интерфейс. Палитесь Wink

Аватар пользователя q2_faith q2_faith 10 декабря 2012 в 17:24

"Crea" wrote:
Если свой модуль написан экспертом, он будет гораздо проще, надежнее и сэкономит кучу нервов.

не всем же заказчикам так везет и они нанимают вас. по качеству 90% кастомных решений это гавно(по опыту работы с амер.сайтами, но с российскими ситуация похуже будет).
по крайней мере на д.орг ревизию кода сделают, плюс багрепорты. правда ревизия не касается "старых" модулей, а там иногда попадаются "шедевры"

Аватар пользователя Crea Crea 10 декабря 2012 в 17:35

Я про себя не говорю Smile Я себя вообще программистом (в классическом понимании) не считаю..

Quote:
по качеству 90% кастомных решений это гавно

На Drupal.org тоже кастомные решения Smile Про баг репорты читать смешно, знаете какой процент пользователей их шлет ? Smile

Ну вот возьмем простую задачу - хлебные крошки. Простейший модуль, задающий хлебные крошки через drupal_set_breadcrumb() в разных хуках, в 10 раз проще и надежнее, чем использование Custom Breadcrumbs + борьба с ним.
То же самое - метатеги. Запихать несколько строчек в head - у меня это вышло на 2 страницы кода. Сравните с Nodewords (Metatags в 7). Вдобавок, при копании в коде Nodewords обнаружил дыру безопасности.

Аватар пользователя Crea Crea 10 декабря 2012 в 17:42

Самое главное - свой модуль на 100% соответствует задаче. А большинство модулей Друпала это каша из топора. Изначально кажется, будето они способны справиться с задачей, а позднее постоянно натыкаешься на баги, невозможность реализации тех или иных фич. И вот уже разработчик, вместо того, чтобы работать над своей задачей, исправляет чужой модуль.
И на эту кашу из топора все попадаются Smile

Аватар пользователя q2_faith q2_faith 10 декабря 2012 в 17:57

"ХулиGUN" wrote:
Если сайт в последствии обслуживается у нас, я никогда не даю заказчику админский доступ, делаю ему юзера, с набором необходимых прав и доступом к страницам(это отдельная тема)
Если клиент не хочет оставлять сайт у нас на обслуживании, я ему так же даю 2 юзеров и говорю, что в 1 варианте он ничего не испортит, во втором может испортить и это будут уже его трудности. Это как с любой купленой вещью - есть гарантия, пока ты не начал самостоятельно её разбирать

я всего лишь намекнул на слабое место в модуле, которое может нарушить работу сайта.

Аватар пользователя q2_faith q2_faith 10 декабря 2012 в 19:02

"Crea" wrote:
Вьюху. экспортированную в код, не удалить через интерфейс. Палитесь ;)

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

Аватар пользователя Crea Crea 10 декабря 2012 в 19:12

q2_faith wrote:

я нигде не прочитал про программно созданную вьюху Wink и с галереей тоже самое, пресеты программно создаете? ;)

Создавать программно не обязательно. достаточно экпортировать. Я к тому, что держать в коде - как бы бест практис Wink

Аватар пользователя q2_faith q2_faith 10 декабря 2012 в 19:45

"Crea" wrote:
Я к тому, что держать в коде - как бы бест практис ;)

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

Аватар пользователя Plazik Plazik 10 декабря 2012 в 20:52

"Crea" wrote:
- в своем модуле меньше кода, меньше дыр, легко найти конкретный кусок кода, если нужно что-то исправить
- в чужом модуле на 145% больше кода, причем абсолютно ненужного, говнокод, непродуманная архитектура, куча багов включая дыры безопасности, регрессии в новых версиях (бесит)

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

P.S. Я в последнее время перешел на повсеместное применение модулей с drupal.org Smile

Аватар пользователя Crea Crea 10 декабря 2012 в 21:28

Разумеется, результат в любом случае зависит от квалификации исполнителя. Я описываю ситуацию только с точки зрения программиста, знакомого с best practice разработки под Drupal.

Quote:
есть поддержка

Крайне редкое явление. Мои тикеты очень часто получают ответ через год. Бесплатная поддержка, ну это примерно, как бесплатный сыр...:)

Quote:

и обновления.

Это недостаток, а не достоинство. Вернее, хорошо, когда баги исправляют, но лучше бы их не было с самого начала. И часто вместе с багфиксом присылают новые функции (которые чаще всего не нужны) и сломанные старые. В итоге, получается, потратил кучу сил на обновление, чтобы просто сохранить то, что уже и так работало.

Гораздо проще 1 раз написать простой модуль, проверить его код + по желанию покрыть тестами. И никаких обновлений не нужно. Не нужно исправлять то, что и так работает.

Аватар пользователя Geldora Geldora 10 декабря 2012 в 23:13

Все зависит. Все зависит от ваших ответов на следующие вопросы:

- вы программист (способны ли написать модуль/разобраться в жаваскриптах и т.п.) или нет? Я, например, не способна.

- вы делаете сайт для себя или на заказ? У меня - собственный проект.

- рассчитываете ли вы, что ваш проект продержится более года? собираетесь ли вы продолжать его поддержку в эом случае? Моему основному сайту - уже 6 лет (апдейт с 5 - 6 - 7), другим - от 3х до года. Я рассчиываю, что все мои проекты как минимум будут портированы на 8ку.

В общем и целом, неважно, делаете ли вы сайт на заказ или "для себя", лучше предпочитать наиболее универсальное решение. Универсальное = такое, которое можно в любой момент изменить. Скажем, любые операции с выборками (лучшие/похожие/топ статьи и т.п.) ДОЛЖНЫ решаться через вьювс. Потмоу что вы, или ваш заказчик, должен иметь возможность в любой момент поменять условие выборки. Если вы сами поддерживаете свой сайт, то вы оцените преимущества вьювса после... скажем, полутора лет поддержки, когда вам придется проводить большой апгрейд, или когда вам захочется поменять тему... Если вы работаете только под заказ, то должны подумать о том, что ваш заказчик может нанять незнакомого с вашим кодом специалиста. Со вьювсом смогут разобраться все. Конечно, если вы работаете через вьювс, то дальше можно использовать все возможности темизации, чтобы навесить любую "обертку" выборки, какая вам захочется: цсс, жс и т.п.

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

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

И то и то - незаменимо для мультисайтинговвых инсталляций.

- Многие пишут, мол, зачем нам модуль Аналитикс - можно же код вставить в шаблон... НО! Модуль и код кэширует, и дает +100 доп.настроек и возможностей (например, отслеживание 404 страниц) и главное - при изменении шаблона вы не теряете статистику (у меня потерялось примерно 4 дня Яндекс Метрики).

- Вы приводили пример Скролл то Топ и пишите, что мол, проще вставить в шаблон. Так-то оно так... но если меняется шаблон?

- Пример с Метатегами вообще неудачный. Я не знаю, есть ли возможность генерировать в шаблоне метатеги на большой, эдак с 10 000 страниц вебсайт... Конечно, если у вас одностраничник... то вариант с шаблоном может быть оправдан.

И так далее и так далее.

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

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

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

Аватар пользователя Crea Crea 11 декабря 2012 в 0:18

Geldora,
Про метатеги вы неправильно поняли. Конечно, записывать их напрямую в шаблоне невозможно, т.к. они динамические. Я писал о своем модуле, который делает все что нужно (description + keywords + robots), при этом не имеет интерфейса. Кода там всего на пару страничек, так что багам и дырам взяться неоткуда.
Такой модуль сразу содержит все нужные данные в коде, значит для изменения настроек модуля не нужно эти настройки из базы дополнительно экспортировать в код - они там уже лежат Smile И для выкатывания новых настроек просто на сервер выкладывается новый код модуля.
Разумеется, это вариант для программиста. Это принципиально другой подход к разработке Друпал сайтов, где Друпал чаще используется как фреймворк.
При этом, Nodewords - классический вариант говнокода.

Quote:
В общем и целом, неважно, делаете ли вы сайт на заказ или "для себя", лучше предпочитать наиболее универсальное решение. Универсальное = такое, которое можно в любой момент изменить.

Не согласен. Изменять нужно только то, что требует замены - исходить надо из задачи. Сама по себе возможность изменить что-то не ценна.
Максимальная универсальность - это многочисленные абстракции, которые имеют огромную цену. Не удивляйтесь потом, когда сайт загружается несколько секунд - это все оттуда.
Каждая новая абстракция должна быть обоснована, прежде чем оказаться внедренной. Views, как такая абстракция, давно доказал свою обоснованность. Такие модули, как Views, Panels - образуют основу Друпала. Если рассматривать отказ от таких модулей в пользу самописных модулей, у меня возникает вопрос "а зачем тогда вообще здесь Друпал используется".

Совсем другая ситуация с "утилити", как вы сказали, модулями. Чаще всего, они действительно могут быть заменены своим модулем. Но я еще при оценке смотрю ответы на такие вопросы:
1) решает ли модуль только одну задачу
2) делает ли он это хорошо - тут смотрю и на качество кода, и на настройки, и на объем кода
Если на оба вопроса ответ "да" то ничего страшного в таком модуле нет. Чаще всего из "утилити" модуле попадаются такие, которые со своей задачей справляются крайне плохо. Например, модуль внедряет какой-то сторонний плагин, но не поддерживает все настройки этого плагина. При этом вам эти настройки нужны. Итого имеем модуль, который мало того, что не решает свою задачу полноценно, он еще становится у вас на пути - ведь для добавления недостающих настроек плагина вам уже нужно разбираться в коде этого модуля и править его. Т.е. лишняя, вредная абстракция. Соотв-но возникает вопрос, а стоила ли овчинка выделки с самого начала ? В большинстве случаев, для разработчика ответ - "нет".

Аватар пользователя Geldora Geldora 11 декабря 2012 в 0:16

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

Cогласна, просто выразилась неправильно Lol

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

Еще я забыла важный момент: нужно использовать те модули, которые более-менее имеют историю + достаточно абстрактные и универсальные. Потому что - хоть это и сложно предугадать - но проект типа вьювса имеет меньше шансов загнуться, чем супер-легкий модуль выборки нод опрделенного типа... Конечно, сложно предугадать что и когда загнется: пример Ивентса из 5ки, или Фююжн-темы с 6ки - это доказывают. Но все равно, чем больше пользователей = тем меньше шанс, что не прекратится проект = возможность малых и больших апгредов

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

"Crea" wrote:
Я писал о своем модуле, который делает все что нужно (description + keywords + robots), при этом не имеет интерфейса

(Оффтоп) А выложить для страждущих? Wink В друпале вообще проблема с метатегами, хоть в 6к (нодвордс - ГОВНОкод!!) что в 7ке, с его Метэгом недоделаным Sad

Аватар пользователя Crea Crea 11 декабря 2012 в 0:33

Geldora wrote:

Еще я забыла важный момент: нужно использовать те модули, которые более-менее имеют историю + достаточно абстрактные и универсальные. Потому что - хоть это и сложно предугадать - но проект типа вьювса имеет меньше шансов загнуться, чем супер-легкий модуль выборки нод опрделенного типа... Конечно, сложно предугадать что и когда загнется: пример Ивентса из 5ки, или Фююжн-темы с 6ки - это доказывают. Но все равно, чем больше пользователей = тем меньше шанс, что не прекратится проект = возможность малых и больших апгредов

Вы рассуждаете как пользователь. Как разработчик могу сказать абстракции - зло Smile

Geldora wrote:

И последнее. Я удивлена, что другие программисты раньше не написали: но ведь работа с .орговскими модулями - выгоднее самописа!!! И скорость разработки, и стоимость поддержки, и даже последующих обновлений

Это не является абсолютной истиной. Все зависит от конкретной задачи. Написать маленький модуль, на 100% выполняющий задачу может быть гораздо дешевле, чем адаптировать гигантский универсальный модуль.
Если вы посмотрите выше, я все это обсуждал. И про поддержку, и про обновления.

Geldora wrote:

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

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

Geldora wrote:

(Оффтоп) А выложить для страждущих? Wink

Смысла не имеет. Модуль максимально привязан к сайту.

Аватар пользователя Geldora Geldora 11 декабря 2012 в 0:21

"Crea" wrote:
при оценке смотрю ответы на такие вопросы:
1) решает ли модуль только одну задачу
2) делает ли он это хорошо - тут смотрю и на качество кода, и на настройки, и на объем кода

Хорошая оценка. Буду использовать Smile

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

Аватар пользователя sas@drupal.org sas@drupal.org 11 декабря 2012 в 0:25

Лучше то, что работает быстрее и спокойно переносит обновление core Drupal, это может быть и модуль в одном случае и код в другом.

Аватар пользователя Geldora Geldora 11 декабря 2012 в 0:45

"Crea" wrote:
Для владельца же - проект пишется один раз, и поддерживается много лет. Универсальность ему ни к чему (за исключением действительно необходимых настроек, согласно ТЗ)

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

Вот, чтобы далеко не ходить за примером: сегодня обсуждали с моим парнером переделку главной страницы. Обсуждался в частности вариант: в слайдере вместо нод выводить термины таксономии. Поскольку это вьювс - сделать такое изменение я смогу. Была бы выборка напрямую с базы - я бы такое не смогла изменить без фрилансера. В общем, вот это, как по мне, "универсальность" и "изменяемость" Smile

Аватар пользователя Crea Crea 11 декабря 2012 в 1:41

Недавний пример отказа от "универсального" модуля.
Использовал модуль Google Ad Manager долгое время. Недавно обновился до 3.х, чтобы использовать Google Publisher Tags. Оказалось, в новой ветке регрессия - нет возможности изменить вывод рекламного кода через фунцию темизации. Плюс, потребовалось привязать слоты GPT к каналам Adsense, а это делается через JS и этой функции в модуле нет.
Заменил все своим модулем. Итог: свой модуль в разы меньше по кол-ву кода. Все функции GPT поддерживаются, нет ненужной привязки к UI модуля. Все работает так, как мне надо. Нет зависимости от чужого кода - замечательно. И обновлять не нужно! Smile
Реализовать поддержку нужных мне функций в универсальном модуле Google Ad Manager было бы гораздо лучше для сообщества в целом, но лично для меня слишком дорого и долго.

Аватар пользователя Chyvakoff Chyvakoff 11 декабря 2012 в 9:03

Если набьете сайт самописными модулями, то при переходе на семерку или восьмерку придется все самим переписывать.
В случае использования орговских модулей этого скорей всего не будет.

Аватар пользователя Crea Crea 11 декабря 2012 в 10:13

Chyvakoff wrote:
Если набьете сайт самописными модулями, то при переходе на семерку или восьмерку придется все самим переписывать.
В случае использования орговских модулей этого скорей всего не будет.

Начнем с того, что не для всех сайтов апгрейд вообще экономически целесообразен. Если сайт продвинутый, на нем всегда используется свой кастомный код, и зачастую очень много такого кода. Переносить такой код - очень дорогое удовольствие. Гораздо выгоднее может быть самостоятельно провести аудит безопасности своих модулей и заморозить версию Друпала у себя на много лет вперед.
Без проблем обновляются только самые простые сайты, использующие самые популярные модули, причем минимальное кол-во. Если у вас на сайте 150+ модулей с орга, так же придется их самому переписывать или заменять своими модулями при апгрейде.
Куча модулей до сих пор не портирована на 7, то же самое будет и с в 8, скорее всего.

Аватар пользователя sas@drupal.org sas@drupal.org 11 декабря 2012 в 10:44

"Geldora" wrote:
Поскольку это вьювс - сделать такое изменение я смогу. Была бы выборка напрямую с базы - я бы такое не смогла изменить без фрилансера. В общем, вот это, как по мне, "универсальность" и "изменяемость" :)

За это приходится платить ресурсами на хосте - а за них вы платите ежемесячно, так как "заточеное решения" "кушает" меньше ресурсов, если конечно оно хорошо сделано Smile

Аватар пользователя sas@drupal.org sas@drupal.org 11 декабря 2012 в 10:48

"ХулиGUN" wrote:
либо писать своё, либо перепиливать уже имеющееся

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

Аватар пользователя sas@drupal.org sas@drupal.org 11 декабря 2012 в 11:15

Есть функциональность, которой нет в core (например как Вы правильно заметили commerce) - ее надо ставить, если это экономит время разработки, деньги клиента и работает быстро, а вот например views - стоит ставить для простых выборок, если же речь идет о сложной выборке - он Вам такой "оптимальный" запрос напишет - что "ну его лесом ..." ( не зря его в core до сих пор не включили )? c другой стороны - страница со списком /node чуть ли не 20 строк код всего Smile - т.е. way делать в конкретном случае разный - со знаем дела и думая головой. Ну вот умный человек - все понимаете

Аватар пользователя q2_faith q2_faith 11 декабря 2012 в 12:23

"Crea" wrote:
Без проблем обновляются только самые простые сайты, использующие самые популярные модули, причем минимальное кол-во. Если у вас на сайте 150+ модулей с орга, так же придется их самому переписывать или заменять своими модулями при апгрейде.

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

Аватар пользователя Crea Crea 11 декабря 2012 в 12:47

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

Я правильно понимаю, что вы своим заказчикам ставите Nodewords вместо своего модуля для метатегов ?

Еще раз, все зависит от задачи. Если для решения задачи изначально лучше свои модули, то их и нужно использовать.
Что лучше для решения задачи должен решать в каждом конкретном случае основной разработчик проекта совместно с владельцем проекта.

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

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

Аватар пользователя q2_faith q2_faith 11 декабря 2012 в 12:50

"Crea" wrote:
Еще раз, все зависит от задачи. Если для решения задачи изначально лучше свои модули, то их и нужно использовать.

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

Аватар пользователя Crea Crea 11 декабря 2012 в 13:01

q2_faith wrote:

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

Если модуль с drupal.org - говно - это тоже для клиента хорошо ? Вы наверное и в код используемых модулей не заглядываете ? Smile
Разработка дешевле, если модуль выполняет задачу на 100%. А если требуется доработка - это еще не известно, что лучше - написать свой маленький модуль или патчить большой универсальный с drupal.org

q2_faith wrote:
использовать друпал как фреймворк для сайта - каталога продукции, экономически не целесообразно.

Я соглашусь про визитки и каталоги. Но даже интернет-магазин это уже продвинутый сайт, где ваше утверждение не всегда верно.

Аватар пользователя q2_faith q2_faith 11 декабря 2012 в 13:14

"Crea" wrote:
Если модуль с drupal.org - говно - это тоже для клиента хорошо ? Вы наверное и в код используемых модулей не заглядываете ? Smile
Разработка дешевле, если модуль выполняет задачу на 100%. А если требуется доработка - это еще не известно, что лучше - написать свой маленький модуль или патчить большой универсальный с drupal.org

давайте обобщать) каков, по вашему мнению, процент гавномодулей на д.орг и каков процент гавнокодеров среди фрилансеров?

Аватар пользователя adubovskoy adubovskoy 11 декабря 2012 в 13:25

"Crea" wrote:
про фрилансеров не скажу, а говномодулей на d.org намного больше 50%

Может с примерами?) Любой из популярных модулей на drupal.org и самописный модуль с схожим функционалом (на гитхаб например выложить). А то что мы тут обсуждаем, без примеров то. Не верю)) А так сравним, порадуемся)

Аватар пользователя adubovskoy adubovskoy 11 декабря 2012 в 13:40

"Crea" wrote:
пример с Nodewords был выше.

А я его не понял. Я вообще не понимаю определения "плохой". Понимаю "хуже чем". Вот хуже чем что - мне не показали. Покажите код, который делает то же, но лучше и красивей. Зачем прятать от сообщества?

Аватар пользователя Crea Crea 11 декабря 2012 в 13:53

adubovskoy wrote:
"Crea" wrote:
пример с Nodewords был выше.

А я его не понял. Я вообще не понимаю определения "плохой". Понимаю "хуже чем". Вот хуже чем что - мне не показали. Покажите код, который делает то же, но лучше и красивей. Зачем прятать от сообщества?

Что там показывать - маленький модуль, который делает hook_preprocess_page() и вставляет нужные метатеги в head.
Недостатки Nodewords - гигантский уродливый интерфейс, кривое API, низкокачественный код (как пример - дыра в безопасности). В общем, куча говнокода, чтобы всего лишь вставить несколько строчек на страницу.

Аватар пользователя adubovskoy adubovskoy 11 декабря 2012 в 13:55

"Crea" wrote:
Что там показывать - маленький модуль, который делает hook_preprocess_page() и вставляет нужные метатеги в head.

А вы все-таки покажите, не стесняйтесь) А мы потом возьмем стороннего друпал-разработчика и спросим сколько времени у него ушло вставить-понять как с этим работать, сравним по скорости вхождения с nodewords, да и на сам код и комментарии хорошо будет посмотреть. В общем - пока все еще сравнивать нечего, а определения "плохой" без примеров не бывает.

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

Аватар пользователя Crea Crea 11 декабря 2012 в 14:06

Я бы мог написать подробное объяснение, почему Nodewords - говно. Только мой труд не будет оплачен, поэтому уж извините, распинаться не собираюсь.
Это серьезная работа.
А показывать код своего сайта - зачем ? Это конфиденциальная информация. Я уже объяснил, что это всего 2 страницы простейшего кода. Если разработчик неспособен в них разобраться - гнать надо такого разработчика.

Может, вы хотите сказать, что другому разработчику будет проще разобраться в коде Nodewords, чем в моем модуле ? Или вы считаете, что разработчик это тот, кто только нажимает кнопки в интерфейсе ? Smile

Аватар пользователя adubovskoy adubovskoy 11 декабря 2012 в 14:44

"Crea" wrote:
Если разработчик неспособен в них разобраться - гнать надо такого разработчика.

Да я в обещем согласен с вашими доводами. Просто потому что они вами произнесены - в этом контектсе они справедливы. А вот если php-разработчик, не до конца разобравшийся с друпалом, начнет идти путем "лучше написать свое" - то начинаются и mysql query в теме и хаки ядра... Т.е. вы пропогандируете "свое писать лучше", при этом вы уже "собаку съели" на drupal api и архитектуре. А к вашим словам могут прислушаться совсем другие люди. Вам же потом расхлебывать, мы все видели такие сайты)

Аватар пользователя Crea Crea 11 декабря 2012 в 14:54

adubovskoy,
я выше писал, что все всегда упирается в конечного исполнителя. Модули с drupal.org хоть и дают некоторую защиту, но не панацея от отсутствия квалификации. Да и хороший модуль с drupal.org можно внедрить через жопу. Делов то..
Мне кажется это очередной миф, что можно нанять индусов/школьников, дать им хороший инструмент (Друпал) и получить на выходе хороший результат. Везде, где серьезный подход к разработке, за джуниорами присматривает синьор. И это его задача следить, чтобы не было "mysql query в теме и хаки ядра".

Аватар пользователя gorr gorr 11 декабря 2012 в 15:12

"<a href="mailto:sas@drupal.org">sas@drupal.org</a>" wrote:
например views - стоит ставить для простых выборок, если же речь идет о сложной выборке - он Вам такой "оптимальный" запрос напишет - что "ну его лесом ..." ( не зря его в core до сих пор не включили )?

В 8 друпале уже в ядре.
И насколько я понял, админ-страницы управления содержимым сайта будут сделаны с помощью вьюза.

Постепенно переводим тему в "Друпал вей для друпал-8"! Smile

Аватар пользователя sas@drupal.org sas@drupal.org 10 ноября 2015 в 11:48

gorr wrote:
"<a href="mailto:sas@drupal.org">sas@drupal.org</a>" wrote:
например views - стоит ставить для простых выборок, если же речь идет о сложной выборке - он Вам такой "оптимальный" запрос напишет - что "ну его лесом ..." ( не зря его в core до сих пор не включили )?

В 8 друпале уже в ядре.
И насколько я понял, админ-страницы управления содержимым сайта будут сделаны с помощью вьюза.

Постепенно переводим тему в "Друпал вей для друпал-8"! :)


Ой... подождем лета

Аватар пользователя q2_faith q2_faith 11 декабря 2012 в 15:13

"Crea" wrote:
И это его задача следить, чтобы не было "mysql query в теме и хаки ядра".

а кто за фрилансером проследит?) на д.орг хоть какая то защита...

Аватар пользователя Crea Crea 11 декабря 2012 в 15:21

q2_faith,
А кто проследит, чтобы модуль с d.org был качественный, был правильно настроен и внедрен ? Кто помешает джуниору нагадить в шаблоне или template.php ?
Это личная половая трудность заказчика - выбрать грамотного исполнителя. Дяди с drupal.org ему в этом не помогут ))

Аватар пользователя gorr gorr 11 декабря 2012 в 15:38

Давайте пойдем от обратного - что такое не друпал вей.
Для меня, и это то, с чем лично сталкивался при доработке проектов - самописный код в теме или модуле, который не следует стандартам кодирования друпал:

1) Хаки в ядре
2) Не разделенные логика и представление (sql запросы в шаблонах и подобное)
3) Когда вместо использования api друпала пишут формы, при этом не заботясь о валидации, очистке данных и т.д. (видел как такой код насовали с помощью php filter в ноды в большом количестве)

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

Аватар пользователя q2_faith q2_faith 11 декабря 2012 в 16:31

Crea,
если разработчик криво внедряет модуль с д.орг, то мне страшно представить, как будет выглядеть его кастомный модуль)
p.s. если к вашему кастомному модулю прикрутить админку и прочие фишки нодвордс, будет в нем меньше багов?

Аватар пользователя Crea Crea 11 декабря 2012 в 17:13

Quote:
если разработчик криво внедряет модуль с д.орг, то мне страшно представить, как будет выглядеть его кастомный модуль)

Мне такие рассуждения представляются бессмысленными. Какая разница - в итоге, все равно получится говно )))

Quote:
если к вашему кастомному модулю прикрутить админку и прочие фишки нодвордс, будет в нем меньше багов?

Зависит от количества фишек и того, кто будет прикручивать. В любом случае, кол-во багов обычно пропорционально объему кода, при прочих равних, а в кастомном модуле кода меньше. Nodewords поддерживает кучу никому не нужных метатегов, например.

Quote:
и последнее. я думаю само развитие друпала зависит от использования модулей с д.орг

Заказчика это не интересует, обычно, что в принципе логично. Нечего перекладывать с больной головы на здоровую ))

Я понимаю, куда вы все клоните, что модули с drupal.org в среднем лучше, чем то, что напишет средний разработчик. Мне это утверждение представляется весьма сомнительным, т.к. на Drupal.org проверяется только первый модуль разработчика при регистрации. Дальше он может клепать говномодули пачками.

Самое интересное начинается, когда модуль с drupal.org не справляется с задачей на 100%.

Аватар пользователя q2_faith q2_faith 11 декабря 2012 в 17:41

"Crea" wrote:
Заказчика это не интересует, обычно, что в принципе логично. Нечего перекладывать с больной головы на здоровую ))

а если по времени одинаково или пофиксить баг, выкатить патч и использовать модуль с д.орг, или написать свой велосипед, то какой вариант вы выберите и каким боком тут фигурирует заказчик?)

Аватар пользователя q2_faith q2_faith 11 декабря 2012 в 17:43

"ХулиGUN" wrote:
З.Ы. Где гарантия. что при апдейте любого модуля с орга (не входящего в ядро) не отвалятся остальные, от него зависящие?

а у кастомного решения есть гарантия?

Аватар пользователя Crea Crea 11 декабря 2012 в 17:57

q2_faith wrote:
"ХулиGUN" wrote:
З.Ы. Где гарантия. что при апдейте любого модуля с орга (не входящего в ядро) не отвалятся остальные, от него зависящие?

а у кастомного решения есть гарантия?

Гарантию тока в морге дают Smile
Какая гарантия вам нужна ? Почитайте GPL

Аватар пользователя q2_faith q2_faith 11 декабря 2012 в 17:51

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

Аватар пользователя Crea Crea 11 декабря 2012 в 17:57

q2_faith wrote:
"Crea" wrote:
Заказчика это не интересует, обычно, что в принципе логично. Нечего перекладывать с больной головы на здоровую ))

а если по времени одинаково или пофиксить баг, выкатить патч и использовать модуль с д.орг, или написать свой велосипед, то какой вариант вы выберите и каким боком тут фигурирует заказчик?)

При прочих равных конечно лучше модуль с d.org.
Но еще нужно смотреть на общую статистику багов. Если модуль проблемный, и требует внимания не первый раз, стоит задуматься о его замене на кастом.
Вообще, по-хорошему, нужно проводить ревизию всех используемых модулей. Хотя бы мельком пробежать глазами.

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

Аватар пользователя Orion76 Orion76 11 декабря 2012 в 18:09

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

Аватар пользователя q2_faith q2_faith 11 декабря 2012 в 18:11

"Crea" wrote:
Какая гарантия вам нужна ? Почитайте GPL

это к ТС
"ХулиGUN" wrote:
Если в своём модуле ты используешь api модуля который ты решил проапдейтить, то перед апдейтом так же можно почитать changelog и исправить пару строк в своём коде при необходимости.

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

Аватар пользователя sg85 sg85 11 декабря 2012 в 18:34

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

Не совсем верно, реальный пример: для 6й ветки нужно было сделать одну довольно сложную выборку(вложенный запрос), штатно вьювс уходил в таймаут(обратное было бы удивительным), решил сперва заменить его своим модулем, но потом захотелось просто добавить пару тройку хендлеров для вьювс, добился правильно построенного запроса, кода получилось примерно в 10 раз больше(не важно, что там обычное тупое описание хендлеров, где не нужно думать), чем было бы своим модулем, однако, несколько раз потом приходилось этот самый вьювс перестраивать, что оказалось весьма удобным и можно сказать, себя окупило(ибо вспоминать структуру БД, для перестроения запроса, через пол года несколько лениво), но тут настало время апгрейда до 7... в общем решил забить болт и сделать самопис.

Суть выше написанного: вьювс может выполнять сколь угодно сложные запросы, однако, "научить" его такому будет значительно дороже самописа(по принципу время\деньги), и единственный выигрыш от этого, как сказала бы Geldora, универсальность.

Аватар пользователя Plazik Plazik 11 декабря 2012 в 19:33

Мне кажется друпалвей - это универсальные модули, управляемые из админки, это как раз главное отличие друпала от других систем.

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

ИМХО, интернет и сайты развиваются постоянно и если заморозить их развитие, то можно отстать на долго. Выходят новые версии PHP, старый сайт с ними бывает не корректно работает, появляются новые тенденции и т.д.
"Crea" wrote:
При этом, Nodewords - классический вариант говнокода.

ИМХО, не корректно сравнивать универсальный модуль и простой модуль из 10 строчек. В простом модуле понятное дело меньше мест, где совершить ошибки и на говнокодить. И если уж Nodewords совсем плохой и ваш модуль справляется с его задачами, почему бы не оформить эти строчки в модуль и не выложить на d.org. Наверно многие тоже возмущались Nodewords, но не могли написать альтернативу.

Аватар пользователя Crea Crea 11 декабря 2012 в 20:34

Plazik wrote:

ИМХО, интернет и сайты развиваются постоянно и если заморозить их развитие, то можно отстать на долго. Выходят новые версии PHP, старый сайт с ними бывает не корректно работает, появляются новые тенденции и т.д.

Смена версии php - событие значимое и оно не совершается каждый день. Ничего не мешает проверить весь код на совмесимость перед переходом. Для модуля с Drupal.org так же нет никаких гарантий, что он будет всегда работать.
Постоянно обновлять такой софт - значит искать лишние приключения на свою задницу, вместо того, чтобы уделять внимание тому, что дейстительно важно - развитию проекта.
Вы, возможно, не знаете, как разрабатываются и поддерживаются серьезные сайты. Там действует правило "работает - не трогай" и за такую самодеятельность наказывают Smile

Plazik wrote:

ИМХО, не корректно сравнивать универсальный модуль и простой модуль из 10 строчек. В простом модуле понятное дело меньше мест, где совершить ошибки и на говнокодить. И если уж Nodewords совсем плохой и ваш модуль справляется с его задачами, почему бы не оформить эти строчки в модуль и не выложить на d.org.
Наверно многие тоже возмущались Nodewords, но не могли написать альтернативу.

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

Аватар пользователя sg85 sg85 11 декабря 2012 в 20:20

"Plazik" wrote:
ИМХО, интернет и сайты развиваются постоянно и если заморозить их развитие, то можно отстать на долго. Выходят новые версии PHP, старый сайт с ними бывает не корректно работает,

обычно сайты замораживаются вместе с серверным ПО, например, стоит у вас debian lenny и пофиг, что давно PHP 5.4 вышел, а новые тенденции обычно не столь критичны.
"Plazik" wrote:
почему бы не оформить эти строчки в модуль и не выложить на d.org.

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

Аватар пользователя Plazik Plazik 11 декабря 2012 в 20:39

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

Вот я про это и говорю. Вот пример такого модуля http://drupal.org/project/metatags_quick, появился когда еще не было под семерку модуля http://drupal.org/project/metatag

Или вот модули http://drupalace.ru/reshenie-problem-s-hlebnymi-kroshkami-v-drupal-7-raz..., http://drupalace.ru/modul-po-dobavleniyu-meta-tegov-path-metatags - это не тему - автору не понравился модуль на d.org - он смог написать лучшую (по его мнению) альтернативу. Как видно, модули пользуются популярностью.

Аватар пользователя Geldora Geldora 11 декабря 2012 в 22:35

"Crea" wrote:
мой модуль еще проще, чем указанные вами.

ваш может и проще... вот только пользуетесь им именно ВЫ. Не имея весь багаэ ВАШИХ знаний, нам остается только пользоваться тем, что имеется. И извините уж, но мне больше нравится подход авторов Метатег-Квик (использую на своем проекте) и Path Breadcrumbs (ставила, пока не разобралась, но обязательно вернусь), которые дали нам возможность пользоваться их трудами.

И да. Непомню уже цитату и конкретного автора... но где-то вверху было, что мол проще заблокировать проект с 150+ модулей на многие-многие лета. Я чуть со стула не упала. Т.е. я должна была сидеть на 5ке??? При том, что даже между 6 и 7 (я уж молчу про 5 и 7) довольно большая разница, в т.ч. по производительности и предлагаемым возможностям, мне предлагают заблокировать развитие проектов??? Извиняюсь, но как мне кажется, даже фрилансер должен, просто обязан думать о перспективах проекта, о возможностях его дальнешйшего развития и т.п... Если мини-модуль блокирует развитие проекта - т.е. на него завязаны какие-то важные функции, имхо НЕТ и НЕТ таким мини-модулям. Если ваш мини-костыль делает что-то небольшое, плагины-оформление - еще ладно. Но для всего, что потенциально может приостановить развитие проекта, имхо, нужно использовать модули с .орга

Аватар пользователя Crea Crea 12 декабря 2012 в 0:53

Quote:

Т.е. я должна была сидеть на 5ке??? При том, что даже между 6 и 7 (я уж молчу про 5 и 7) довольно большая разница, в т.ч. по производительности и предлагаемым возможностям, мне предлагают заблокировать развитие проектов??? Извиняюсь, но как мне кажется, даже фрилансер должен, просто обязан думать о перспективах проекта, о возможностях его дальнешйшего развития и т.п...

Если бы ваш сайт был на D5, а вы, вместо апгрейдов занимались бы новыми функциями для ваших посетителей, ваш сайт был бы гораздо более навороченным и продвинутым.
Да, он бы использовал более примитивное API, но посетителям это не заметно. Посетители не оценят технической красоты сайта. Они видят только дизайн + функциональность.
Представим, что вы строите дом. Ядро Drupal и его API - это фундамент вашего дома. У вас есть выбор, строить этаж за этажом, или раз в 2-3 года все сносить, ставить новый фундамент и строить этажи заново. Если вы каждый раз все сносите, то вы никогда не сможете построить небоскреб.
Теоретически, новое API позволяет быстрее развиваться. Но на практике, существующий, работающий код всегда лучше, чем создание нового, пускай и на более совершенном API. Стоит только врем от времени проводить рефакторинг (приведение кода в порядок).
В любом случае, описанное касается только продвинутых проектов, использующих свою собственную функциональность, заложенную в своих модулях, и не доступную на drupal.org. Если вы используете только готовые модули - тут и обсуждать нечего. Это вас не касается никоим образом.
Есть много примеров подобного подхода. Например, Вебпланета долгое время, ЕМНИП, сидела на старой версии Друпала.
Aviasales в качестве веб-морды к своему сервису поиска билетов долго время использовали 5 Друпал.
В общем, заморозка - отличное средство снижения издержек.
Операционная система Redhat Enterprise Linux имеет срок поддержки 10 лет - это означает, что ее можно не переустанавливать и она продолжит работать и получать обновления. Друпалу до такого серьезного уровня еще расти и расти.

Quote:

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

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

Аватар пользователя Crea Crea 12 декабря 2012 в 10:46

q2_faith wrote:
"Crea" wrote:
Портировать такой кастомный модуль - очень легко.

а если сам заказчик захочет перенести?)

Если заказчик хочет вообще без программиста обновлять свой сайт, ему остается использовать только модули с Drupal.org. Но так бывает только на самых простых сайтах.
Мне вообще трудно представить сайт совсем без кастомного кода. Его может быть очень много хотя бы в template.php

Аватар пользователя sas@drupal.org sas@drupal.org 12 декабря 2012 в 10:38

"q2_faith" wrote:
а если сам заказчик захочет перенести?)

Значит у него появится шанс расшевелить моцг и вырасти над собой

Аватар пользователя Crea Crea 12 декабря 2012 в 11:40

<a href="mailto:sas@drupal.org">sas@drupal.org</a> wrote:
Значит у него появится шанс расшевелить моцг и вырасти над собой

Хаха )))
Я это называю друпальной "кашей из топора". Человека ведется на легкость управления сайтом без программирования, сначала вникает в абстракции и термины друпала, а потом начинает программировать Smile
Вон, Geldora уже всего на расстоянии шага от программирования Smile

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

Аватар пользователя q2_faith q2_faith 12 декабря 2012 в 12:34

"Crea" wrote:
Мне вообще трудно представить сайт совсем без кастомного кода. Его может быть очень много хотя бы в template.php

90% таких сайтов)

Аватар пользователя sg85 sg85 12 декабря 2012 в 13:48

"Crea" wrote:
Самое забавное, что многие заказчики не понимают, сколько времени и сил было бы сэкономлено, если бы техническими деталями с самого начала занимался профессиональный разработчик, а заказчик концентрировался на своем проекте ))

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

Аватар пользователя sg85 sg85 12 декабря 2012 в 14:08

"ХулиGUN" wrote:
Я тоже обожаю всяческие апдейты тз, но самой лучшей тактикой является составление нового тз на новые идеи

Я так и делаю, но, сейчас новые ТЗ умудряются приходить еще ДО того как закончу старые(по принципу:
-такое сделать возможно?
-(прочитав ТЗ по диагонали)типа того
) Wink Самое сложное - не запутаться в ТЗ, особенно, если учесть, что примерно половина из них друг друга дополняют, а то и частично перекрывают. Вроде изначально планировал за неделю не напрягаясь все сделать, получить свою несчастную тридцатку, и пропить отдыхать, а тут уже набралось на полтора месяца... А ведь "оптовикам" еще и скидка нужна))

Аватар пользователя sas@drupal.org sas@drupal.org 10 ноября 2015 в 11:48

"ХулиGUN" wrote:
DrupalWay Необходимые модули

Кстати что о этому поводу думает 8-яверсия и соответственно, что выбирает разработчик "коробки" - вносит "необходимы модули" в поставку, все остальное API для нужд использования переползает аля MVC и юзаем задумки symphony, т.е. ООП, квалификационные требования к разработчикам модулей выше, использования без доп. кода должно расти

Аватар пользователя sas@drupal.org sas@drupal.org 13 декабря 2012 в 0:35

"ХулиGUN" wrote:
html + js в чистом виде)))

Или он уже "поиспользовал в чистом виде" что-то и теперь ошибки на страницах и конфликты js - не дают ему использовать way

Аватар пользователя q2_faith q2_faith 13 декабря 2012 в 12:22

"ХулиGUN" wrote:
Не будем глубоко лезть свежий примерЧеловек штампует друпал-сайты, а тут бяда, модуль криво встал. Друпалвей не даёт ему возможности использовать html + js в чистом виде)))

я летом использовал эту связку на 6-ке, все прекрасно встало)

Аватар пользователя q2_faith q2_faith 13 декабря 2012 в 13:07

"ХулиGUN" wrote:
Здесь скорее всего идёт понимание того, что собираешься сделать и представление как это работает

то есть что будет drupalway в случае этого пациента?)

Аватар пользователя q2_faith q2_faith 13 декабря 2012 в 14:07

"ХулиGUN" wrote:
Отдать сайт специалисту)))

и обязательно хорошему специалисту, который знает апи друпала, как свои пять пальцев и наклепает кучу кастомных решений?)

Аватар пользователя q2_faith q2_faith 13 декабря 2012 в 14:52

"ХулиGUN" wrote:

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

Аватар пользователя sg85 sg85 13 декабря 2012 в 17:33

"ХулиGUN" wrote:
Я к тому, что этому что в данном примере человеку требуется тупо сделать слайдшоу. Думаю максимум, что нужно заказчику, это выбирать какой контент выводить в этом слайдшоу.

На то, что бы сделать(прикрепить) свое слайд шоу(вплоть до написания jquery плагинов), времени лично мне нужно меньше, чем найти и прикрутить готовое, однако, если мне попалось чужое творчество, у меня все равно уйдет меньше времени на разобраться в чужом коде(при условии что там не полный бардак), чем разбираться, что за модуль там используется и как он вообще работает, ибо этих модулей как собак не резаных, а так же разбираться какого лешего каруселька при генерации вывода грузит проц на 100%, честно говоря, лень.

И еще, на Drupal 7, как, наверное, многие заметили, кодить приходится значительно меньше, интересно, что будет с 8...

"ХулиGUN" wrote:
И как правило, если дать заказчику брозды правления этим слайдером, то велика вероятность, что он сам испортит свой сайт

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

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

Судя по тому, что творится на этом форуме:
В случае с квалифицированным ламером(то бишь со мной) - если модуль решает проблему на 100%, не создает лишних проблем и его не нужно переделывать(или почти не нужно, плотность хаков ~0.1% считаю вполне приемлимой) - беру на вооружение, иначе кодинг.
В случае с неквалифицированным друпалером - сойдет любой модуль, который хотя бы на 20% подходит, ТЗ переписывается под этот модуль, а если и даже такого модуля нет - тогда либо он заказывается, либо джумла, но чаще выносится мозг обитателям drupal.ru, ибо деваться просто некуда(сбрасывать заказ, каким бы он нибыл, наверное, не хочется). Заказчикам, как правило, пофиг друпал вей там или ... Им главное конечный результат.

Аватар пользователя natbampo natbampo 13 декабря 2012 в 20:50

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

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

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

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

Аватар пользователя Crea Crea 13 декабря 2012 в 21:44

sg85,
про 20% красиво сказано. Похоже на правду ))

natbampo,

Quote:
Как сказала Geldora самое главное кто кому делает сайт.

Только она это упоминала с абсолютно противоположным смыслом Smile

Аватар пользователя natbampo natbampo 14 декабря 2012 в 9:59

"Crea" wrote:
Только она это упоминала с абсолютно противоположным смыслом :)

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

Аватар пользователя MainVisor MainVisor 17 декабря 2012 в 21:15

По возможности нужно использовать:
1. Модули с д.орга
1.1. Если используем модуль, то он должен быть с "историей".
1.2. Количество модулей должно быть минимальным, без которых "никак"
2. Хардкодить только в редких случаях - исключениях.
2.1. Свой код только для вторичной функциональности проекта, без которой можно жить.

Как вам такой алгоритм?

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

Аватар пользователя Crea Crea 18 декабря 2012 в 8:55

MainVisor wrote:

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

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

Аватар пользователя sg85 sg85 17 декабря 2012 в 23:49

"MainVisor" wrote:
2.1. Свой код только для вторичной функциональности проекта, без которой можно жить.

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

"MainVisor" wrote:
Мне кажется модули сильно облегчают жизнь, и фиг с производительностью, гигабайты дешевеют.

если модуль создает загрузку процессора 100% на главной из-за кривого кода, тут уж никакое железо не спасет...

"MainVisor" wrote:
Абстрактность ускоряет прогресс, а то бы до сих пор писали на ассемблере и т.п.

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

Аватар пользователя volocuga@drupal.org volocuga@drupal.org 18 декабря 2012 в 0:49

ХулиGUN: как бы всё верно, но спор шаред или впс меня всегда убивал. Если разница в пару десятков баксов остро стоит для владельца, то очевидно, что это говнобизнес и занималься им не стоит.

Аватар пользователя q2_faith q2_faith 18 декабря 2012 в 12:16

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

Аватар пользователя q2_faith q2_faith 18 декабря 2012 в 13:32

"ХулиGUN" wrote:
Возможно и есть))) Сужу исключительно по своему опыту... Я сам из тех, что зачем писать лишний код, если есть готовое решение, но если для решения нужен ни один, ни два, а целый ряд дополнительных модулей, то считаю проще написать свои 100 строчек, чем городить из кучи хлама

Давайте поговорим более предметно) В 95% случаев, те модули, которые требуется, либо уже стоят, либо понадобятся в будущем. Обычно это token, entity_api, ctools, для различных галерей это libraries, еще может быть views. Поправьте меня, если я не прав)

Аватар пользователя q2_faith q2_faith 18 декабря 2012 в 15:21

"ХулиGUN" wrote:
Задача
Дано: Свежескачанный дистрибутив Drupal 7
Найти: Количество дополнительных модулей с орга, чтобы реализовать поле для вставки роликов с ютуба и вимео?
Информация к размышлению: Обыкновенный форматер для текстового поля занимает примерно строк 12-20

Задача
Дано: Кастомный модуль в 12-20 строк.
Найти: Разработчика, который обновит модуль, так как поменялось апи ядра.
Информация к размышлению: на д.орг уже бы выкатили патч.
Информация к информации: На сайте посещаемость 3,5 человека и он работает без включенного кэширования со всеми панелями, вьюшками, ЧПУ и т.д.

Аватар пользователя Geldora Geldora 18 декабря 2012 в 16:12

"ХулиGUN" wrote:
Задача
Дано: Свежескачанный дистрибутив Drupal 7
Найти: Количество дополнительных модулей с орга, чтобы реализовать поле для вставки роликов с ютуба и вимео?

Млин. Включить мозг и попробовать ПОИСКАТЬ. Google: Drupal 7 Vimeo Youtube

Аватар пользователя multpix multpix 18 декабря 2012 в 16:29

"Geldora" wrote:
Млин. Включить мозг и попробовать ПОИСКАТЬ. Google: Drupal 7 Vimeo Youtube

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

имхо: если задача решается своими 20ю строчками против существующего решения с хвостом зависимостей - то уж лучше свое
но с прицелом на повторное использование в дальнейшем ))

а если код с дорг - то не стесняться и долбить ишью (по существу).

Аватар пользователя Chyvakoff Chyvakoff 18 декабря 2012 в 16:59

"ХулиGUN" wrote:
Обыкновенный форматер для текстового поля занимает примерно строк 12-20

Хулиган, код форматера в студию. С указанием того, сколько минут у вас ушло на его написание.Должно быть минут 10,не больше?

Аватар пользователя natbampo natbampo 18 декабря 2012 в 17:31

Вот из книги DRUPAL: THE GUIDE TO PLANNING AND BUILDING WEBSITES (стр 34):

Quote:

Estimating Project Duration

If you have little or no experience estimating schedules, estimating project duration can be a challenge. Duration refers to the time that elapses between starting an effort and ending an effort.

You might hear that it will take 40 hours to build your site. Your first thought might be, Great, so I will have it next week, right? Not necessarily. Your time, your team’s time, and your contractor’s
availability are factors in determining the duration of your project. In other words, you might need 40 hours of work to be done, but those 40 hours could get spent over a course of months.

Estimating project duration is not unique to projects using open source, but it can be magnified if you are working with Drupal community volunteers. Because volunteers often don’t work on a
schedule, you might need to wait a while before getting the feature you need or even a bid from a module developer.


как раз про разработку жестко завязанную на модулях. Может у них там так и там такая логика и работает, а у наших заказчиков?

Аватар пользователя natbampo natbampo 18 декабря 2012 в 17:36

И что много сайтов с 6-ого на 7-ой силами самого владельца сайта обновляются?...
Вообще не заметно, так же сидят на шестерке.
Так что владельцу сайта все равно считай по любому надо нанимать спеца друпалера на переезд. Так что ему нет разницы если все равно платить.

Аватар пользователя MainVisor MainVisor 18 декабря 2012 в 18:11

Тупая тема, даже лень печатать... Читаешь доводы некоторых, которые больше похоже упражнения в стохастике-софистике.

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

Аватар пользователя MainVisor MainVisor 18 декабря 2012 в 18:12

"natbampo" wrote:
Geldora это тема для разработчиков. Вы - разработчик, который по работе создает на заказ сайты?

Встречный вопрос: Это сайт разработчиков drupal?

Аватар пользователя MainVisor MainVisor 18 декабря 2012 в 18:15

"ХулиGUN" wrote:
Задача
Дано: Свежескачанный дистрибутив Drupal 7
Найти: Количество дополнительных модулей с орга, чтобы реализовать поле для вставки роликов с ютуба и вимео?

Модуль: Video Filter

Аватар пользователя MainVisor MainVisor 18 декабря 2012 в 18:17

"sg85" wrote:
а как быть, если ни один готовый модуль для решения основной задачи не подошел?

90% случаев людям достаточно модулей с d.org, а ваш случай скорее исключение согласитесь ведь так?

Аватар пользователя MainVisor MainVisor 18 декабря 2012 в 18:19

"ХулиGUN" wrote:
А ещё как вариант после установки этих 20 модулей обновится 1 и полетит весь их функционал, который выполнили бы каких сотню строк своего кода.

По возможности нужно использовать:
1. Модули с д.орга
1.1. Если используем модуль, то он должен быть с "историей".
1.2. Количество модулей должно быть минимальным, без которых "никак"
2. Хардкодить желательно только в редких случаях - исключениях.
2.1. Свой код только для вторичной функциональности проекта, без которой можно жить.

Читаем подпункты пункта 1

Аватар пользователя Geldora Geldora 18 декабря 2012 в 18:46

"natbampo" wrote:
Geldora это тема для разработчиков. Вы - разработчик, который по работе создает на заказ сайты?

Это тема для тех, кто делает сайты на Друпале, так?

Я - человек, который работает с друпалом уже 6 лет. Но я, если не справляюсь сама, предпочитаю нанимать людей.

Аватар пользователя Geldora Geldora 18 декабря 2012 в 18:37

"multpix" wrote:
нужно открыть глаза, и прочитать что народ обсуждает,
а потом повторно включить мозг и попытаться понять)))

Учитывая, что я как раз участвую в обсуждении на 3 страницах... как бэ я понимаю. Но не согласна с большинством участников Smile

Аватар пользователя Geldora Geldora 18 декабря 2012 в 18:49

"ХулиGUN" wrote:
Для того чтобы установить этот модуль, нужно ещё как минимум 2 дополнительных установить... если ещё нужна поддержка ютуба то + ещё 1... итого минимальный набор 4 модуля + время на тестинг стабильности версий против 20 строк. Это друпал вэй по-вашему?

Ну и что, что 4 модуля???

Если мне в лень ставить три модуля... то их можно и не ставить, так? (Я бы вообще без форматтера обошлась - настроить фильтры + удобная кнопка в эдитор = результат, который МЕНЯ устраивает = ни строки кода...)

И вообще. Мы обсуждаем, что лучше - море или апельсин.

Имхо, решает не программист Lol а заказчик. Если заказчик вам говорит - ХОЧУ именно это и ХОЧУ именно так, то разработчик сделает так, как ему скажет заказчик. Это право хозяина сайта решать - останавливать развитие сайта, зависать ли на 5ке или 6ке, или планировать развитие своих проектов. Если я, как заказчик, могу позволить себе планировать найм специалиста для апдейта минимодулей на 8ку - это хорошо. Если я, как заказчик, могу себе позволить оплачивать время специалиста на написание мини-модулей + их тестинг, то это тоже хорошо. Но если я, как заказчик, не могу себе позволить ни того, ни другого - вполне нормально, имхо, сразу указать эти ограничения в ТЗ. Это нормально же?

Программист со своей стороны может (или даже должен - но это уж на ваш вкус) посоветовать, объяснить, почему мини-модуль лучше чем существующее решение. Но вы же не можете навязывать свою точку зрения мне, говорить МНЕ что мой сайт должен остановить свое развитие, потому что вам проще написать 20-30 строк кода?! Это же тоже номральный подход, правда?

Аватар пользователя Crea Crea 18 декабря 2012 в 19:49

Geldora wrote:

Имхо, решает не программист Lol а заказчик. Если заказчик вам говорит - ХОЧУ именно это и ХОЧУ именно так, то разработчик сделает так, как ему скажет заказчик. Это право хозяина сайта решать - останавливать развитие сайта, зависать ли на 5ке или 6ке, или планировать развитие своих проектов. Если я, как заказчик, могу позволить себе планировать найм специалиста для апдейта минимодулей на 8ку - это хорошо.

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

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

Аватар пользователя q2_faith q2_faith 18 декабря 2012 в 19:09

Geldora тут права. Заказчик должен решать какие решения ему нужны. Не часто, но встречал в ТЗ, что заказчики требовали использования модулей с д.орг. Применение кастомных решений должно было обсуждаться отдельно и нужно было доказать почему лучше.
p.s. предлагаю чуть упростить спор и применить следующее упрощение, по дефолту считать, что модули с д.орг и кастомные решения написаны правильно.

Аватар пользователя multpix multpix 18 декабря 2012 в 19:28

"Geldora" wrote:
Имхо, решает не программист Lol а заказчик.

"q2_faith" wrote:
Заказчик должен решать какие решения ему нужны.

заказчик должен принять конструктивное решение в той сфере для выполнения работы в которой он нанимает специалиста??? - при всем уважении.. бред!

максимум - совместное обсуждение

а спор - свое или от сообщества, это спор - своя поддержка или своя+сообщество

хулиган спрашивал - не еретик ли он, дак имхо нет, не еретик )))
пока не начал писать свою облегченную но более функциональную версию вьюс и пугать этим сообщество, костер готовить рано )))))

Аватар пользователя Geldora Geldora 18 декабря 2012 в 19:44

"ХулиGUN" wrote:
Один хер придётся орговские модули перепиливать под задачу... зачем качать кучу модулей, чтобы один хер писать кастомный код, но используя новые модули?

Зачем же вы спрашиваете совета, если уже знаете ответ???

Аватар пользователя q2_faith q2_faith 18 декабря 2012 в 19:51

"ХулиGUN" wrote:

Будьте джентльменом) с девушкой же общаетесь)
подведем промежуточный итог) правильнее с клиентом обсуждать применение тех или иных решений, разъясняя суть происходящего?)

Аватар пользователя Geldora Geldora 18 декабря 2012 в 19:55

"Crea" wrote:
Я давным давно в этой теме написал, что решают совместно заказчик с разработчиком. Если решает один заказчик то это самодурство. Работать или нет с самодурами - личное дело исполнителя.

Ну, я же написала

"Geldora" wrote:
Программист со своей стороны может (или даже должен - но это уж на ваш вкус) посоветовать, объяснить, почему мини-модуль лучше чем существующее решение

Объясните. И еще раз объясните. Но НЕ РЕШАЙТЕ за меня, потому что это тоже самодурство:

"Geldora" wrote:
Но вы же не можете навязывать свою точку зрения мне, говорить МНЕ что мой сайт должен остановить свое развитие, потому что вам проще написать 20-30 строк кода?!

П.С. Я исхожу из того, что и специалист, и заказчик - "нормальные" люди, т.е. есть подробное ТЗ, мы друг друга "уважаем", уважаем чужое мнение, чужое время и т.п.

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

Аватар пользователя natbampo natbampo 19 декабря 2012 в 10:48

"MainVisor" wrote:
90% случаев людям достаточно модулей с d.org, а ваш случай скорее исключение согласитесь ведь так?

Это просто бред. Кому - разработчикам хватает модулей для реализации любых пожеланий по сайту???? Smile
Скорее тете Моте хватает их для странички о своем коте Степане.
"Geldora" wrote:
Объясните. И еще раз объясните. Но НЕ РЕШАЙТЕ за меня, потому что это тоже самодурство:

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

Аватар пользователя natbampo natbampo 19 декабря 2012 в 10:56

"Geldora" wrote:
П.П.С. Лично я считаю за "заказчик"+"фрилансер" и ситуацию, когда человек сам себе делает сайт. Потому что лично я, когда чего-то хочу добиться (те я - заказчик) сразу понимаю, что я - как исполнитель - не могу написать собственный модуль. Иначе говоря, я-то использую всегда только модули с .орга.

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

Аватар пользователя natbampo natbampo 19 декабря 2012 в 13:54

"q2_faith" wrote:
не редкий, если человек делает сайт для себя/заработка

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

Аватар пользователя q2_faith q2_faith 19 декабря 2012 в 14:19

"natbampo" wrote:

я имел ввиду не сам делает для себя, а нанимает кого то. а потом уже в процессе учится администрировать его, в том числе и обновлять.

Аватар пользователя MainVisor MainVisor 19 декабря 2012 в 15:52

"natbampo" wrote:
Это просто бред. Кому - разработчикам хватает модулей для реализации любых пожеланий по сайту???? =)

Вы читать умеете? По вашему проекты на друпал делают одни программисты? Я не писал "любых пожеланий", но 90% случаев, достаточно модулей с дорга.
А много ли самописных модулей используеть drupal.ru?

Аватар пользователя Crea Crea 19 декабря 2012 в 16:22

MainVisor wrote:
А много ли самописных модулей используеть drupal.ru?

drupal.ru - пример того, как не надо делать сайты.

Аватар пользователя MainVisor MainVisor 19 декабря 2012 в 15:52

"natbampo" wrote:
А представляете есть даже сайты которые с нуля пишутся программистами или на фреймворках... Один раз сделался и работает годами и нет парения что вышла какая то новая версия и захотелось.

Тогда пишите на чистом php и ассемблере. И что вы делаете на этом сайте?

Аватар пользователя natbampo natbampo 19 декабря 2012 в 16:22

"MainVisor" wrote:
Тогда пишите на чистом php и ассемблере.

Это тупое предложение от ламера можешь оставить себе.
"MainVisor" wrote:

И что вы делаете на этом сайте?

То же что и остальные друпалеры.

Аватар пользователя natbampo natbampo 19 декабря 2012 в 17:19

да они не ответят, они же говорят, что сайт делают себе и поэтому их устраивает если хоть как то получится. Пофиг что у конкурентов в 10 раз лучше, главное не заплатить раз в 2-3 года пару баксов программисту.

Аватар пользователя q2_faith q2_faith 19 декабря 2012 в 18:06

"ХулиGUN" wrote:
Так что лучше: написать свои пару строк или всё же установить с орга модуль и перепиливать его?

давайте возьмем за пример private_message
по заданию меня модуль на 100% не устраивал. я стоял перед выбором, написать новый private_message(гораздо менее громоздкий) или написать небольшой модуль и переопределить вывод этого модуля(был еще вариант сделать это через вьюшку, но вьюшка наотрез отказалась работать). чтобы вы выбрали?

Аватар пользователя Plazik Plazik 19 декабря 2012 в 19:42

"ХулиGUN" wrote:
Количество дополнительных модулей с орга, чтобы реализовать поле для вставки роликов с ютуба и вимео?

http://drupal.org/project/youtube
http://drupal.org/project/vimeo_link_formatter

Простое поле, работает по простому урлу видео.

Аватар пользователя sg85 sg85 19 декабря 2012 в 20:52

2MainVisor, сравните сайты, сделанные ТСом и сайты PromoGroup, это будет самым наглядным примером разницы применения небольших кусков своего кода и модулей с d.org

"q2_faith" wrote:
давайте возьмем за пример private_message
по заданию меня модуль на 100% не устраивал. я стоял перед выбором, написать новый private_message(гораздо менее громоздкий) или написать небольшой модуль и переопределить вывод этого модуля(был еще вариант сделать это через вьюшку, но вьюшка наотрез отказалась работать). чтобы вы выбрали?

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

Еще пример, необходимо сделать так, что бы пропало поле кол-во товара в Ubercart2(т.е. купить можно не более 1 единицы товара), для этого есть модуль(название забыл, restrict_qty что ли), позволяющий ограничить кол-во товаров, однако, по делу там только 2 строчки кода(1 хук, в котором, 1 строчка кода, хрен с ним, с закрывающей скобкой в сумме 3 строчки кода), остальное же, попытка сделать его универсальным(а вот там уже много мусора), т.е. привязать его функционал к конкретным продуктам(даже не к типам), однако, в самой корзине и оформлении поле от этого не исчезло(а вот альтеры там почему-то не привязали), и получается, все равно придется кодить, так как быть с этим забавным модулем? Ставить его и один черт через свой модуль дописывать альтеры, или же не захламлять индексы функций, БД, админку не нужным хламом, а тупо включить этот уберовский хук в свой модуль?

Вообще уберкарт - хороший пример, как не надо писать модули

Аватар пользователя natbampo natbampo 20 декабря 2012 в 9:57

"q2_faith" wrote:
давайте возьмем за пример ...

А что это за пример? В обоих случаях добавится один "самописный" модуль.
"q2_faith" wrote:

чтобы вы выбрали?

Если получится в своем модуле через хуки настроить другой модуль (его не касаясь), то думаю 2-ой вариант очевиден.
Но вы же и против таких настроечных модулей...

ХулиGUN же не про эту ситуацию спрашивал, а когда так, по проще, настроить нет возможности и когда уже требуется лезть и менять код модуля чтобы добиться требуемого.

Аватар пользователя q2_faith q2_faith 20 декабря 2012 в 15:46

"natbampo" wrote:
А что это за пример? В обоих случаях добавится один "самописный" модуль.

только объем кода будет разный
"natbampo" wrote:
Если получится в своем модуле через хуки настроить другой модуль (его не касаясь), то думаю 2-ой вариант очевиден.
Но вы же и против таких настроечных модулей...

я против самокатов решений, которые потом тяжело поддерживать

Аватар пользователя natbampo natbampo 7 июня 2013 в 11:17

"Crea" wrote:
Хорошая статья

+1

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