mendel

mendel
Рейтинг
232
Регистрация
06.03.2008
SeVlad:
Ну это просто эпикфейл.
Не, фейс (и да, отличный фейс) и простота понимания (юзабилити) конечно сыграли роль в популярности винды. Но вот только в 198x-199x не то, что линуха не было, но были конкуренты, у которых, собсно этот фейс во многом и был стянут. Причина же популярности несколько в другом.
А если ты имеешь ввиду не линукс, а юникс, так он изначально затачивался не для хоумюзеров. И в своей нише (серверов) он был лидером.

Вы помните как во времена вин3.11 "сервер под виндоус" было анекдотом? Шуточки всякие ходили и т.п.

Потом как-то не так смешно стало когда это стало правдой.

Причина простая. Нет, не в том, что чуваки улучшили ось. Это уже следствие.

А в том, что ее лучше знали.

У меня в то время был сервак под ДОС. Фидошная нода крутилась.

Мне всего хватало.

Потом ближе к закату Фидо она уже жила в Вин95. Иногда. Иногда в Дос загружал, но если нужна была многозадачность то запускал ее в винде.

Линуховый сервер на том же железе у меня завелся не потому что он лучше решал мои задачи, более защищенный и т.п. - просто не было подходящего софта под винду. Собирать руками, патчить и т.п. было глупо. Сейчас всё тот-же софт уже и под виндой прекрасно живет.... Да и сейчас сижу под виндой, хотя весь софт что использую изначально или виндовый или кроссплатформенный. Но разбираться с драйверами и т.п.? Та ну нафиг.... "Та ну нафиг" это вообще движущая сила нашего времени)

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

В том и суть. Функционал вордпресса достаточен для блога. Но чуть дальше и нужно делать надстройки, чтобы вместо 15 символов делать 3 строчки. А вместо 30 символов - 10 строк.

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

Не будет.

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

Дальше уже мы по этому ид получим аватарку.

После чего мы можем уже проверять что она существует, выбирать размер и т.п.

TiA:
$queried_object = get_queried_object();

это все еще половина от половины) Я не вижу здесь $vendor_id.

Просто вы ведь не под вордпрессом пишете а под ACF а изучать ненужный мне "фреймворк" чтобы написать пример за вас, это уж слишком)

TiA:
Да, в 15 строк у меня не получилось вложиться.

Ну да, если я правильно помню тут выйдет 10 строк а не 15.

Запрос комментария

получение ид поста

запрос поста

получение ид категории

запрос категории

получение ид оунера

получение оунера

получение

и

вывод аватарки.

Ну и плюс еще пару строк "главного цикла".

Но все зависит от того как вы сделаете вывод комментария отдельно. Тут или куча кода, или опять говнокодить на "записях".

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

А мой фреймворк хорошо поддерживается мною, и я даже писал раньше под вордпресс. Но какое это имеет отношение к вордпресс?

Если бы ACF был бы частью вордпресс или хоть написан компанией вордпресс, то да, можно было бы его к вордпрессу относить, но при чем тут какой-то сторонний плагин?)

Вы пишете на ACF который требует для себя вордпресс.

Вы используете синтаксис ACF а не вордпресса.

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

TiA:
PSR-1 позволяет использовать как полный, так и сокращенный синтаксис, стандарт оформления кода WordPress разрешает только полные PHP теги.

Серьезно?)

То-то я смотрю в ВП везде пишут


<?php if ( have_posts() ) : ?>
<?php while ( have_posts() ) : the_post(); ?>
...
<?php endwhile; ?>
<?php endif; ?>

Если же вы про <?= и т.п. то все равно не совсем верно. PSR запрещает <? а разрешает только <?= и этому есть внятное объяснение. Я спорил с участниками PSR и меня убедили почему это можно, а это нельзя)

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

TiA:
В OpenCart можно относительно быстро написать свой модуль и не городить лишний раз костыли. Вам же потом это все поддерживать.

Быстро наговнокодить можно что угодно. Но зачем?

Говнокода тут два:

1 - если пишешь на Опенкарт то это говнокод по определению.

2 - я не стал копипастить админку модуля html а прямо использую его данные для подстановки в текст по хештегам (аналог вордпресовского [названиеБлока] в тексте статьи). Это не столько лень, сколько разумный выбор - один и тот-же текст может использоваться и как блок в дизайне, и как текст в описаниях/статьях и т.п. На эту мысль вы же меня и натолкнули, используя записи там где надо и не надо...

ПС: так я что-то не услышал как же вы собираетесь выводить комментарий отдельно?)

---------- Добавлено 22.07.2016 в 11:58 ----------

SeVlad:
И да. "Каждый кодер должен написать свой движок, что бы в конце-концов прийти к ВП" (с) не моё

Нее. Это уже было. Правда пришел не к ВП а к юии.

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

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

