Как вывести комментарии в нужном файле шаблона tpl?
Оформляю главную страницу и хочу разместить на главной вместо списка постов, блок комментариев. Что то вроде стены на главной.
48 комментариев
Не ужели не могли сделать что то вроде:
Я писал плагины под Joomla, WordPress, Prestashop, а тут чего?
Я писал плагины под Joomla, WordPress, Prestashop, а тут чего?
и лс — ничего из вышеперечисленного. ознакомтесь что внутри продуктов из вашего списка и как устроен ЛС. здесь говнокодить весьма затруднительно.
Трудно было сделать чтоли 1 php для функций(например init, displayAdmin,displayHook) и вывода на сайте и в админке, 1 xml для информации о модуле в админке и все.
Конечно, напхали ООП всякого.
Пусть берут пример с PrestaShop! Я вот честно легче написание модуля я не видел. Когда разобрал первый модуль офигел! Все элементарно просто до ужаса. Два файла и модуль уже будет работать, без всяких извращенств. Namemodule.php и config.xml все!
А говнокодить можно везде если руки растут не от туда. И не стоит строить из себя «сверхумного» плохая привычка. Я говорю исключительно по факту.
Это означает что вы не понимаете что есть другое программирование кроме как процедурного.
Вам хочется по-быстрому все в один файл накидать потому что это нужно «здесь и сейчас», без планировани архитектуры. Да какая архитектура, да? Если бы вы писали крупные проекты, то знали что без хорошего разделения логики код «в одном файле» — это головная боль.
Примечание: В лс тоже есть хуки, если что, кроме целого вагона других возможностей.
Стремится надо к простому решению, а не к тому «как умеею так и делаю» и брать лучшее из других.
Вот как раз ваше описание «все в одном файле» — это один худших примеров кода, задумайтесь.
Итак, резюмируя: ваше «простое решение» осталось в прошлом веке, поэтому найдите время изучить какие архитектурные принципы используются в хорошем коде сегодня. Потому что то, что вы пишете — настолько безграничное заблуждение, что на некоторое время показалось что вы тролите. Конечно, если вы писали под вордпресс, то вам кажется что такой же код должен быть везде, но, к счастью, это не так. Вордпресс популярен, но код его — какашка. И вы должны об этом знать.
Я еще раз повторюсь посмотрите на ассортимент плагинов точнее на их количество и на цену их, может так понятно будет почему в других в той же престе они стоят раз в 10 дешевле.
Разный размер сообщества, количество разработчиков в штате вы не берете в счет?
Вы классический «застрявший» программист, который считает что процедурный стиль программирования должен торжествовать везде т.к. любимый вп на нем. И с болью осознаете что прогресс давно ушел дальше.
Возможность кодить в смарти никуда не далась, там в трешке запрещена возможностьявно прописыватьphp
возможность «как» это делать. это уже касательно безопасности.
а ветвления вывода в зависи от переменной никуда не далась
Просто для примеры, я когда беру КМС любую обычно они содержат модули и в стартах всегда почти есть модуль комментариев. Который выводится в новостях типа:
Т.е. я могу в любой шаблон вставить его и на страницах, где используется шаблон будет фигурировать модуль «комментарии», где пользователи могут писать свои мысли.
— выводит заголовок новости к которой относится комментарий, если, допустим, в разделе Статистика нажать на «Последние комментарии», то вы увидите список последних комментариев с заголовками новостей(являются ссылками на новость) к которым они относятся.
— выводит иконку группы
— выводит название группы
Меняем форму:
За основу я взял таблицу которой мы оформляли блоки, растянул ее и слегка модифицировал.
Открываем comments.tpl, удаляем из него весь код, и вставляем вот этот код:
Открываем файл templates/Default/addcomments.tpl, видим там страшный и ужасный код:) многие новички не понимают, где же там прописана форма редактора, скажу по секрету она прописана в обычной таблице которая вставлена в основную таблицу. Т.е. таблица в таблице.
Давайте рассмотрим код оригинала поподробнее, в микроскоп, вот он (картинки убраны):
Код4:
[not-logged]
Ваше Имя:
Ваш E-Mail:
[/not-logged] [not-wysywyg]
[/not-wysywyg]
[not-wysywyg][/not-wysywyg]
[sec_code]
Код:
Введите код
[/sec_code]
Вот код нашего редактора (я выделил его из общего кода, для наглядности):
Код 5:
[not-logged]
Ваше Имя:
Ваш E-Mail:
[/not-logged] [not-wysywyg]
[/not-wysywyg]
[not-wysywyg][/not-wysywyg]
[sec_code]
Код:
Введите код
[/sec_code]
Давайте посмотрим что там есть:
Ваше Имя и следующая строка ниже
Это форма ввода имени (нужна если вы не зарегистрированы, а владельцем сайта разрешены комменты от незарегистрированных), если вы зарегистрированы то данные беруться из профиля.
Ваш E-Mail и следующая строка ниже
Форма ввода адреса электронной почты, если вы не зарегистрированы, если же зарегистрированы то данные берутьсяиз профиля.
— выводит форму с BBCODE
— выводит сам код безопасности (если включены комментарии для гостей)
Как вы видите обычные формы+css и ничего более.
вот то что получилось:
код 6:
/pics/6.gif» rowSpan=3>
[not-logged]
Ваше Имя:
Ваш E-Mail:
[/not-logged] [not-wysywyg]
[/not-wysywyg]
[not-wysywyg][/not-wysywyg]
[sec_code]
Код:
Введите код
[/sec_code]
/pics/9.gif»>
Ответы на возможные вопросы:
Скриншот того что получилось:
Ну вот и все. Мы научились менять дизайн комментариев.
It totally depends on template engine you are using. Some of them have no comment feature at all. You should carefully read documentation or browse source code if possible.
On my previous job I had to deal with really obsolete code from 90s with few internal-written template engines and at least in one of them I didn’t find any comment feature after reading internal documentation. After browsing the code I realised that the template logic flow was based on top of few preg_replace calls with no comment feature implementation at all.
I think that the approved answer is correct only in that specific case. For example, in OVOLogistics PDF Generator for CS-CART all the following comments types don’t work.
It totally depends on template engine you are using. Some of them have no comment feature at all. You should carefully read documentation or browse source code if possible.
Вы наверняка это слышали: «Хороший код является самодокументированным».
Я больше 20 лет зарабатываю написанием кода, и слышал эту фразу чаще всего. Это клише.
И как во многих других клише, здесь есть зерно истины. Но это истиной уже столько злоупотребляли, что большинство из тех, кто произносит эту фразу, не понимает, что она на самом деле означает.
Означает ли она, что вы никогда не должны комментировать код? Нет.
В этой статье мы рассмотрим разные аспекты комментирования кода.
Для новичков: существует два разных вида комментариев. Я называю их документирующими комментариями и поясняющими комментариями.
Документирующие комментарии
Документирующие комментарии предназначены для тех, кто будет скорее использовать ваш код, а не читать его. Если вы делаете библиотеку или фреймворк для других разработчиков, то вам понадобится что-то вроде документации API.
Чем дальше документация API от вашего исходного кода, тем вероятнее, что он со временем устареет или станет некорректным. Лучше всего встраивать документацию прямо в код, а затем извлекать её с помощью какого-нибудь инструмента.
Вот пример документирующего комментария из популярной JS-библиотеки Lodash:
К недостаткам документирующих комментариев можно отнести то, что они способны сильно «зашумлять» код, а программистам, которые активно участвуют в сопровождении кода, труднее их читать. Но зато большинство редакторов поддерживают «сворачивание блоков кода» (code folding), что позволяет скрывать комментарии и уделять всё внимание только коду.
Сворачивание комментариев в коде Visual Studio.
Поясняющие комментарии
Поясняющие комментарии предназначены для всех (включая вас самих в будущем), кто будет сопровождать, рефакторить или расширять код.
Зачастую поясняющие комментарии являются признаком плохого кода. Их наличие говорит об излишней сложности кодовой базы. Поэтому старайтесь убирать поясняющие комментарии и упрощать код, потому что «хороший код — самодокументированный».
Вот пример плохого — хотя и очень забавного — поясняющего комментария:
Не поймите неправильно, бывают ситуации — особенно при работе над очень тяжёлой задачей, — когда душа просит чуточку юмора. Но если пишешь смешной комментарий, уравновешивая плохой код, то вряд ли кто-то захочет потом его рефакторить или исправлять.
Вы действительно хотите лишить других программистов удовольствия от чтения вашего остроумного маленького стишка? Большинство из них посмеются и займутся своими делами, игнорируя недостатки кода.
Но бывают ситуации, когда натыкаешься на избыточный комментарий. Если код и правда прост и очевиден, не нужно добавлять комментарии.
Например, не делайте так:
Но бывает и так: что бы вы ни делали с кодом, поясняющий комментарий оказывается оправданным. Обычно это случается, когда нужно добавить какой-то контекст к неочевидному решению. Вот хороший пример из Lodash:
Или бывают такие ситуации: после долгих размышлений и экспериментов понимаешь, что решение, казавшееся наивным, на самом деле лучше всего. В будущем другие программисты практически неизбежно решат, что они умнее вас, и начнут переделывать код, чтобы потом осознать, что ваш способ оказался наилучшим.
Иногда таким программистом можете оказаться вы сами.
В таких ситуациях лучше сэкономить чужое время и написать комментарий.
Этот комментарий-заглушка прекрасно иллюстрирует описанное:
Конечно, это скорее развлечёт, чем поможет. Но вы ДОЛЖНЫ оставлять комментарии, предостерегающие других от поиска, казалось бы, очевидно «лучшего решения», если вы уже испробовали и отвергли другие варианты. При этом комментарий должен описывать, что вы пытались сделать и почему отказались от таких решений.
Простой пример в JavaScript:
Итак, вы прочитали про хорошего и плохого, а что насчёт злого?
К сожалению, в любой профессии можно почувствовать разочарование, и когда пишешь код ради заработка, может возникнуть соблазн выразить это разочарование в комментариях.
Если поработать с достаточным количеством кодовых баз, то вам встретятся комментарии от циничных и депрессивных до мрачных и злобных.
Такие комментарии могут казаться забавными, или на время помогают уменьшить разочарование, но если они попадают в production, то дискредитируют профессионализм автора и его нанимателя, выставляют их в дурном свете.
Применение tpl-шаблонов совместно с php-скриптами существенно облегчает web-разработку т.к. позволяет автоматизировать рутинные операции. Да и вобще удобная штука.
Механизм работы очень прост: допустим Вы занимаетесь разработкой типовых сайтов, страницы которых содержат какой-то статичный контент (контент, который не будет изменяться) и изменяющийся контент. Вместо того чтоб каждый раз создавать новые файлы, мы создадим tpl-файл, в котором заменим строки c изменяющимся контентом на переменные (они пишутся в фигурных скобках <> ) и создадим php-скрипт, который будет вставлять в эти переменные то, что нам нужно и выводить готовые странички.
Предположим что ваша страничка выглядит так:
Менять нужно записи — «Новый сайт», «Крутой сайт», «Ещё какой-то контент. ».
