10 декабря 2012 в 12:53
Довольно часто вижу на форуме сообщения типа "какой модуль поставить, чтобы была карусель или сворачивающийся блок". И часто в ответах ставят ссылки на модули с орга, которые выполняют данные функции.
Так вот хотелось бы спросить: DrupalWay под собой подразумевает по каждой хотелке инсталить новый модуль или же можно обойтись парой строчек кастомного кода. На своих проектах я использую только минимальный набор модулей, необходимый для базового функционала + некоторые серьёзные модули, которые расширяют возможности движка в конкретном направлении (например, если это магазин, то я ставлю commerce и не собираю на коленке данный функционал, если это какой-нить crm то проще поставить maestro).
Всякие модули галерей, слайдеров и прочих финтиплюшек идут в треш автоматически, ибо их функционал можно заменить небольшим кастомным кодом. Ведь один хрен каждый из них придётся подгонять под себя, делать темизацию...
Так каков всё-таки drupalWay? Я поступаю правильно или всё же я еретик, и чем больше модулей установлено в проекте, тем он считается круче?
Комментарии
Если бы все все делали готовыми модулями, новых модулей бы не появлялось) Пишите, публикуйте на орге, получайте патчи на свой код, лучшие проекты привлекут внимание и будут обновляться.
Правильный ответ зависит от типа аудитории. Не все являются разработчиками.
ХулиGUN, много друпалеров не являются программистами. Спорить тут не о чем, это просто факт.
Иногда да, проще прикрутить что-нибудь ручками.. Тем более, если более менее подходящего модуля нет.
И кстати даже по этой причине иногда проще прикрутить ручками, если модуль писать не умеешь. Вот недавно прикрутил ajax калькулятор для webform, а коды в Гугле нарыл и адаптировал.. но еще допиливать надо.
Разработчики друпал решили, что будут делать свою систему, как одновременно и CMS и фреймворк. Соответственно оба подхода являются друпалвей, Crea тут прав.
У пользователей, не программистов просто нет выбора, они используют то, что доступно, либо заказывают у программистов новый модуль.
Для программистов все несколько иначе - если есть полностью подходящее решение на друпал.орг, то конечно надо использовать его. Если же оно не удовлетворительно, то либо допиливать его и слать патчи разработчикам, либо делать свое решение.
Быстрые решения в лоб сначала хороши, но если занимаешься поддержкой проекта и он растет, то более универсальные решения уже могут оказаться предпочтительнее.
Кроме того у разработчиков уже есть опыт работы с каким-то набором модулей, наработанные схемы, сборки, которые ускоряют разработку на стандартных решениях и время разработки на таких решениях оказывается примерно таким же, как написание пары строк кода.
Еще есть разные требования по производительности и тут возможно нужно отказаться от использования каких-то модулей, которые в противном случае можно использовать, если это существенно экономит время разработчика и средства заказчика.
И так можно долго рассуждать, но в итоге, как говорят по-англицки it all depends.
Наоборот. Кастомное решение более простое и снижает издержки на поддержку.
Контр-пример: в 90% случаев через год существования проекта, переопределение темизации в tpl.php сложнее и дороже поддерживать, чем то же самое, через ds и panels. У меня есть выборка сайтов, количественно это статистически значимые уже результаты, минимум по 30 сайтов с обеими вариантами реализации.
Контр-контр-пример: визуальный вывод слайдеров, галереи и т.п. проще поддерживать когда это views+js plugin, нежели модуль с d.org, включающий в себя этот js плагин и настройки вывода.
Panels я бы заменять своим модулем не стал - это, все-таки, фундаментальный, формирующий архитектуру модуль. Речь о более простых модулях.
Разница в поддержке обычно такая:
- в своем модуле меньше кода, меньше дыр, легко найти конкретный кусок кода, если нужно что-то исправить
- в чужом модуле на 145% больше кода, причем абсолютно ненужного, говнокод, непродуманная архитектура, куча багов включая дыры безопасности, регрессии в новых версиях (бесит)
Но создать свой модуль это большие капитальные издержки + потеря времени. Поэтому имеет смысл это делать не на старте, а когда проект уже прошел начальную стадию.
правильный ответ зависит от экономической целесообразности)
модули с д.орг легче поддерживать, говорю по собственному опыту. так как часто приходится иметь дело с сайтами, которые "кто то сделал".
я считаю что друпалвэй, это если и делать кастомное, то правильно, через модуль, но сначала посмотреть д.орг
Нелюбовь к чужому коду у программстов - явление известное. Проблема в том, что модуль с drupal.org - это тоже чужой код.
Считается, будто решение с Drupal.org позволяет не заботиться о его внутренностях. А заглянешь в код и волосы становятся дыбом.
Мое мнение - это обычный самообман. Модули с drupal.org позволяют только разным специалистам говорить на одном языке. Они не обеспечивают снижение издержек автоматически, если только у вас проект не функционирует в стиле цыганского табора - когда над ним работают постоянно новые разработчики. Но это бы означало, что у вас уже большие проблемы.
Здесь все, как обычно, упирается в прокладку между стулом и монитором. Если свой модуль написан экспертом, он будет гораздо проще, надежнее и сэкономит кучу нервов. И по качеству будет лучше 90% говна с Drupal.org
а потом пользователь "случайно" удаляет вьюшку и получаем ошибку. пользователь идет к другому разработчику и тот потратит достаточно много времени, чтобы понять в чем суть происходящего.
я не против кастомных решений. но как правило они дырявые. или у вас в штате есть тестер?
Вьюху. экспортированную в код, не удалить через интерфейс. Палитесь
не всем же заказчикам так везет и они нанимают вас. по качеству 90% кастомных решений это гавно(по опыту работы с амер.сайтами, но с российскими ситуация похуже будет).
по крайней мере на д.орг ревизию кода сделают, плюс багрепорты. правда ревизия не касается "старых" модулей, а там иногда попадаются "шедевры"
Я про себя не говорю
Я себя вообще программистом (в классическом понимании) не считаю..
На Drupal.org тоже кастомные решения
Ну вот возьмем простую задачу - хлебные крошки. Простейший модуль, задающий хлебные крошки через drupal_set_breadcrumb() в разных хуках, в 10 раз проще и надежнее, чем использование Custom Breadcrumbs + борьба с ним.
То же самое - метатеги. Запихать несколько строчек в head - у меня это вышло на 2 страницы кода. Сравните с Nodewords (Metatags в 7). Вдобавок, при копании в коде Nodewords обнаружил дыру безопасности.
Самое главное - свой модуль на 100% соответствует задаче. А большинство модулей Друпала это каша из топора. Изначально кажется, будето они способны справиться с задачей, а позднее постоянно натыкаешься на баги, невозможность реализации тех или иных фич. И вот уже разработчик, вместо того, чтобы работать над своей задачей, исправляет чужой модуль.
И на эту кашу из топора все попадаются
я всего лишь намекнул на слабое место в модуле, которое может нарушить работу сайта.
я нигде не прочитал про программно созданную вьюху
а вообще каждый оценивает со своей колокольни. если разработчик в основном создает сайты с нуля и на поддержке в основном сайте сделанные им самим, то конечно он будет двумя руками за кастом и хардкод)
Создавать программно не обязательно. достаточно экпортировать. Я к тому, что держать в коде - как бы бест практис
я ведь и не спорю
я просто указал, что кастомное не всегда достаточно тестируется и дальнейшая поддержка тоже под вопросом.
Для многих все наоборот. В своих модулях можно наделать дыр, сделать непродуманную архитектуру.
В то же время модули на drupal.org проверены другими людьми, видно сколько сайтов их используют и, самое главное, есть поддержка и обновления. На свой же код обычно забиваешь после его написания.
P.S. Я в последнее время перешел на повсеместное применение модулей с drupal.org
Разумеется, результат в любом случае зависит от квалификации исполнителя. Я описываю ситуацию только с точки зрения программиста, знакомого с best practice разработки под Drupal.
Крайне редкое явление. Мои тикеты очень часто получают ответ через год. Бесплатная поддержка, ну это примерно, как бесплатный сыр...:)
Это недостаток, а не достоинство. Вернее, хорошо, когда баги исправляют, но лучше бы их не было с самого начала. И часто вместе с багфиксом присылают новые функции (которые чаще всего не нужны) и сломанные старые. В итоге, получается, потратил кучу сил на обновление, чтобы просто сохранить то, что уже и так работало.
Гораздо проще 1 раз написать простой модуль, проверить его код + по желанию покрыть тестами. И никаких обновлений не нужно. Не нужно исправлять то, что и так работает.
Все зависит. Все зависит от ваших ответов на следующие вопросы:
- вы программист (способны ли написать модуль/разобраться в жаваскриптах и т.п.) или нет? Я, например, не способна.
- вы делаете сайт для себя или на заказ? У меня - собственный проект.
- рассчитываете ли вы, что ваш проект продержится более года? собираетесь ли вы продолжать его поддержку в эом случае? Моему основному сайту - уже 6 лет (апдейт с 5 - 6 - 7), другим - от 3х до года. Я рассчиываю, что все мои проекты как минимум будут портированы на 8ку.
В общем и целом, неважно, делаете ли вы сайт на заказ или "для себя", лучше предпочитать наиболее универсальное решение. Универсальное = такое, которое можно в любой момент изменить. Скажем, любые операции с выборками (лучшие/похожие/топ статьи и т.п.) ДОЛЖНЫ решаться через вьювс. Потмоу что вы, или ваш заказчик, должен иметь возможность в любой момент поменять условие выборки. Если вы сами поддерживаете свой сайт, то вы оцените преимущества вьювса после... скажем, полутора лет поддержки, когда вам придется проводить большой апгрейд, или когда вам захочется поменять тему... Если вы работаете только под заказ, то должны подумать о том, что ваш заказчик может нанять незнакомого с вашим кодом специалиста. Со вьювсом смогут разобраться все. Конечно, если вы работаете через вьювс, то дальше можно использовать все возможности темизации, чтобы навесить любую "обертку" выборки, какая вам захочется: цсс, жс и т.п.
Если с вьювсом все понятно, то часто гуру-программисты выступают против небольших утилити-модулей: скажем, тот же Скролл то Топ. Их использование становится очччень оправдано после первого Большого Апдейта. Вот скажем, из моего опыта:
- роботс.тхт - все настройки перенеслись с 6ки, не нужно переживать что где-то что-то затерлось.
- верификейшн - вообще отлично. Мало того, что все верификации сохраняются, у вас еще и чистая корневая папка сайта.
И то и то - незаменимо для мультисайтинговвых инсталляций.
- Многие пишут, мол, зачем нам модуль Аналитикс - можно же код вставить в шаблон... НО! Модуль и код кэширует, и дает +100 доп.настроек и возможностей (например, отслеживание 404 страниц) и главное - при изменении шаблона вы не теряете статистику (у меня потерялось примерно 4 дня Яндекс Метрики).
- Вы приводили пример Скролл то Топ и пишите, что мол, проще вставить в шаблон. Так-то оно так... но если меняется шаблон?
- Пример с Метатегами вообще неудачный. Я не знаю, есть ли возможность генерировать в шаблоне метатеги на большой, эдак с 10 000 страниц вебсайт... Конечно, если у вас одностраничник... то вариант с шаблоном может быть оправдан.
И так далее и так далее.
Еще меня искренне бесит, когда производители премиум-тем используют: прямой вывод кода в шаблоне, скрытую темизацию через модули (когда темизация вынесена в модули), или когда темизация вынесена в темплейт.пхп, а не в файлы тпл.пхп. Или когда используется в теме глубоко закодированная функция вызова какого-то конкретного меню - вместо нормальной темизации, скажем, праймари меню (этим страдает Темснап, он еще и свои переводы в тпл. файлах пишет, которые не подхватываются системой перевода Друпала
). Скажем, я-то сразу проверяю темплейт.пхп файл, но не все с этим разберутся.
Также, нужно всегда использовать друпальскую систему блоков и регионов (никаких - прописка кода в шаблоне) потому что заказчик должен иметь возможность изменить расположение такого-то блока. Вообще, для всего, что касается оформления - есть тема, менять все нужно там - в соответствующих тпл.пхп файлах + через .инфо прописывать цсс-ки, жс и тп
С другой стороны, для оформлений - имхо - можно и нужно пользоваться системой темизации, прописывать все в шаблоне. Скажем, я стараюсь не ставить модули интеграции с соцсистемами, со всякими скриптами - это можно решить в шаблоне, притом, с большей гибкостью...
Geldora,
И для выкатывания новых настроек просто на сервер выкладывается новый код модуля.
Про метатеги вы неправильно поняли. Конечно, записывать их напрямую в шаблоне невозможно, т.к. они динамические. Я писал о своем модуле, который делает все что нужно (description + keywords + robots), при этом не имеет интерфейса. Кода там всего на пару страничек, так что багам и дырам взяться неоткуда.
Такой модуль сразу содержит все нужные данные в коде, значит для изменения настроек модуля не нужно эти настройки из базы дополнительно экспортировать в код - они там уже лежат
Разумеется, это вариант для программиста. Это принципиально другой подход к разработке Друпал сайтов, где Друпал чаще используется как фреймворк.
При этом, Nodewords - классический вариант говнокода.
Не согласен. Изменять нужно только то, что требует замены - исходить надо из задачи. Сама по себе возможность изменить что-то не ценна.
Максимальная универсальность - это многочисленные абстракции, которые имеют огромную цену. Не удивляйтесь потом, когда сайт загружается несколько секунд - это все оттуда.
Каждая новая абстракция должна быть обоснована, прежде чем оказаться внедренной. Views, как такая абстракция, давно доказал свою обоснованность. Такие модули, как Views, Panels - образуют основу Друпала. Если рассматривать отказ от таких модулей в пользу самописных модулей, у меня возникает вопрос "а зачем тогда вообще здесь Друпал используется".
Совсем другая ситуация с "утилити", как вы сказали, модулями. Чаще всего, они действительно могут быть заменены своим модулем. Но я еще при оценке смотрю ответы на такие вопросы:
1) решает ли модуль только одну задачу
2) делает ли он это хорошо - тут смотрю и на качество кода, и на настройки, и на объем кода
Если на оба вопроса ответ "да" то ничего страшного в таком модуле нет. Чаще всего из "утилити" модуле попадаются такие, которые со своей задачей справляются крайне плохо. Например, модуль внедряет какой-то сторонний плагин, но не поддерживает все настройки этого плагина. При этом вам эти настройки нужны. Итого имеем модуль, который мало того, что не решает свою задачу полноценно, он еще становится у вас на пути - ведь для добавления недостающих настроек плагина вам уже нужно разбираться в коде этого модуля и править его. Т.е. лишняя, вредная абстракция. Соотв-но возникает вопрос, а стоила ли овчинка выделки с самого начала ? В большинстве случаев, для разработчика ответ - "нет".
Cогласна, просто выразилась неправильно
Я имею в виду, если стоит выбор - либо вьювс либо "10 строк кода" там, тут и здесь, нужно все равно ставить вьювс... Потому что вьюювс - это та самая абстрактность, которая поддерживается и принята. А поддержка "10 строк кода" в конечно счете обойдется слишком дорого, если конечно, речь не идет о краткосрочном проекте.
Еще я забыла важный момент: нужно использовать те модули, которые более-менее имеют историю + достаточно абстрактные и универсальные. Потому что - хоть это и сложно предугадать - но проект типа вьювса имеет меньше шансов загнуться, чем супер-легкий модуль выборки нод опрделенного типа... Конечно, сложно предугадать что и когда загнется: пример Ивентса из 5ки, или Фююжн-темы с 6ки - это доказывают. Но все равно, чем больше пользователей = тем меньше шанс, что не прекратится проект = возможность малых и больших апгредов
И последнее. Я удивлена, что другие программисты раньше не написали: но ведь работа с .орговскими модулями - выгоднее самописа!!! И скорость разработки, и стоимость поддержки, и даже последующих обновлений - а если вы переделываете под себя модуль, то выложите патч в модуль + получите немного саморекламы. Я была на французском друпалкампе, там было несколько презентаций модулей, которые выкладывались на тот момент на .орг. Это были большие веб-агенства, которые а) закладывали в свои сметы время на доводку "до уровня .орга" б) все равно считали, что опен-сурсное развитие их модулей им обойдется дешевле, чем "внутристудийное", за счет тестеров и патчей со стороны.
(Оффтоп) А выложить для страждущих?
В друпале вообще проблема с метатегами, хоть в 6к (нодвордс - ГОВНОкод!!) что в 7ке, с его Метэгом недоделаным 
Вы рассуждаете как пользователь. Как разработчик могу сказать абстракции - зло
Это не является абсолютной истиной. Все зависит от конкретной задачи. Написать маленький модуль, на 100% выполняющий задачу может быть гораздо дешевле, чем адаптировать гигантский универсальный модуль.
Если вы посмотрите выше, я все это обсуждал. И про поддержку, и про обновления.
Давайте разделим студии и владельцев проекта. Студиям требуются максимально универсальные решения для снижения издержек - они клепают сайты сотнями. Для владельца же - проект пишется один раз, и поддерживается много лет. Универсальность ему ни к чему (за исключением действительно необходимых настроек, согласно ТЗ). Поэтому, сравнивать все в одной куче некорректно.
Да, разработка в опенсурс позволяет продвинуться разработчику. Но ведь у владельца проекта нет такой задачи - пиарить исполнителя
Смысла не имеет. Модуль максимально привязан к сайту.
Хорошая оценка. Буду использовать
Я обычно отказываюсь от интеграций с соцсетями. С плагинами - не могу, т.к. друпал не всегда правильно распознает жкуэри-плагины в шаблоне (мне сказали, нужно их как-то там переписывать). Я не могу их переписать по друпальски, так что приходится ставить модули
Но скажем, лайзилоад мне было проще вставить в шаблон напрямую. Так что зависит от задачи и от исполнителя еще 
Лучше то, что работает быстрее и спокойно переносит обновление core Drupal, это может быть и модуль в одном случае и код в другом.
Не сказала бы. Вот я - владелец проекта. Как раз мне лично - чем универсальнее модуль, тем лучше, ибо я могу в любой момент сменить его настойки. Если бы я была программистом, возможно, я бы предпочитала что-то другое.
Вот, чтобы далеко не ходить за примером: сегодня обсуждали с моим парнером переделку главной страницы. Обсуждался в частности вариант: в слайдере вместо нод выводить термины таксономии. Поскольку это вьювс - сделать такое изменение я смогу. Была бы выборка напрямую с базы - я бы такое не смогла изменить без фрилансера. В общем, вот это, как по мне, "универсальность" и "изменяемость"
сайт без разработчика...мечты, мечты.....
Недавний пример отказа от "универсального" модуля.
Использовал модуль Google Ad Manager долгое время. Недавно обновился до 3.х, чтобы использовать Google Publisher Tags. Оказалось, в новой ветке регрессия - нет возможности изменить вывод рекламного кода через фунцию темизации. Плюс, потребовалось привязать слоты GPT к каналам Adsense, а это делается через JS и этой функции в модуле нет.
Заменил все своим модулем. Итог: свой модуль в разы меньше по кол-ву кода. Все функции GPT поддерживаются, нет ненужной привязки к UI модуля. Все работает так, как мне надо. Нет зависимости от чужого кода - замечательно. И обновлять не нужно!
Реализовать поддержку нужных мне функций в универсальном модуле Google Ad Manager было бы гораздо лучше для сообщества в целом, но лично для меня слишком дорого и долго.
Если набьете сайт самописными модулями, то при переходе на семерку или восьмерку придется все самим переписывать.
В случае использования орговских модулей этого скорей всего не будет.
Начнем с того, что не для всех сайтов апгрейд вообще экономически целесообразен. Если сайт продвинутый, на нем всегда используется свой кастомный код, и зачастую очень много такого кода. Переносить такой код - очень дорогое удовольствие. Гораздо выгоднее может быть самостоятельно провести аудит безопасности своих модулей и заморозить версию Друпала у себя на много лет вперед.
Без проблем обновляются только самые простые сайты, использующие самые популярные модули, причем минимальное кол-во. Если у вас на сайте 150+ модулей с орга, так же придется их самому переписывать или заменять своими модулями при апгрейде.
Куча модулей до сих пор не портирована на 7, то же самое будет и с в 8, скорее всего.
За это приходится платить ресурсами на хосте - а за них вы платите ежемесячно, так как "заточеное решения" "кушает" меньше ресурсов, если конечно оно хорошо сделано
А так же:
- патчить существующие дополнительные модули
- делать форки модулей
- совмещать работу разных модулей, подбираю рабочую комбинацию в том числе из дев
- переделываться, вылизывать, баги и ошибки, проверять совместную работу модулей после апдейта, устранять ошибки и т.д. и т.п.
Есть функциональность, которой нет в core (например как Вы правильно заметили commerce) - ее надо ставить, если это экономит время разработки, деньги клиента и работает быстро, а вот например views - стоит ставить для простых выборок, если же речь идет о сложной выборке - он Вам такой "оптимальный" запрос напишет - что "ну его лесом ..." ( не зря его в core до сих пор не включили )? c другой стороны - страница со списком /node чуть ли не 20 строк код всего
- т.е. way делать в конкретном случае разный - со знаем дела и думая головой. Ну вот умный человек - все понимаете 
я думаю можно подвести итог)
если вы делаете сайт под себя или вы потом будете его сопровождать, то вправе использовать любое решение.
если сайт делается для заказчика, тем более, который потом не будет у вас сопровождаться, то вы должны использовать модули с д.орг.
да за универсальность надо платить, но как часто говорят на кэмпах, сейчас железо стоит дешевле, чем хороший разработчик.
Я правильно понимаю, что вы своим заказчикам ставите Nodewords вместо своего модуля для метатегов ?
Еще раз, все зависит от задачи. Если для решения задачи изначально лучше свои модули, то их и нужно использовать.
Что лучше для решения задачи должен решать в каждом конкретном случае основной разработчик проекта совместно с владельцем проекта.
Масштабируемость железом имеет свой предел. И если ситуацию запустить с самого начала, потом уже железом можно не вытянуть.
естественно мы сейчас говорим не про "в контактике", а достаточно распространенные визитки, каталоги, инет-магазины. опять же повторюсь, для клиента лучше, когда разработка дешевле(модули с д.орг) и дальнейшее сопровождение дешевле(модули с д.орг). использовать друпал как фреймворк для сайта - каталога продукции, экономически не целесообразно.
Если модуль с drupal.org - говно - это тоже для клиента хорошо ? Вы наверное и в код используемых модулей не заглядываете ?
Разработка дешевле, если модуль выполняет задачу на 100%. А если требуется доработка - это еще не известно, что лучше - написать свой маленький модуль или патчить большой универсальный с drupal.org
Я соглашусь про визитки и каталоги. Но даже интернет-магазин это уже продвинутый сайт, где ваше утверждение не всегда верно.
давайте обобщать) каков, по вашему мнению, процент гавномодулей на д.орг и каков процент гавнокодеров среди фрилансеров?
про фрилансеров не скажу, а говномодулей на d.org намного больше 50%
на нет и суда нет)
Может с примерами?) Любой из популярных модулей на drupal.org и самописный модуль с схожим функционалом (на гитхаб например выложить). А то что мы тут обсуждаем, без примеров то. Не верю)) А так сравним, порадуемся)
adubovskoy,
пример с Nodewords был выше.
А я его не понял. Я вообще не понимаю определения "плохой". Понимаю "хуже чем". Вот хуже чем что - мне не показали. Покажите код, который делает то же, но лучше и красивей. Зачем прятать от сообщества?
Что там показывать - маленький модуль, который делает hook_preprocess_page() и вставляет нужные метатеги в head.
Недостатки Nodewords - гигантский уродливый интерфейс, кривое API, низкокачественный код (как пример - дыра в безопасности). В общем, куча говнокода, чтобы всего лишь вставить несколько строчек на страницу.
А вы все-таки покажите, не стесняйтесь) А мы потом возьмем стороннего друпал-разработчика и спросим сколько времени у него ушло вставить-понять как с этим работать, сравним по скорости вхождения с nodewords, да и на сам код и комментарии хорошо будет посмотреть. В общем - пока все еще сравнивать нечего, а определения "плохой" без примеров не бывает.
Не подумайте что я придираюсь. Напротив - я думаю что вы хороший разработчик и ладите с кодом, и поэтому (именно поэтому!) можете не замечать некоторых сложностей поддержки. Надо проверить.
Я бы мог написать подробное объяснение, почему Nodewords - говно. Только мой труд не будет оплачен, поэтому уж извините, распинаться не собираюсь.
Это серьезная работа.
А показывать код своего сайта - зачем ? Это конфиденциальная информация. Я уже объяснил, что это всего 2 страницы простейшего кода. Если разработчик неспособен в них разобраться - гнать надо такого разработчика.
Может, вы хотите сказать, что другому разработчику будет проще разобраться в коде Nodewords, чем в моем модуле ? Или вы считаете, что разработчик это тот, кто только нажимает кнопки в интерфейсе ?
Да я в обещем согласен с вашими доводами. Просто потому что они вами произнесены - в этом контектсе они справедливы. А вот если php-разработчик, не до конца разобравшийся с друпалом, начнет идти путем "лучше написать свое" - то начинаются и mysql query в теме и хаки ядра... Т.е. вы пропогандируете "свое писать лучше", при этом вы уже "собаку съели" на drupal api и архитектуре. А к вашим словам могут прислушаться совсем другие люди. Вам же потом расхлебывать, мы все видели такие сайты)
adubovskoy,
я выше писал, что все всегда упирается в конечного исполнителя. Модули с drupal.org хоть и дают некоторую защиту, но не панацея от отсутствия квалификации. Да и хороший модуль с drupal.org можно внедрить через жопу. Делов то..
Мне кажется это очередной миф, что можно нанять индусов/школьников, дать им хороший инструмент (Друпал) и получить на выходе хороший результат. Везде, где серьезный подход к разработке, за джуниорами присматривает синьор. И это его задача следить, чтобы не было "mysql query в теме и хаки ядра".
В 8 друпале уже в ядре.
И насколько я понял, админ-страницы управления содержимым сайта будут сделаны с помощью вьюза.
Постепенно переводим тему в "Друпал вей для друпал-8"!
Ой... подождем лета
а кто за фрилансером проследит?) на д.орг хоть какая то защита...
q2_faith,
А кто проследит, чтобы модуль с d.org был качественный, был правильно настроен и внедрен ? Кто помешает джуниору нагадить в шаблоне или template.php ?
Это личная половая трудность заказчика - выбрать грамотного исполнителя. Дяди с drupal.org ему в этом не помогут ))
Давайте пойдем от обратного - что такое не друпал вей.
Для меня, и это то, с чем лично сталкивался при доработке проектов - самописный код в теме или модуле, который не следует стандартам кодирования друпал:
1) Хаки в ядре
2) Не разделенные логика и представление (sql запросы в шаблонах и подобное)
3) Когда вместо использования api друпала пишут формы, при этом не заботясь о валидации, очистке данных и т.д. (видел как такой код насовали с помощью php filter в ноды в большом количестве)
Это основное, не все конечно. Такие вещи заставляют сайт работать не так, как это ожидалось после прочтения документации по друпал. И в этом смысле сторонние модули с друпал.орг все-таки предпочтительнее, ибо хотя бы такого в них, как правило нет.
Crea,
если разработчик криво внедряет модуль с д.орг, то мне страшно представить, как будет выглядеть его кастомный модуль)
p.s. если к вашему кастомному модулю прикрутить админку и прочие фишки нодвордс, будет в нем меньше багов?
и последнее. я думаю само развитие друпала зависит от использования модулей с д.орг
Мне такие рассуждения представляются бессмысленными. Какая разница - в итоге, все равно получится говно )))
Зависит от количества фишек и того, кто будет прикручивать. В любом случае, кол-во багов обычно пропорционально объему кода, при прочих равних, а в кастомном модуле кода меньше. Nodewords поддерживает кучу никому не нужных метатегов, например.
Заказчика это не интересует, обычно, что в принципе логично. Нечего перекладывать с больной головы на здоровую ))
Я понимаю, куда вы все клоните, что модули с drupal.org в среднем лучше, чем то, что напишет средний разработчик. Мне это утверждение представляется весьма сомнительным, т.к. на Drupal.org проверяется только первый модуль разработчика при регистрации. Дальше он может клепать говномодули пачками.
Самое интересное начинается, когда модуль с drupal.org не справляется с задачей на 100%.
а если по времени одинаково или пофиксить баг, выкатить патч и использовать модуль с д.орг, или написать свой велосипед, то какой вариант вы выберите и каким боком тут фигурирует заказчик?)
а у кастомного решения есть гарантия?
Гарантию тока в морге дают
Какая гарантия вам нужна ? Почитайте GPL
ну и последнее) я не навязываю свое мнение. я просто попытался его объяснить.
а то тема превращается в холивар
upd. и мое мнение такое - при всех равных условиях, использование модуля с д.орг будет более дпупалвэй, чем писание своего велосипеда каждый раз.
При прочих равных конечно лучше модуль с d.org.
Но еще нужно смотреть на общую статистику багов. Если модуль проблемный, и требует внимания не первый раз, стоит задуматься о его замене на кастом.
Вообще, по-хорошему, нужно проводить ревизию всех используемых модулей. Хотя бы мельком пробежать глазами.
Важно концентрироваться на проекте, а не на улучшении модулей для сообщества. Второе - скорее побочный эффект первого. Например, если есть универсальный модуль с ужасными характеристиками, скорее всего, его нужно заменять маленьким кастомным модулем, а не писать новый универсальный модуль, хотя для сообщества последний вариант, конечно, предпочтителен
Разница в стоимости разработки универсального модуля и маленького, четко сконцентрированного на задаче - гигантская.
тема-ниочем. но поспорить интересно-)))
т.к. универсального ответа на все случаи жизни не существует...
иногда надо сделать бысторо,дешево,сердито
иногда быстро, качествеего,дорого
иногда быстро сделать прототип и пилить,пилить,пилить...
иногда аргументы типа "увеличение стоимости разработки на 20 процентов уменьшит стоимость поддержки и развития на 50 процентов а сумма отобьется за полгода" не работают...
и это ничтожная часть вариантов ситуаций, которые могут возникнуть..
это к ТС
вы так говорите, как будто в год делаете по одному не сложному сайту и помните где какие функции использовали)
и вы описываете очень идеальную ситуацию. точнее даже так преподносите, модуль с д.орг априори глючный и при обновлении обязательно что то сломается, а мой модуль априори неглючный, но если даже что то и будет, то я быстро все поправлю, так как его делал я и мне там все понятно.
Не совсем верно, реальный пример: для 6й ветки нужно было сделать одну довольно сложную выборку(вложенный запрос), штатно вьювс уходил в таймаут(обратное было бы удивительным), решил сперва заменить его своим модулем, но потом захотелось просто добавить пару тройку хендлеров для вьювс, добился правильно построенного запроса, кода получилось примерно в 10 раз больше(не важно, что там обычное тупое описание хендлеров, где не нужно думать), чем было бы своим модулем, однако, несколько раз потом приходилось этот самый вьювс перестраивать, что оказалось весьма удобным и можно сказать, себя окупило(ибо вспоминать структуру БД, для перестроения запроса, через пол года несколько лениво), но тут настало время апгрейда до 7... в общем решил забить болт и сделать самопис.
Суть выше написанного: вьювс может выполнять сколь угодно сложные запросы, однако, "научить" его такому будет значительно дороже самописа(по принципу время\деньги), и единственный выигрыш от этого, как сказала бы Geldora, универсальность.
Мне кажется друпалвей - это универсальные модули, управляемые из админки, это как раз главное отличие друпала от других систем.
ИМХО, интернет и сайты развиваются постоянно и если заморозить их развитие, то можно отстать на долго. Выходят новые версии PHP, старый сайт с ними бывает не корректно работает, появляются новые тенденции и т.д.
ИМХО, не корректно сравнивать универсальный модуль и простой модуль из 10 строчек. В простом модуле понятное дело меньше мест, где совершить ошибки и на говнокодить. И если уж Nodewords совсем плохой и ваш модуль справляется с его задачами, почему бы не оформить эти строчки в модуль и не выложить на d.org. Наверно многие тоже возмущались Nodewords, но не могли написать альтернативу.
Смена версии php - событие значимое и оно не совершается каждый день. Ничего не мешает проверить весь код на совмесимость перед переходом. Для модуля с Drupal.org так же нет никаких гарантий, что он будет всегда работать.
Постоянно обновлять такой софт - значит искать лишние приключения на свою задницу, вместо того, чтобы уделять внимание тому, что дейстительно важно - развитию проекта.
Вы, возможно, не знаете, как разрабатываются и поддерживаются серьезные сайты. Там действует правило "работает - не трогай" и за такую самодеятельность наказывают
Кто сказал, что мой модуль справляется со всеми задачами Nodewords ? Он работает согласно задаче, а там требовалось только базовый функционал.
И зачем другой модуль-монстр вместо маленького, эффективного и прекрасно выполняющего задачу ?
обычно сайты замораживаются вместе с серверным ПО, например, стоит у вас debian lenny и пофиг, что давно PHP 5.4 вышел, а новые тенденции обычно не столь критичны.
у меня тот же подход, но, за пределами сайта, под который этот модуль написан, он просто не будет работать, а при попытке сделать из него универсальное решение, получится что-то вроде Nodewords, что собственно, шило на мыло.(возможно код будет чище, но тем не менее...)
Вот я про это и говорю. Вот пример такого модуля 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 - он смог написать лучшую (по его мнению) альтернативу. Как видно, модули пользуются популярностью.
Plazik
мой модуль еще проще, чем указанные вами.
ваш может и проще... вот только пользуетесь им именно ВЫ. Не имея весь багаэ ВАШИХ знаний, нам остается только пользоваться тем, что имеется. И извините уж, но мне больше нравится подход авторов Метатег-Квик (использую на своем проекте) и Path Breadcrumbs (ставила, пока не разобралась, но обязательно вернусь), которые дали нам возможность пользоваться их трудами.
И да. Непомню уже цитату и конкретного автора... но где-то вверху было, что мол проще заблокировать проект с 150+ модулей на многие-многие лета. Я чуть со стула не упала. Т.е. я должна была сидеть на 5ке??? При том, что даже между 6 и 7 (я уж молчу про 5 и 7) довольно большая разница, в т.ч. по производительности и предлагаемым возможностям, мне предлагают заблокировать развитие проектов??? Извиняюсь, но как мне кажется, даже фрилансер должен, просто обязан думать о перспективах проекта, о возможностях его дальнешйшего развития и т.п... Если мини-модуль блокирует развитие проекта - т.е. на него завязаны какие-то важные функции, имхо НЕТ и НЕТ таким мини-модулям. Если ваш мини-костыль делает что-то небольшое, плагины-оформление - еще ладно. Но для всего, что потенциально может приостановить развитие проекта, имхо, нужно использовать модули с .орга
Если бы ваш сайт был на D5, а вы, вместо апгрейдов занимались бы новыми функциями для ваших посетителей, ваш сайт был бы гораздо более навороченным и продвинутым.
Да, он бы использовал более примитивное API, но посетителям это не заметно. Посетители не оценят технической красоты сайта. Они видят только дизайн + функциональность.
Представим, что вы строите дом. Ядро Drupal и его API - это фундамент вашего дома. У вас есть выбор, строить этаж за этажом, или раз в 2-3 года все сносить, ставить новый фундамент и строить этажи заново. Если вы каждый раз все сносите, то вы никогда не сможете построить небоскреб.
Теоретически, новое API позволяет быстрее развиваться. Но на практике, существующий, работающий код всегда лучше, чем создание нового, пускай и на более совершенном API. Стоит только врем от времени проводить рефакторинг (приведение кода в порядок).
В любом случае, описанное касается только продвинутых проектов, использующих свою собственную функциональность, заложенную в своих модулях, и не доступную на drupal.org. Если вы используете только готовые модули - тут и обсуждать нечего. Это вас не касается никоим образом.
Есть много примеров подобного подхода. Например, Вебпланета долгое время, ЕМНИП, сидела на старой версии Друпала.
Aviasales в качестве веб-морды к своему сервису поиска билетов долго время использовали 5 Друпал.
В общем, заморозка - отличное средство снижения издержек.
Операционная система Redhat Enterprise Linux имеет срок поддержки 10 лет - это означает, что ее можно не переустанавливать и она продолжит работать и получать обновления. Друпалу до такого серьезного уровня еще расти и расти.
Ни один из модулей ничего не может блокировать т.к. исходники доступны - можно легко все перенести, при желании.
Даже больше - маленький кастомный модуль на самом деле облегчает апгрейд! Да, там свой код, но его очень мало, вы не зависите от переноса на след. версию большого универсального модуля.
Портировать такой кастомный модуль - очень легко.
а если сам заказчик захочет перенести?)
Если заказчик хочет вообще без программиста обновлять свой сайт, ему остается использовать только модули с Drupal.org. Но так бывает только на самых простых сайтах.
Мне вообще трудно представить сайт совсем без кастомного кода. Его может быть очень много хотя бы в template.php
Значит у него появится шанс расшевелить моцг и вырасти над собой
Хаха )))
Я это называю друпальной "кашей из топора". Человека ведется на легкость управления сайтом без программирования, сначала вникает в абстракции и термины друпала, а потом начинает программировать
Вон, Geldora уже всего на расстоянии шага от программирования
Самое забавное, что многие заказчики не понимают, сколько времени и сил было бы сэкономлено, если бы техническими деталями с самого начала занимался профессиональный разработчик, а заказчик концентрировался на своем проекте ))
90% таких сайтов)
Сайты визитки и блоги Василия Пупкина ? На стандартном шаблоне ? Может быть.
ага, и параллельно безостановочно рожал бы новые идеи(уже после утверждения ТЗ), так что про время и силы, это Вы зря, хотя каждая новая идея это $, но все равно мозг выносит, это как, вроде делал визитку с оговоренной стоимостью пару сотен баксов, а на выходе получился портал ценой с хороший автомобиль... главное после этого заработанное еще получить.
Я так и делаю, но, сейчас новые ТЗ умудряются приходить еще ДО того как закончу старые(по принципу:
-такое сделать возможно?
-(прочитав ТЗ по диагонали)типа того
)
пропитьотдыхать, а тут уже набралось на полтора месяца... А ведь "оптовикам" еще и скидка нужна))Кстати что о этому поводу думает 8-яверсия и соответственно, что выбирает разработчик "коробки" - вносит "необходимы модули" в поставку, все остальное API для нужд использования переползает аля MVC и юзаем задумки symphony, т.е. ООП, квалификационные требования к разработчикам модулей выше, использования без доп. кода должно расти
Или он уже "поиспользовал в чистом виде" что-то и теперь ошибки на страницах и конфликты js - не дают ему использовать way
я летом использовал эту связку на 6-ке, все прекрасно встало)
то есть что будет drupalway в случае этого пациента?)
и обязательно хорошему специалисту, который знает апи друпала, как свои пять пальцев и наклепает кучу кастомных решений?)
я тоже не хочу холиварить. просто лично мне хочется понять, когда стоит использовать доп.модули и их апи. а когда нужно написать свой модуль. вопросы квалификации разработчика предлагаю опустить, потому что выше все скатилось к этому. и я считаю это не правильно.
На то, что бы сделать(прикрепить) свое слайд шоу(вплоть до написания jquery плагинов), времени лично мне нужно меньше, чем найти и прикрутить готовое, однако, если мне попалось чужое творчество, у меня все равно уйдет меньше времени на разобраться в чужом коде(при условии что там не полный бардак), чем разбираться, что за модуль там используется и как он вообще работает, ибо этих модулей как собак не резаных, а так же разбираться какого лешего каруселька при генерации вывода грузит проц на 100%, честно говоря, лень.
И еще, на Drupal 7, как, наверное, многие заметили, кодить приходится значительно меньше, интересно, что будет с 8...
Есть такой момент, по сути самый защищенный в этом плане views, однако, от того, что заказчик сломает все остальное, не тронув(ибо не получилось) слайдер, не легче. Так что единственный выход из этой ситуации, это как в никсах, бить заказчика по
яйцамкарману, за работу в системе под рутом(впрочем это касается всего, и винды в том числе, но винда - это отдельная тема)Судя по тому, что творится на этом форуме:
В случае с квалифицированным ламером(то бишь со мной) - если модуль решает проблему на 100%, не создает лишних проблем и его не нужно переделывать(или почти не нужно, плотность хаков ~0.1% считаю вполне приемлимой) - беру на вооружение, иначе кодинг.
В случае с неквалифицированным друпалером - сойдет любой модуль, который хотя бы на 20% подходит, ТЗ переписывается под этот модуль, а если и даже такого модуля нет - тогда либо он заказывается, либо джумла, но чаще выносится мозг обитателям drupal.ru, ибо деваться просто некуда(сбрасывать заказ, каким бы он нибыл, наверное, не хочется). Заказчикам, как правило, пофиг друпал вей там или ... Им главное конечный результат.
Имхо хитро настроенный невообразимыми модулями сайт становится поболее проблемой при возникновении багов и отличий в хотелках к функционалу чем небольшой кастомный модуль. Уже не говоря про понятность для конечного пользователя управления этого всего из админки.
Тут одним глазом не решить проблему, откуда ты знаешь как вся эта куча вместе работает? Это не в сфере ничьей ответственности.
Как сказала Geldora самое главное кто кому делает сайт.
Если человек делает себе сайт, то может сам решать что и как будет работать и какой функционал удастся удачней настроить готовыми модулями такой и останется.
А при создании для других сайта уже на этапе взятия более менее заказа разработчик не может предугадать получится ли это собрать из готового.
И если разработчик намерен использовать только модули с орга - получает дополнительные барьеры на пути создания хорошего сайта.
Друпал и создавался как фреймворк, а иначе смысл тогда программистам вообще под него модули бесплатные создавать если во всем этом разбираться будет нужно только чтобы бесплатно модули на орг писать?
sg85,
про 20% красиво сказано. Похоже на правду ))
natbampo,
Только она это упоминала с абсолютно противоположным смыслом
Ну я про сам изначальный тезис, а дальнейшие ее рассуждения из такого разделения - это ее личное специфичное мнение.
По возможности нужно использовать:
1. Модули с д.орга
1.1. Если используем модуль, то он должен быть с "историей".
1.2. Количество модулей должно быть минимальным, без которых "никак"
2. Хардкодить только в редких случаях - исключениях.
2.1. Свой код только для вторичной функциональности проекта, без которой можно жить.
Как вам такой алгоритм?
Мне кажется модули сильно облегчают жизнь, и фиг с производительностью, гигабайты дешевеют.
Такой подход до добра не доведет. Вы предлагаете "отключать мозг" на эту тему. На самом же деле программист просто должен взвешивать каждый шаг, анализировать. Универсального рецепта здесь нет.
Абстрактность ускоряет прогресс, а то бы до сих пор писали на ассемблере и т.п.
а как быть, если ни один готовый модуль для решения основной задачи не подошел?
если модуль создает загрузку процессора 100% на главной из-за кривого кода, тут уж никакое железо не спасет...
Например, хлебные крошки, можно кодингом быстро сделать сколь угодно сложные, или несколько часов возиться с готовыми решениями, которые, потом еще и могут глючить.
ХулиGUN: как бы всё верно, но спор шаред или впс меня всегда убивал. Если разница в пару десятков баксов остро стоит для владельца, то очевидно, что это говнобизнес и занималься им не стоит.
Кстати, только мне кажется, что у критиков модулей с д.орг есть предвзятость к ним? Я бы даже сказал презумпция виновности. Если модуль с д.орг, то обязательно глючный, обязательно проблемы с обновлением возникнут и т.д.
Давайте поговорим более предметно) В 95% случаев, те модули, которые требуется, либо уже стоят, либо понадобятся в будущем. Обычно это token, entity_api, ctools, для различных галерей это libraries, еще может быть views. Поправьте меня, если я не прав)
Задача
Дано: Кастомный модуль в 12-20 строк.
Найти: Разработчика, который обновит модуль, так как поменялось апи ядра.
Информация к размышлению: на д.орг уже бы выкатили патч.
Информация к информации: На сайте посещаемость 3,5 человека и он работает без включенного кэширования со всеми панелями, вьюшками, ЧПУ и т.д.
Млин. Включить мозг и попробовать ПОИСКАТЬ. Google: Drupal 7 Vimeo Youtube
нужно открыть глаза, и прочитать что народ обсуждает,
а потом повторно включить мозг и попытаться понять)))
имхо: если задача решается своими 20ю строчками против существующего решения с хвостом зависимостей - то уж лучше свое
но с прицелом на повторное использование в дальнейшем ))
а если код с дорг - то не стесняться и долбить ишью (по существу).
Geldora это тема для разработчиков. Вы - разработчик, который по работе создает на заказ сайты?
Хулиган, код форматера в студию. С указанием того, сколько минут у вас ушло на его написание.Должно быть минут 10,не больше?
а если супер секьюрити баг?)
На самом деле можно долго холиварить)
Вот из книги DRUPAL: THE GUIDE TO PLANNING AND BUILDING WEBSITES (стр 34):
как раз про разработку жестко завязанную на модулях. Может у них там так и там такая логика и работает, а у наших заказчиков?
И что много сайтов с 6-ого на 7-ой силами самого владельца сайта обновляются?...
Вообще не заметно, так же сидят на шестерке.
Так что владельцу сайта все равно считай по любому надо нанимать спеца друпалера на переезд. Так что ему нет разницы если все равно платить.
Тупая тема, даже лень печатать... Читаешь доводы некоторых, которые больше похоже упражнения в стохастике-софистике.
Ну давайте тогда все дружно откажется от модулей и будем весь функционал писать сами. Давайте пойдем дальше и будем делать сайты на чистом php.
Встречный вопрос: Это сайт разработчиков drupal?
Модуль: Video Filter
90% случаев людям достаточно модулей с d.org, а ваш случай скорее исключение согласитесь ведь так?
По возможности нужно использовать:
1. Модули с д.орга
1.1. Если используем модуль, то он должен быть с "историей".
1.2. Количество модулей должно быть минимальным, без которых "никак"
2. Хардкодить желательно только в редких случаях - исключениях.
2.1. Свой код только для вторичной функциональности проекта, без которой можно жить.
Читаем подпункты пункта 1
Это тема для тех, кто делает сайты на Друпале, так?
Я - человек, который работает с друпалом уже 6 лет. Но я, если не справляюсь сама, предпочитаю нанимать людей.
Учитывая, что я как раз участвую в обсуждении на 3 страницах... как бэ я понимаю. Но не согласна с большинством участников
Ну и что, что 4 модуля???
Если мне в лень ставить три модуля... то их можно и не ставить, так? (Я бы вообще без форматтера обошлась - настроить фильтры + удобная кнопка в эдитор = результат, который МЕНЯ устраивает = ни строки кода...)
И вообще. Мы обсуждаем, что лучше - море или апельсин.
Имхо, решает не программист
а заказчик. Если заказчик вам говорит - ХОЧУ именно это и ХОЧУ именно так, то разработчик сделает так, как ему скажет заказчик. Это право хозяина сайта решать - останавливать развитие сайта, зависать ли на 5ке или 6ке, или планировать развитие своих проектов. Если я, как заказчик, могу позволить себе планировать найм специалиста для апдейта минимодулей на 8ку - это хорошо. Если я, как заказчик, могу себе позволить оплачивать время специалиста на написание мини-модулей + их тестинг, то это тоже хорошо. Но если я, как заказчик, не могу себе позволить ни того, ни другого - вполне нормально, имхо, сразу указать эти ограничения в ТЗ. Это нормально же?
Программист со своей стороны может (или даже должен - но это уж на ваш вкус) посоветовать, объяснить, почему мини-модуль лучше чем существующее решение. Но вы же не можете навязывать свою точку зрения мне, говорить МНЕ что мой сайт должен остановить свое развитие, потому что вам проще написать 20-30 строк кода?! Это же тоже номральный подход, правда?
Я давным давно в этой теме написал, что решают совместно заказчик с разработчиком. Если решает один заказчик то это самодурство (как впрочем, и в случае единоличного решения программиста). Работать или нет с самодурами - личное дело исполнителя. Правда, у меня большие подозрения, что компетентные разработчики избегают таких вариантов, т.к.достаточно востребованы и без этого.
Вообще, явление коррекции ТЗ под инструмент известно. Только это несерьезный подход - вместо "какие новые функции добавить" думаем "какой модуль мы можем сюда запихнуть". Далеко на этом не уехать. Чуть шагнешь в сторону и уже нет модуля под задачу или они все убогие. Т.е. в итоге - экономить получается, а развивать сайт - нет
Geldora тут права. Заказчик должен решать какие решения ему нужны. Не часто, но встречал в ТЗ, что заказчики требовали использования модулей с д.орг. Применение кастомных решений должно было обсуждаться отдельно и нужно было доказать почему лучше.
p.s. предлагаю чуть упростить спор и применить следующее упрощение, по дефолту считать, что модули с д.орг и кастомные решения написаны правильно.
заказчик должен принять конструктивное решение в той сфере для выполнения работы в которой он нанимает специалиста??? - при всем уважении.. бред!
максимум - совместное обсуждение
а спор - свое или от сообщества, это спор - своя поддержка или своя+сообщество
хулиган спрашивал - не еретик ли он, дак имхо нет, не еретик )))
пока не начал писать свою облегченную но более функциональную версию вьюс и пугать этим сообщество, костер готовить рано )))))
Зачем же вы спрашиваете совета, если уже знаете ответ???
Будьте джентльменом) с девушкой же общаетесь)
подведем промежуточный итог) правильнее с клиентом обсуждать применение тех или иных решений, разъясняя суть происходящего?)
Ну, я же написала
Объясните. И еще раз объясните. Но НЕ РЕШАЙТЕ за меня, потому что это тоже самодурство:
П.С. Я исхожу из того, что и специалист, и заказчик - "нормальные" люди, т.е. есть подробное ТЗ, мы друг друга "уважаем", уважаем чужое мнение, чужое время и т.п.
П.П.С. Лично я считаю за "заказчик"+"фрилансер" и ситуацию, когда человек сам себе делает сайт. Потому что лично я, когда чего-то хочу добиться (те я - заказчик) сразу понимаю, что я - как исполнитель - не могу написать собственный модуль. Иначе говоря, я-то использую всегда только модули с .орга. Если же вы, создавая себе собственный сайт, можете написать мини-модуль, значит вы, как заказчик, выделяете средства на апдейт и поддержку собственных модулей = ваше время как фрилансера. Опять же, тут решает "заказчик".
Это просто бред. Кому - разработчикам хватает модулей для реализации любых пожеланий по сайту????
Скорее тете Моте хватает их для странички о своем коте Степане.
А представляете есть даже сайты которые с нуля пишутся программистами или на фреймворках... Один раз сделался и работает годами и нет парения что вышла какая то новая версия и захотелось.
То как вы научились за 6 лет настраивать модули для своего единственного сайта, и технически возиться с ним, не значит что любой кто захочет себе сайт пожелает стать разработчиком ( как вы) чтобы стать счастливым владельцем сайта. С которым он будет технически заниматься. Ваш случай - очень редкий, а советуете вы для всех ситуаций
Скажите это инферне.
не редкий, если человек делает сайт для себя/заработка
ну так если он для себя делает сайт, это же абсолютно его проблемы как он его себе сделает, при чем тут использование своих модулей? Понятно он не сможет себе модуль написать, использует готовые, поверстать тоже не сможет, берет готовый шаблон и т.д.
я имел ввиду не сам делает для себя, а нанимает кого то. а потом уже в процессе учится администрировать его, в том числе и обновлять.
q2_faith, ну тогда можно им обоим пожелать только успехов
Geldora , ваш сайт не работает:
http://s019.radikal.ru/i607/1212/d8/1240242a845a.gif
Не пора бы обновиться на 8-ку?
Вы читать умеете? По вашему проекты на друпал делают одни программисты? Я не писал "любых пожеланий", но 90% случаев, достаточно модулей с дорга.
А много ли самописных модулей используеть drupal.ru?
drupal.ru - пример того, как не надо делать сайты.
Тогда пишите на чистом php и ассемблере. И что вы делаете на этом сайте?
Это тупое предложение от ламера можешь оставить себе.
То же что и остальные друпалеры.
да они не ответят, они же говорят, что сайт делают себе и поэтому их устраивает если хоть как то получится. Пофиг что у конкурентов в 10 раз лучше, главное не заплатить раз в 2-3 года пару баксов программисту.
давайте возьмем за пример private_message
по заданию меня модуль на 100% не устраивал. я стоял перед выбором, написать новый private_message(гораздо менее громоздкий) или написать небольшой модуль и переопределить вывод этого модуля(был еще вариант сделать это через вьюшку, но вьюшка наотрез отказалась работать). чтобы вы выбрали?
http://drupal.org/project/youtube
http://drupal.org/project/vimeo_link_formatter
Простое поле, работает по простому урлу видео.
2MainVisor, сравните сайты, сделанные ТСом и сайты PromoGroup, это будет самым наглядным примером разницы применения небольших кусков своего кода и модулей с d.org
Интересный вопрос, от ситуации зависит, если в этом модулей устраивает вообще все, кроме его вывода, то можно переопределить вывод, а если же нужна только небольшая часть или половина его функционала, лучше написать свой. IMHO
Еще пример, необходимо сделать так, что бы пропало поле кол-во товара в Ubercart2(т.е. купить можно не более 1 единицы товара), для этого есть модуль(название забыл, restrict_qty что ли), позволяющий ограничить кол-во товаров, однако, по делу там только 2 строчки кода(1 хук, в котором, 1 строчка кода, хрен с ним, с закрывающей скобкой в сумме 3 строчки кода), остальное же, попытка сделать его универсальным(а вот там уже много мусора), т.е. привязать его функционал к конкретным продуктам(даже не к типам), однако, в самой корзине и оформлении поле от этого не исчезло(а вот альтеры там почему-то не привязали), и получается, все равно придется кодить, так как быть с этим забавным модулем? Ставить его и один черт через свой модуль дописывать альтеры, или же не захламлять индексы функций, БД, админку не нужным хламом, а тупо включить этот уберовский хук в свой модуль?
Вообще уберкарт - хороший пример, как не надо писать модули
А что это за пример? В обоих случаях добавится один "самописный" модуль.
Если получится в своем модуле через хуки настроить другой модуль (его не касаясь), то думаю 2-ой вариант очевиден.
Но вы же и против таких настроечных модулей...
ХулиGUN же не про эту ситуацию спрашивал, а когда так, по проще, настроить нет возможности и когда уже требуется лезть и менять код модуля чтобы добиться требуемого.
только объем кода будет разный
я против
самокатоврешений, которые потом тяжело поддерживатьХорошая статья на тему МодулизмЪ VS Custom code
http://mikecr.it/ramblings/drupal-and-invented-here
+1
Хотя в будущем, когда друпал 8 выйдет (не смотрел его но уже наслышан...), может эта проблема и отпадет сама собой
, когда уже не будет экономического смысла программисту разбираться во всей сложноте "программирования под друпал".