Deploy на shared-хостинг, как с этим жить

Кто против то?

Написать аналог ACF в моем движке это неделя работы. Напишу. Но ПОЗЖЕ. :)

Интересно почему?) Делаем аналог MU, но уже внутри конкретного блога, т.е. в Мультиблоге есть блог со своим царем и богом, а у блога есть категории, в каждой есть царь и бог этой категории. Нормальная ситуация.

Представил. И что? Это другая задача, с другим кодом.

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

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

Никак. А зачем меня это должно волновать? Это как раз классическая ошибка.

Видел как чувак рассказывал свою историю.

Начал писать на новом ему языке и фреймворке. Написал код на 100 строк. Потом начал изучать движок и подобавлял кучу проверок исключительных ситуаций. Потом разобрался хорошо и убрал все это нафиг вернувшись к тем же 100 строк с которых начинал. Так и здесь. Запрет комментариев ВООБЩЕ не касается этой задачи. От слова совсем.

Значит в ее шаблоне не будет вывода этой аватарки?)

Ну черт с вами. Давайте тогда так:

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

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

Так что в максимальном варианте это будет массив массивов массивов аватар.

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

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

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

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

1) У комментария должно быть свойство post. Если его нет - получаете полноценную ошибку, которая связана с обращением к несуществующему свойству. В результате скрипт падает, на выходе белый экран и ваш телефон разрывается от звонков клиентов;

2) Если у объекта post нет свойства category или оно возвращает что-то отличное от объекта со свойством owner, то вы также получите ошибку;

3) Если у объекта owner нет свойства avatar, то вы также получите ошибку.

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

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

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

А с чего ему там вдруг не быть?)))

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

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

Еще раз - когда я разрабатываю проект, то я стараюсь продумать структуру, и таких потеряшек быть не может. Сущность комментария обязана иметь того кого комментировать. Всё.

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

owner в нашем примере это экземпляр модельки User

Если у юзера нет аватара как свойства, то очевидно что вьюв аватара не попадет в шаблон комментария. А если в системе предусмотрены аватары, то свойство будет в любом случае. Это же объект "картинка", ему в любом случае надо выдавать дефолтное значение. Но даже если дефолта нет, и вернется пустая строка, то ничего страшного, он же сам и поймет что его выводить не нужно. Всё в конфиге прописано (в будущем - в админке).

Их не нужно отслеживать потому что они не могут произойти.

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

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

Гы. А теперь представьте проект в котором несколько сотен... нет не строк. Классов.

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

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

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

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

Вам всё-таки нужно разжевать почему данная одна строка кода вообще никак не связана с запретом комментариев, или вы всё-таки догадаетесь сами?

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

Вот тут соглашусь. Пожалуй нам с вами не стоит продолжать эту тему. Все что я мог полезного от вас получить, я получил. А дальше уже не тот уровень понимания...

---------- Добавлено 22.07.2016 в 20:57 ----------

Было и такое. Лет 5 назад. Только оно вышло больше похоже на урезанный yii1 и со слабеньким ORM. По факту модельки выходили слишком толстыми, и местами попахивало вордпрессом. Но опыт был интересным и полезным. Проекты на том движке до сих пор живут, и все довольны.

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

?

В общем, все тут и так понятно, обсуждение смело можно заканчивать.

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

Это как? ORM на ORM Yii? и что в итоге? Интересно для общего развития и понимания структуры создания проекта.

В свое время с YII поигрался, понравилось, но в итоге не стал разбираться досконально

Может вы мне предлагаете еще и такие конструкции писать?

Не, ну а чё? А вдруг произойдет ошибка? Пацаны ведь стараются, тесты пишут. Может и мне написать?

Еще раз. И по буквам. Не для вас уже собственно, ибо свою возможность реабилитироваться вы упустили. Объясняю в чем лажа с "запрет комментариев".

Если у поста запрещены комментарии, то у нас не может появится комментарий у которого родительским постом указан пост у которого запрещены комментарии. Если запрет был установлен после того как комментарий появился, то закономерно, что этот комментарий будет по прежнему виден, как это обычно и делается во всех системах комментариев. Если же при разработке ТЗ будет принято решение что при установке запрета - существующие комментарии скрываются или удаляются, то это тема никак не уровня комментария, а уровня поста. В модели поста метод запрещающий комментарии просто поставит соответствющий флажок на комментарии. И уже КОНТРОЛЛЕР а не шаблон будет решать выдать ли тут 404 или 403, или не заморачиваться а таки показать, коль ссылку то ты знаешь.

Single responsibility principle. Когда я пишу вьюв для отдельно стоящего комментария, то я не имею права задумываться о том, что кто-то, где-то, что-то может себе придумать. Я решаю конкретную задачу. Конечно сохраняя все остальные принципы в том числе и принцип бабушки Барбары)

Нет-нет. Или я неудачно выразился, или Вы не совсем поняли.

Я говорил что проект был ПОХОЖ на Yii. Но писался он на чистом пхп. Ну только используя некоторые свои старые библиотеки, которые еще со времен пхп4 со мной были. Потом я проект бросил и перешел на Yii в силу того что он был уж очень круче чем мой движок.

Хотя некоторые решения у меня были удобнее.

Ну тут две причины как по мне бывают:

1 - ну это же так просто сделать, я такой крутой, ща всё сделаю побыренькому, и все меня похвалят

2 - не устраивает то что есть, и хочется чего-то большего

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

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

Почему я начал опять писать свой велосипед? Я хочу движок который будет понятен для домохозяек вроде TiA, но при этом предоставлять все прелести современного мира (Нормальный ООП, т.е. DRY, SOLID и т.п., MVC, composer, удобный и гибкий инжектор зависимостей, заготовки под удобное мокание и прочие прелести тестирования, ну и т.п.). Чтобы из коробки было. Чтобы пришел программист в сайт сделанный верстальщиком, и мог писать что-то дальше, а не выкидывать всё и начинать заново....

mendel, Ясно, спасибо за разьяснения) Планы амбициозные, ничего не скажешь.

Вот поэтому я и перешел на Джангу)

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

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

В Yii для решения этой простой задачи достаточно просто добавить в модель комментария магический метод getAvatar, который будет просто подгружать аватарку нужного пользователя из соответствующей модели. В итоге вывод аватарки сведется к $comment->avatar. Отключение комментариев в этом случае делается элементарно: для модели записи добавляется метод getCommentsState, который берет на себя все проверки. Если он возвращает true, то подключается модель с комментариями и выводятся комментарии.

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

В итоге поддерживать и дорабатывать проект на Yii или все том же WordPress на порядок проще, чем ваш велосипед.

Да таких наполеонов.. :)

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

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