SeVlad:
Да, "таксономия" - не выдумка вордпрессеров

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

SeVlad:
По поводу ВП ты сильно отстал от реальности.

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

Я видел даже что в вордпрессе некоторые городят плагины для псевдоMVC))

Но суть то от этого не меняется.

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

Ну это его основное преимущество.

Зазубри кукбук и поехали.

Чисто за счет кухарок он и оброс кучей плагинов и тем.

Чисто за счет кухарок его админка известна всем.

Почему винда обогнала линукс? Именно поэтому.

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

Именно благодаря домохозяйкам.

$vendor_id

Это только половина кода, ведь $vendor_id еще получить надо.

Итого 5-6 строчек нечитабельного кода вместо одной строчки.

И на выходе специфичный код зависимый от плагинчика и в принципе не поддерживаемый самим вордпрессом, т.е. пишем на ACF а не на вордпрессе.

TiA:
Отдельно один комментарий можно вывести с помощью функции get_comment.

Не в тему. Функция то есть. А вот механизма вывода нету. Куда ее вставлять?

Как создать страницу где оно будет выводиться? Как генерить на нее ссылку? Как при желании изменить формат ссылок их менять? Мне нужно сделать вот так. Как это сделать в вп?)

Если дополнительное поле с аватаркой связать с пользователем, то оно будет выводиться абсолютно так же как показано выше с той лишь разницей, что вместо vendor будет user с соответствующим ID

Именно!

Только вот получение этого ИД, как и в прошлом примере вы "забыли". А оно будет строк на 15, если вы удосужитесь прочитать задачу, а не ограничитесь своими предположениями. Юзер не у комментария а у категории.

---------- Добавлено 22.07.2016 в 01:50 ----------

А с Вами чертовски полезно флудить)

Понял что даже для верстальщика нужно вводить стандарты кодирования.

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

Присвоение в условии опять же.

Стандарт уберет споры о том что важнее - чистый код или экономия одной строчки... Сказал "у нас такой стандарт" и всё, тема закрыта.)

TiA:
Для термина таксономии "Производители" просто добавляется еще одно дополнительное поле с картинкой. В случае с ACF делается это через админку без правки конфигов. Само изображение можно вывести в шаблоне через функцию get_field в нужном размере и с нужными метаданными.

Ну вы код приведите)

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

У меня одна строчка в конфиге, у вордпресса одна строчка в конфиге, разницы нет.

Вы код для вывода картинки приведите. Который в шаблоне товара будет.

Он конечно не намного страшнее будет, но вот к примеру другой вариант:

У постов есть комментарии и категории где эти посты расположены.

У категорий есть "владелец", т.е. пользователь ответственный за этот раздел.

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

У меня это будет что-то вроде

<?=$comment->post->category->owner->avatar;?>

Для ВП это почти непосильная задача.

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

Нашли мы пост, потом по его ид находим категорию, потом по ней владельца, и уже у владельца аватару, которую засовываем в генерацию картинки?

---------- Добавлено 21.07.2016 в 23:37 ----------

Capistrano, Chef, Puppet, Ansible, Vlad the Deployer, Rex, Rocketeer, Phing

Кто все эти люди?)))

А если серьезно, то беглый гуглеж:

Capistrano - руби, нет винды

Chef - явный оффтоп. И руби, "и вообще"

Puppet - руби, да и причем тут шаредхостинг вообще? Нет, ну вот каким боком?

Ansible - питон. Почему не руби?!!!!!один. (опять таки, ну причем тут деплой на шаред?)

Vlad the Deployer - ну наконецто! А то подсовывают нам питон какой-то....

Rex - Перл??!один Что за перл такой? А где руби?

Rocketeer - php? правда чтоль?))

Phing - еще php? Где вы видели пхп на шаред хостинге! Верните руби!!!один1

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

Смотрите.

Вот кусочек из конфига моделек из живого простенького магазина.

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

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

Еще отличия от Юии - правила распространяются далеко не только на валидацию.

В частности article от строки отличается тем, что в активформ генерится TiniMCE или другой какой редактор, я не помню уже. Есть в шаблонах, можно поменять.

Ну и конечно правила для сохранения, правила после чтения (что покрывает 90% всех кейсов бефорСаве и АфтерЛоад и прочих) и другие правила.

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

Контроллер пока да, создается, но только на фронте. В админке это уже просто запись в конфиге такого вида.

Здесь мы указываем по сути только по каким полям возможна сортировка да какие поля в какую вкладку засовывать.

Список полей с их типами по которым уместен поиск, как вы наверное заметили - в сценарии поиск, в конфиге моделек.

Ну конечно тут еще конфиги с языковыми строками идут, но это думаю очевидно.

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

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

Но согласитесь, что сделать в шаблоне товара что-то вроде


<?=$product->manuf->thumb?>

