30 марта 2013 в 0:20
Делаю социальную сеть на Drupal 7. Планируется 3-5 тыс. пользователей, какое-то (скорее всего, незначительное количество постов от каждого).
Мучают сомнения по поводу использования Views: не раз приходилось слышать мнение, что уже при таких масштабах проекта с Views лучше не связываться, а выводить всю нужную информацию программно.
В то же время очень желательно, чтобы сайт был собран именно из готовых модулей, по возможности, без программирования.
Где в таком случае находится "золотая середина"? Views или нет?
Комментарии
Ну если у вас view используется в 1-2 местах, что сомнительно, можно сделать им замену программно.
На норм хостинге правильно настроенный сайт с 5 тыс. уников должен работать норм.
Лучше смотреть инфу по оптимизации сайта под высоконагруженные проекты.
Думаю, стоит пользоваться преимуществами Друпала, раз они есть.
Рискну вставить свое неопытное слово, которое не могу даже подкрепить какими-либо проектами (за плечами только личный веб-сайт и тот переделыввать надо), но уж очень хочется умным себя почувствовать.
This! Причем always, если интерактива хватает.
Готовая дефолтная cms, это не примущество, это фича.
Цифр я конечно никаких не знаю, но тонкая специализированная работа всегда даст более производительный результат по сравнению с использованием универсальных решений.
UPDATE
Всегда нужно быть готовым что проект получит развитие круче чем предполагалось и что потом писать заново, но уже программно? Можно и так, но лучше сразу, такое мое ИМХО.
Ответьте сначала на вопрос: "сможет ли администратор сайта, при необходимости, поправить код или нет?"
на вьюсе сделаны многие модули, особенно слайдеры... сделать вашу соц.сеть-портал без вьюса сведется к тому что, нужно будет лезть в код для любой правки... 3-5 тыс. это не та нагрузка чтобы отказываться от вьюса
Администратору код править и не надо, у него должна быть своя специализированная cms где он сможет управлять всеми заранее оговоренными возможностями.
В код пусть лезет прогер если надо будет что-то добавить в админку (расширить функционал).
в которых (возможностях) не будет кнопки, например поменять порядок выводимых нод, и что тогда, искать прогера который полезет в код? или лучше чтобы у админа была дополнительная кнопка?
т.е. опять отсебятина, вместо готового модуля, нужно писать свой вьюс, что бы было что-то в админке...
Составлять детальный проект сперва и да, нужно управлять порядком вывода инфы? Добро пожаловать в соответствующий раздел меню. А прогера не искать надо, а просить того (тех) кто занимается проектом.
Не могу уловить смысл.
В общем опять мое желание поболтать мне боком вышло, хочу только сказать что считаю что решать как реализовывать надо не только от предполагаемой
посещаемостинагрузки, а и от предполагаемой сложности и пакеда.друпал без вьюса не друпал, будет значительно урезан функционал... для замены вьюса нужно будет слишком много писать, что оправданно только на больших проектах... да и не так страшен вьюс если включить кэширование внутри вьюса...
Будет все какбы урезано (голый друпал, галочка такая есть) и написано под сайт (с использованием модулей с апи при необходимости), но судя по всему да, такой вариант тут совсем неоправдан.
Ваш код, призванный заменить views, с большой долей вероятности будет работать не лучше, и не быстрее.
Научитесь лучше готовить правильно views, вместо того, чтобы слушать слухи о его медленной работе и прожорливости, от тех, кто этого делать не умеет.
И кстати да, я предлагал вариант "писать" все целиком если уж "писать".
Forbes.ru, на главной странице вьюсов несколько. Как, сильно тормозит?
Не слушайте всякие домыслы, причин использовать вьюзы гораздо больше, чем не использовать. Даже если вдруг так получится, что вьюз надо будет заменить кодом - спроектировать вывод на вьюзе, а потом взять спроектированный запрос и подставить в темплейт - раз в 10 быстрее, чем изначально разрабатывать все представления программно.
Огромное спасибо всем высказавшим свое мнение!
Решение принято: "друпал без вьюса не друпал", так что если уж использовать Друпал, то использовать все его возможности, а если писать - то писать полностью.
В моем случае - решение в пользу Друпал с Вьюс!
Хоть 100 views, главное cache!
Зря рискнули.
Как всегда.
На морде 22 вьюса))))
Вьюсы это конечно круто и удобно, и снижает затраты на поддержку. Но на примере того же форбса - уперлись в производительность вьюсов. Если все его вьюсы переписать на SQL запросы - будет работать быстрее. Если дорастете до такого уровня - пишите свой код. Если маленькая посещалка - оставайтесь на вьюсах.
PS Можете свою систему кэширования написать. Правда в соц сетях и кэшировать то нечего, по определению.
Я к тому, что цена (время) за разработку представляшек с нуля, со старта проекта, вместо переписывания готовых вьюх, не оправдывается разницей на выходе.
Спросите у администраторов с it-patrol чего им стоят сайты на views.
Представим что загружается страница с вьюс.
Что при этом происходит? (шаг 1) Сначала должен загрузится вьюс, (шаг 2) посмотреть в базу и выбрать конфигурацию представления. (шаг 3) Потом он должен соответствии с конфигурацией составить запрос (не всегда оптимально это происходит). (шаг 4) Потом этот запрос исполняется, данные передаются в шаблон.
А теперь что происходит при загрузке запрограммированной страницы. Шаг 1 и 2 просто отсутствуют. Шаг 3 упрощен, запрос уже составлен. Шаг 4 - и представление видит пользователь.
Кто знаком с render arrays, db API, EntityFieldQuery в друпал 7 понмают на сколько это мощная и простые системы.
Думаю что даже при поверхностном рассмотрении ситуации понятно что вьюс просто не может работать быстрее кастомного кода.
Теперь давайте двигаться дальше и пусть наш проект поживет годик. Набралось прилично пользователей, проект перешел к другим разработчикам и клиент хочет поменять что-то очень срочно, причем задача простая например у нас было два поля имя и фамилия а он хочет одно поле с автокомплитом и поиском по имени фамилии. Что мы будем делать? Правельно полезем в хуки вюса, попробуем изменить запрос, в форм альтер поменяем форму. Что-то ничего не выходит. Нужно написать свое поле фильтра. Если это действие увенчается успехом - отлично. Нет - придется переписать на кастом код. Сколько это займет времени в разработке?
Подобные примеры встречаются довольно часто.
Еще вопрос. Как любители вьюса натягивают готовый HTML на друпал? Ответ никак. Нужно верстать почти с нуля. А если еще любитель вьюс является любителем панелей - можно послушать как красиво ругается верстальщик:).
Мое мнение вместо траты времени на изучение views API лучше почитать документацию по drupal (благо для drupal она намного лучше написана чем для views) и нормально кодить под drupal.
По моим наблюдениям (3 достаточно больших проекта за последний год), проект написанный самостоятельно с использование drupal
И еще хочу ответить на вот этот кусочек поста от о k_dmitry
Drupal это:
Как сказал когда-то А. Швец - "Смотрите ядро" и print_r (dsm, dpq) вам в помощь (не дословно).
В схеме с кодом этот шаг тоже будет в полной мере, если конечно речь не о том, чтобы три картинки с подписью вывести. Если менять более-менее сложный вьюз на EntityFieldQuery, получится не только не быстрее, но и медленнее. Хотя бы в силу отсутствия релейшнов, ограничений сущностей по доступу и т.д. Поэтому лишние сущности давайте не будем приплетать
Однако если руководствоваться такой логикой - необходимо вслед за вьюзом выкинуть сначала Field API (потому что кастомные решения будут быстрее), затем render arrays и темплейты (кастомный php побыстрее молотить будет), а следом - и весь Друпал, по той же самой причине. Значительно меньше, нежели создание вывода кодом изначально. Запрос - выдирается из вьюза (и оптимизируется, если не очень нравится как он составлен), темплейт - выдирается из вьюза, а сверху прикручивается фильтр.
А вот противоположный вариант: добавление новой логики в работу вывода (новых полей, фильтров, аргументов и рилейшнов) - всегда быстрее во views, нежели в коде. Ну это уже просто неправда. К темплейтам отлично всё прикручивается, если готовые темплейты не нравятся, свой темплейт или даже дисплей-плагин сделать - очень просто.
Или, пардон, речь о том, что кто-то левый где-то там пилил верстку и не знал, чем занимаются все остальные? Так это проблема организации рабочего процесса, а не инструментов.
На тех проектах, где ставил панели (ради контекстов, в основном), ни разу не ругался верстальщик. Может, проблема в верстальщике а не в панелях? С точки зрения освоения Друпала, views все же лучше изучить (см. гугл по запросу drupal 8 views in core).И каждая из этих частей будет работать медленнее, чем кастомный код, написанный под конкретную нужду. Но повод ли это выбросить все перечисленное?
Вы общались по поводу views с админами которые разбираются также в друпале?
Кеш не в базе хранится, его что запрашивать не нужно? Понятно что он загрузится быстро, но зачем, если этот шаг вообще можно пропустить.
Не подходит EntityFieldQuery - пользуйте DB API
Если мы говорим о друпал как о CMF то выбросить все его прелести просто нельзя.
Основное отличие views от концепции CMF это то что мы программируем продукт в соответствии с потребностями заказчика. А вслучае views просто наклациваем необходимые представления. И последствии все равно придется обращаться к программированию.
Это зависит от того на сколько вы хорошо умеете программировать под drupal.
Зачем "выдирается из вьюза" если нужно просто знать как составить свой запрос?
Речь идет, например, о таком варианте, когда делается быстро верстка, представителем заказчика, она утверждается заказчиком потом передается разработчику. У разработчика есть 2 пути: становится верстальщиком и переверстывать все в соответствии с новой разметкой либо улучшить свои знания друпал и используя систему темизации друпал и готовые шаблоны быстро и легко вывести новое представление.
В чем тут проблема?
<div class="inside panels-flexible-row-inside panels-flexible-row-1-1-inside panels-flexible-row-inside-first clearfix">
<div class="panels-flexible-region panels-flexible-region-1-chiffres_cl__s_and_baner panels-flexible-region-first panels-flexible-region-last ">
<div class="inside panels-flexible-region-inside panels-flexible-region-1-chiffres_cl__s_and_baner-inside panels-flexible-region-inside-first panels-flexible-region-inside-last">
<div class="panel-pane pane-block pane-block-2">
<div class="pane-content">
</div>
</div>
</div>
</div>
</div>
</div>
Правильность, в том что тут нужно было создать свой стиль для панелей. Но на это нужно было потратить время сравнимое с програмным выводом.
Честно говоря не знаю что такое "контексты", но думаю что это легко можно заменить программно.
Будем надеяться что использование views не будет обязательным для составления представлений.
В одмом из интервью (не смог найти) Дрис очень хитро улыбнулся на вопрос о том будет ли views в ядре восьмерки и сказал что пока не ясно. Это старое интервью, когда еще не было принято решение будет ли views in core.
И вьюс работает поверх всего этого, а поверх вьюс работаете вы. Вопрос: зачем?
[URL=http://hostingkartinok.com/show-image.php?id=60d26360bcda35478902e1be039...
Если можно работать на прямую.
Во-первых, вовсе не обязательно придется к чему-то там обращаться - всякий раз всё зависит от конкретной ситуации.
Во-вторых, каждому, конечно, свое, но лично мне ближе сделать макет страницы за час, а потом еще за час переделать его (если уж очень надо) в код, чем сразу тратить значительно большее время на страницу в коде. Разумеется. Чем лучше умеете, тем быстрее преобразование вьюхи в код. Чем хуже - тем дольше. То же самое справедливо и для кода "с нуля". Затем что во вьюзе запрос уже составлен, и если к нему никаких претензий нет - скопировать его проще и быстрее, чем составлять свой заново. На порядки.
Что мешает "быстро и легко вывести новое представление" в шаблоне вьюза, который ничем не хуже всех остальных шаблонов? Заменить программно можно все что угодно, т.к. "заменяемое" тоже сделано программно. Речь идет о том, что в ряде случаев нет смысла изобретать велосипеды, когда уже сделаны готовые. Конечно не будет. Сейчас полями пользоваться тоже необязательно, хоть они и есть в ядре. Во-первых, не "всего"
Во вторых - и что дальше? Любое API - это тоже надстройка, которая тоже работает поверх чего-то и априори имеет какой-то оверхед. Я все время говорю об одном и том же: о том что этот оверхед не может являться причиной отказа от чего-либо в отрыве от других плюсов и минусов. Затем что ценю свое время и прекрасно вижу, как использование views сокращает почти все этапы в жизненном цикле ПО.
Шаги 1, 2 в кеше.
На втором этапе, когда количество пользователей перевалит критическую отметку, можно переписать/заказать часть кода.
поясню мое высказывание, сайты без вьюс или совсем простые или сайты где программисты делают оптимизацию под большую нагрузку, вюьс делает друпал доступнее, администратор сайта без особых знаний в пхп может настроить представление "под себя"
Согласен, но это плюсы для разработчика, а не для конечного пользователя
Специально для Ilami:
мадемуазель, если у вас,как у разработчика ресурса на базе drupal,
возникает вопрос использовать или нет views,
то ответ однозначный: использовать.
аргумент: постановка вами вопроса свидетельствует об отсутствии реального опыта разработок на базе drupala, и соответственно написанный вами код не будет оптимальным и быстрым.
задел на будущее: расцените drupal7+views как инструменты для создания прототипа ресурса.
и далее, на уже работающем оцените фактическое положение дел - тогда уже и решайте, что переписать.
Mr qraker, здравствуйте! Как ваше настроение, mr qraker? Надеюсь не очень и я смогу его еще больше испоганить своим обращением к вам.
Не побоясь того что вы меня безжалостно втопчите в грязь или в лучшем случае просто проигнорируете, я все же позволю себе брякнуть кое-что даже не смотря на то что сам не хотел с вами общаться.
Чегож вы так рано остановились? Сказали бы что и zend надо переписать, а лучше вообще новый интерпретатор написать, да и новый протокол связи разработать. Граница это рендер массивы и form api, остальное по требованию, но оно всяко быстрей и гибче будет чем "система запустить все, а использовать только малую часть".
Простите, а на кой хер дизайнеру знать чем занимаются остальные? Его задача сделать html шаблоны и точка, не?
Сдерзить - это ваш стиль, всегда буду искать повод подгадить вам настроение, пусть и не сейчас.
Спасибо, mr qraker, за внимание!
К счастью, мое настроение не зависит от того, что малолетние дурачки пишут в интернете. Можешь особо не тужиться - заодно время появится мат.часть подтянуть.
Но желание "подгадить" тебя снова хорошо характеризует, да.
Вообще-то задача дизайнера - сделать дизайн, все что дальше psd-файла - это уже верстка.
Вопрос нужно ставить так - стоит ли вообще использовать Drupal ?
Views это фундамент Drupal, модуль с которым интегрированы сотни других модулей. Отказываясь от него, разработчик отказывается от огромного пласта готовых решений.
И что мы получаем в итоге ? Фреймворк ? Ну так как фреймворк Drupal очень слабый. Поэтому отказ от Views выглядит очень глупо - взять систему и выкинуть из нее самое ценное.
Да, Views имеет некоторый overhead. Но он никогда не станет у вас на пути - любую из его частей можно легко заменить или отключить. Стоит ли использовать пласт готовых решений, потеряв при этом чуть чуть производительности ? Мой ответ - да, если вы выбрали Drupal ради готовых решений. А если уж отказываться от готовых решений, то тогда надо брать более мощный фреймворк и делать сайт на нем. Если вы от Drupal используете только API то вы сам себе злобный буратино.
Чуть не забыл
Забегая далеко вперед предсказываю судьбу drupal 8 такуюже как пророчат windows 8, но об этом больше я пока ничего говорить не буду.
Испльзвать возможности друпала надо исходя из задачи.
Мне почему то кажется что Дрис не очень то хотел видеть views в ядре. Но сообщество. Что поделаешь...
А для кого я писал это ?
Или у вас ставится задача максимально усложнить разработку, сделать ее более трудоемкой и дорогой для заказчика ? Мосье мазохист ?
Как раз все на оборот, хочется сделать все быстро и максимально дорабатываемо в будущем. А не быстро напили за 500 грн. сайт, спулил заказчику и забыл. А что с ним будут делать последующие разработчики уже значения не имеет?
"быстро и максимально дорабатываемо в будущем" - это на Views. Это если оценивать разработку сайта целиком. Отказались от Views - отказались от готовых решений и все кодим сами - стоимость и сложность разработки выросла.
Почему отказались если views так хорош?
Это я ваш алгоритм действий описываю, а не собственный опыт.
Это не мой алгоритм. Вы что-то спутали.
Ну вы же защищаете идею "отказаться от Views" ? Или я что-то путаю ?
То что отказ от views влечет увеличение стоимости разработки это ваше предположение или опыт. Не мой.
епт, неужто у вас настолько говеные сайтики, что прибыль с них заставляет задаваться подобными вопросами?
вьюс говно
+1
Хотя видал и похуже.
Dimasikov и Andruxa вопрос к вам, как без вьюс реализовать календарь, например афишу?
ПФФ))) У меня консультации платные. Также у меня есть готовый модуль который могу кастомизировать под ваши потребности.
1. мне ваша консультация не нужна, хотел увидеть обоснованный ответ "против вьюс" на конкретном примере
2. если "своего модуля" не было, сколько бы стоила разработка?
Как вы будете реализовать вариант, если клиент например захочет при клике на событие редактировать его, только без перезагрузки страницы, а чтоб форма подгружалась и сохранялась ajax, как в гугл календаре?
ну, каким-то лютым самописом, видимо
в моём предыдущем посте фильтр вырезал тэг сарказм
Если нужен красиво отформатированный сборник сочинений то гоу вьюс гоу!
Если нужна куча интерактива, то нужно писать мозги с нуля.
П.С. Это не опыт, это логика.
2П.С. Поставил в профиле 'Получать уведомления по e-mail о новых комментариях.:' => 'Нет уведомлений', все равно прут! Чего это они?
3П.С. Убрал галку 'Receive content follow-up notification e-mails' может она поможет, хотя должна-ли? И к чему эта галка вообще тут?
не знаю, наверно писать свой модуль или заказывать отдельно, как дополнение к вьюс+календарь... код скорее всего будет такой же как в своем модуле (без вьюс), только нужно писать не весь модуль а только дополнение...
Я знаю как сделать и c views и без него, с использование технологии AJAX, потому что делал (с использованием друпаловского ajax фреймворка). Без views все же проще.
Хотя если ситуация позволит создать нужную ссылку через views то как то уже все равно)))
не совсем аякс, но примерно так http://xandeadx.ru/blog/drupal/426
Я думаю что еслиб мистер qraker был на другой стороне, он бы написал: "OMFG"!
П.С. А письма все равно прут, админы сбросьте кэш плиз!
ну может не кошерно, но все же, это можно решить на уровне темизации:
1. сделать как тут http://xandeadx.ru/blog/drupal/426
2. в файле темизации сделать проверку на админа, если админ то вывести форму редактирования с display:none и кнопку при клике по которой через js форма будет выводиться в поп-ап как тут http://drupalace.ru/lesson/pop-login-pri-pomoshchi-javascript
это так, решение "на вскидку"
что за OMFG?
Это очень плохо. Не делайте так. Благо в 8 вы так уже не сможете делать, это плюс.
Oh My Fucking God
спорить не буду, т.к. писал выше что не знаю как это сделать, но думаю чтобы из друпал вьюс-календаря сделать гугл календарь, нужно написать дополнение которое займет на разработку меньше времени чем писать весь календарь без вьюс.
А вы по моей честно признаюсь не самой удачной фотографии (у меня с ними проблема) о моем возрасте узнали или это снова ваша телепатия? Или мне должно быть 40 лет чтобы что-то тут писать?
А по поводу того что именно вы посоветовали подучить матчасть ответ один -
И не давайте не будем говорить что кого как характеризует, а то действительно времени на матчасть у меня будет мало.
Мне параллельно, что ты там кому хочешь разжевывать - я не к тебе обращаюсь. С тобой предметный разговор вести бессмысленно, интересного мне ты тоже ничего не расскажешь.
Дизайнеров верстальщиков в природе не существует? Или опять надо разжевать и объяснить что имелось в виду именно человек который делает верстку.
Только слово "малолетний", остальное ваш обычный способ общения.
Верно, это мой обычный способ общения с малолетними дурачками. С остальными общаюсь иначе, да.
Воспользовавшись информацией с вашего сайта, а также исходя из того что вы утверждаете (и пишите в разных топиках) возникает вопрос, почему вы так недолюбливаете себе подобных?
Малолетнего дурачка легко вычислить и без фотографии, которая кстати ни о чем не говорит. Например, всякий малолетний дурачок имеет мнение по любому вопросу, в котором совершенно не разбирается. Также любой малолетний дурачок не имеет ни желания, ни способности к обучению. Например, вместо того, чтобы научиться правильно расставлять буковки в коде, малолетний дурачок выдумывает собственный стандарт написания говнокода, чем немерено веселит окружающих.
Малолетний дурачок - это не возраст в паспорте, а образ мышления.
Печаль. Выводы этот пост тоже заставляет делать, но поймете-ли вы хоть что нибудь, вряд-ли, а потому ок, буду малолетним дурачком.