это не сложнее чем в ВП писать (да и кстати как вы в шаблоне выведете логотип производителя товара? Плясками?

Сейчас у меня ключевые задачи это:

1 - отделение админки от фронта

2 - улучшение кода в плане стандартов, внедрить нормальную работу с неймспейсами и т.п., подчистить чуть костылей

3 - унификация контроллеров с выносом их настроек в отдельный конфиг, здесь же убрать костыли из роутинга (аналоги урлКонтроллера)

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

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

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

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

---------- Добавлено 21.07.2016 в 16:05 ----------

ПС: кстати вот прямо сейчас сажусь гвонокодить в том стиле за который Вы тут ратуете) Буду использовать в последнем моем магазине на опенкарте модуль ХТМЛ-содержимого не по назначению)

TiA:
Вы, наверное, неправильно меня поняли. Таксономия и тип записей - это не записи и категории

Я вкурсе. Я когда говнокодил на ВП пользовался всякими Pods. Сейчас уже деталей не помню, но общую картину помню. Костыли над костылями.

ВП это движок для блогов, ну максимум сайт-визитка с несколькими разделами статей да блогом новостей компании. Всё. Дальше уже говнокод идет.

TiA:
В этом нет смысла. На WordPress есть чудесный плагин WooCommerce

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

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

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

Вы понимаете что VQMOD это бред, но не видите что использование сущности записи под всё это говнокод. Ну да это вопрос опыта. Когда есть с чем сравнивать, то понимаешь разницу. А когда опыта не хватает, то можно и не по делу использовать инструмент.

TiA:
К сожалению, аналогов ACF PRO для других систем я пока не встречал.

У меня есть нечто подобное)

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

Но пока движок сыроват, выкатывать на паблик рано, да и есть вещи которые важнее по функционалу а не по красоте...

Сделать можно всё. Вопрос в количестве кода.

Сделайте функционал ОпенКарта (про него вы кстати не ответили) на вордпрессе, и у вас получится.... опенкарт)

Вообще в некотором смысле вы правы. Для блогов ВП хорош. Особенно если использовать проверенные темы и плагины.

Простенький сайт с десятком разных сущностей на ВП или на нормальном движке делать примерно одинаково. На вп может даже проще потому что много готового под него есть.

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

Портянки копипасты, портянки костылей, лабиринты процедурной каши...

Сделать можно много чего. Даже VQMOD придумать. Но вот зачем?

ПС: а вообще занятно. Если всё можно сделать, то чем же оно хуже?) В голове пролетают кучи вариантов, но понимаю что лет пять назад я бы их не воспринял.

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

Мир жесток и несправедлив)))

---------- Добавлено 20.07.2016 в 19:13 ----------

Sly32:
За фреймворками будущее)

Ну я как раз сейчас и пилю свой фреймворк с куртизанками и покемонами.

Так что мне это доказывать не нужно.

Хочу совместить простоту вордпресса и возможность программировать без программирования с нормальными подходами.

Пока глубокая альфа, но уже все задачи что раньше писал на ВП решается на раз.

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

Т.е. простота вордпресса и функциональность полноценного фреймворка.

Черт, вот как жить без миграций?

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

TiA:
Зачем изобретать велосипед и писать вручную код для работы с какой-то очередной сущностью?

Баннерокрутилка.

Плагин автогенерации метаполей и наименований для перелинковки (прописываем у каждого товара несколько блоков "похожие", "рекомендуемые" и т.п., с РАЗНЫМИ названиями для улучшения внутреннего ссылочного, но писать эти разные тексты руками не хотим, а хотим чтобы если оно заполнено, то выводилось из базы, а если нет, то выводилось по алгоритму, а список алгоритмов настраивается).

Биллинг - счета, оплаты. Да даже корзина.

Тикет-система.

Хранение писем из фидбека в базе а не только отправка на почту.

График занятий для учебной группы с календариком (дни, занятия, преподаватели, группы, номера "уроков" и время их начала).

Шаблоны для почтовых рассылок и т.п.

Это так. Навскидку.

Всё это подразумевает ту или иную CRUD-админку.

Всё это делать записями? Под всё это городить права, фиктивные шаблоны чтобы они выдавали таки 404 там где не нужно или другие извращения? Оставлять лишние поля и т.п.?

Ну это так, по памяти. Уже год с ВП дела не имею и функционал забыл как страшный сон.

---------- Добавлено 20.07.2016 в 17:21 ----------

TiA, глянул Вашу подпись.... Опенкарт.

Скажите еще что Опенкарт нормальный движок в котором всё есть)

Вордпресс просто старый. И у него возрастные болезни, плюс нецелевое использование. Те кто называют его УГ - не совсем правы. Но Опенкарт.... это проклятие а не движок.

TiA:
Многие популярные плагины разрабатываются целыми командами разработчиков в соответствии со стандартами оформления кода

Нет, конечно есть и нормальные плагины.

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

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

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

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

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

Всего: 1906