Перейти до вмісту
Пошук в
  • Детальніше...
Шукати результати, які ...
Шукати результати в ...

sv2109

Користувачі
  • Публікації

    3 664
  • З нами

  • Відвідування

Записи блогу, опубліковані користувачем sv2109

  1. sv2109
    В последнее время начал немного изучать Python.
    Это на сегодня очень популярный язык программирования, входит в тройку наиболее популярных языков и по количеству вопросов на разных сайтах типа стековерфолоу и по колличеству репозиториев на гитхабе.
    Или вот сравнение по гугл трендах
    https://trends.google.com/trends/explore?date=today 5-y&geo=UA&q=%2Fm%2F05z1_,PHP&hl=ru
    Или вот информация с сайта TIOBE, они для анализа используют очень много параметров:
    https://www.tiobe.com/tiobe-index/
    Согласно их данным Python сейчас занимает первую позицию в рейтинге, обограм даже C++, C, C# и Java, а PHP занимает 8 позицию (год назад была 9-тая, то есть за год немного даже подрос). За последние 15 лет Python взлетел из 7 позиции на 1-вую, а PHP медленно опустился с 5-той на 8-9. Вся информация по ссылке выше.
     
    Для чего используют Python:
    для учебы. Если раньте школьников и студентов учили на паскале и бейсике которые вообще нигде не используются, то сейчас все дружно перешли на Python и это правильно, язык простой, живой, очень активно развивается и также активно используется. Наверное из-за этого и такой бурный рост языка, так как вчерашние студенты, которые выучили основы языка во время учебы потом начинают его использовать и в работе.  для различной автоматизации рабочих процессов. Например спарсить какой-то сайт, обработать пачку ексель документов, дернуть какую-то апишку и тысячи других не очень больших задач. На Python есть тысячи готовых библиотек с помощь которых можно делать что угодно от парсинга всего что только можно спарсить до распознавания лиц, синтеза речи и машинного обучения. для робототехники. Например можно взять какой-нибудь конструктор лего программируемый или плату типа Arduino, подключаем к ней какие-то датчики, моторчики, камеры итд. пишем на Python программу управления и вуаля получаем какую-то машинку на радиоуправлении, или квадрокоптер или сигнализацию для дома или кучу других интересных вещей, как я жалею что в годы моего детства такого не было)) для обработки больших данных, дата саенс, машинного обучения, нейронных сетей итд. И тут Python вообще первый среди всех языков программирования, в нем есть огромное к-во библиотек для всего этого. Эти библиотеки часто используют часть кода на C++ для ресурсоемких задач. Часть аналогов есть на node.js, а на PHP практически ничего нету. для веба и создание API серверов. Есть там фреймворк Django, наверное самый популярный, и на нем много чего делают. Его плюс в том что к нему есть очень много модулей, но сам по себе он гм.. я немного посмотрел его возможности и это мне напомнило PHP фреймворки и микрофреймворки лет так 10-15 назад.. ну то есть все очень бедно по функционалу, если сравнить его с напр. ларавел то это просто небо и земля Короче, мне сложно представить как на Python можно сделать что-то реально большое, скорее какие-то простые, небольшие сайты.
    Есть фреймворк FastAPI очень популярный в последнее время, на нем делают разные api сервисы.  консольные программы игры, точнее больше или какие-то несложные 2D игры или какие-то части для больших игр по например обработке данных десктопные приложения программы для мобильных устройств.. но последние 2 пункта это как по мне скорее исключение, примерно как натягивание совы на глобус так как для это есть специальные инструменты. его также майкрософт уже добавил в свой Excel, его также добавляют в браузер.. короче, скоро наверное вообще не останется ни одной области, где бы не было Python-а))  
    Плюсы Python
    простота изучения, отлично подходит в качестве первого языка программирования, мне он очень напоминает как в студенческие годы изучал паскаль)) огромное к-во библиотек на все случаи жизни огромное сообщество очень активно развивается в среде машинного обучения ему практически нету альтернативы много вакансий
    Минусы Python
    скорость, он как и все скриптовые языки достаточно медленный, причем тот же PHP последних версий 7,8 значительно обгоняет Python по скорости. Хотя, для тех задач для которых его используют скорости там вполне себе хватает. отсутствие хорошего ООП, тут нету ни нормальных приватных классов и методов, особенно протектед, здесь вообще нету интерфейсов, абстрактные классы реализованы как какой-то костыль через сторонний модуль итд. PHP версии 4! если не ошибаюсь был более функциональным в этом плане. рядом с очень классными библиотеками, написанными хорошими программистами, есть также множество говнокода и очень слабых программистов, так как пишут на Python вообще все кому не лень))
    Немного сравнения синтаксиса Python и PHP
    расширение файлов *.py
    не нужно открывать никаких тегов тира <?php в PHP, открыли файл и пишете код
    каждый файл это модуль, можно подгрузить, импортировать не весь файл, а только какую-то его функцию или класс, напр
    import random или
    from random import randint нету $ для переменных, ; в конце каждой строки и {} для классов, функций, условий, циклов.. () для условий и циклов также не пишутся, вместо этого есть отступы!
    не всем это нравится, но зато код стает очень понятным и написать код неправильно его отформатировав просто невозможно.
    def my_func(x):   #comment   return x*x
    это функция, вместо function - def
    функция может возвращать не одно значение а несколько, например
    return x,x*2,x*3 и потом делаем
    x,y,z = my_func(x) нету оператора ++ вместо него просто пишут
     
    x +=1 Нету тернарного оператора
    $x = true ? 1 : 0;
    вместо этого дают так:
    x = 1 if True else 0 вроде логически даже более правильно - 1 если истина иначе 0, но не привычно)
    True и False с большой буквы
    вместо NULL - None
     
    В классах уже писал нету нормальных private, protected, interface, трейтов итд. А то, что есть скорее костыли какие-то. То есть по сути нету нормальной инкапсуляции. Скорее есть набор правил, которым должны следовать программисты, но при желании это все обходится и можно легко получить доступ к приватным переменным. Фанаты языка в один голос повторяют что Python это самый лучший язык, а раз там этого нету, значит там это и не нужно. До недавнего времени они тоже самое говорили и о динамической типизации, а потом (вроде с версии 3.6) в язык завезли типизацию (правда использовать ее не обязательно). Кстати, тоже самое буквально слово в слово можно услышать и от фанатов опенкарта)) опенкарт - самый лучший, а раз там этого нету, значит оно тут и не надо)) Категорически с этим не согласен, так как наличие какого-то функционала не заставляет им пользоваться, но дает выбор, а отсутствие практически лишает вообще какого-либо выбора.
     
    Но в тоже время классы в пайтоне имеют одну очень интересную особенность - там есть тьма магических методов (которые начинаются и заканчиваются на __), которые позволяют выполнять с этим классом почти все (или вообще все) возможные операции, разные +, -, сложение, деление, возведение в степень, сравнение, преобразование в число, строку, массив итд.
    например создаете метод класса
    __add__() со своей логикой и можно делать
    object3 = object1+object2 Классы также поддерживают множественное наследование, чего не поддерживает PHP, но PHP поддерживает множественную имплементацию интерфейсов и трейтов, чего нету в пайтоне.
    В Python метод конструктора и деструктора это __init__ и __del__ соответственно
    Наоборот:
    В Python self указывает на объект класса (аналог $this в PHP), а в PHP на сам класс (для обращения к переменным класса и методам класса)
    В Python есть понятие статического метода класса и метода класса. Первое это просто функция которая не имеет доступа к переменным класса, а второе - имеет, как раз второй вариант работает как статический метод в PHP.

    Вместо одного массива array или [] как в PHP
    есть аж 4 вида типа массивов:
    list или список, обычный одномерные массив
    [1,2,"foo","bar"] tuple (кортеж) - очень похож на список, только его нельзя изменять. Через него сделаны возвраты нескольких значений из функции. Через него также можно легко поменять значения переменных местами, например
    x,y=y,x и все) теперь в переменной x значение из y и наоборот.
    (1,2,"foo","bar") set набор - имеет все элементы уникальные
    {1,2,"foo","bar"} dictionary - словарь, аналог ассотиативного массива в PHP
    {1: 2, "foo": "bar"} есть срезы, очень удобная штука, например получить элементы массива с 1 по 3
    new_list = old_list[1:3] или перевернет все элементы, кто был первым станет последним итд.
    seq[::-1] тоже самое со строками, так как строка работает как список, можно делать срезы, использовать циклы перебора символов  итд.
    string = 'строка' string[1:3] # 'тр'
    или вот такая магия используется очень часто:
    squares = [i * i for i in range(10)] print(squares) #[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
    То есть в одну строку кода можно создать список, набор, словарь
    И достаточно много подобное магии
     
    Если вкратце по синтаксису - все, если где ошибся то поправьте кто более знаком с этим языком или добавьте если есть что, так как я только начинаю его учить, вполне возможно что-то и упустил.
     
    Нужно ли учить этот язык? Мне кажется - однозначно - да.
    он простой, выучить его можно достаточно быстро, тем более что по пайтону есть просто куча бесплатных курсов, видео на ютубе итд. на нем интересно писать код, просто открываешь редактор и пишешь)) он очень популярный и есть много вакансий тут огромное сообщество и тьма библиотек на все случаи жизни, это открывает большие возможности можно работать в области машинного обучение и нейронных сетей, а сейчас это вообще очень популярная область и Python тут похоже вне конкуренции, он завоевал тут почти все)) очень полезно для общего развития очень полезно для резюме, даже если вы программист PHP то иметь в резюме Python как второй язык будет огромным плюсом для вас как для специалиста мне кажется, что очень хорошо подойдет для разработчиков OpenCart, тут нету сложных конструкций как в ларавел, тут простой код и синтаксис, ну почти как в самом опенкарте  
     
  2. sv2109

    OpenCart
    S.O.L.I.D. - это принципы программирования, которые сильно помогают при написании больших приложений, делая их более гибкими, расширяемыми, уменьшая при этом количество ошибок и конфликтов, а также время и деньги на поддержку и сопровождение этого приложения в будущем. 
     
    Принципы были описал еще в 2000 году Робертом Мартином, вы скорее всего слышали о его книгах, таких как "Чистый код" и "Чистая архитектура".
    Эти принципы настолько важны, что многие работодатели даже указывают в вакансиях их знание как обязательное условие при устройстве на работу.
     
    Попробую описать эти принципы своими словами, максимально просто и понятно.
     
    Как можно было догадаться из названия - принципов всего 5 по первым буквам названия:
    S - Single Responsibility Principle - Принцип единой ответственности
    O - Open-closed Principle - Принцип открытости/закрытости
    L - Liskov Substitution Principle - Принцип подстановки Барбары Лисков
    I - Interface Segregation Principle - Принцип разделения интерфейсов
    D - Dependency Inversion Principle - Принцип инверсии зависимостей
     
    Single Responsibility Principle - Принцип единой ответственности
    Достаточно простой, понятный но в тоже время очень важный, фундаментальный, принцип.
    Он говорит о том, что любая программная сущность (класс, метод, функция итд.) должна иметь только одну ответственность, то есть решать только одну задачу. Правда Роберт Мартин изначально вкладывал в этот принцип немного другой смысл. 
    Этот принцип очень часто нарушается в OpenCart, когда в контроллер добавляют все, что только можно - тут и валидация данных и создание ошибок, хлебных крошек, пагинации, картинок и вообще вся логика, так как в модели только получение данных из базы, а все остальное - в контроллере. Из-за этого мы получаем довольно распространенную ошибку MVC шаблона - очень большой контроллер, что является неправильным, контроллер должен быть очень простым и легким, его основная задача - получить запрос от пользователя (Request), передать его кому-то другому на обработку и результа вернуть назад пользователю (Response), но делать вообще всю работу он никак не должен.
     
    Open-closed Principle - Принцип открытости/закрытости
    Еще один очень важные принцип, который также полностью нашурается опенкартом.
    Он говорит о том, что программные сущности должны быть открыты для расширения и закрыты для изменения (модификации кода)
    То есть, эти сущности должны иметь возможность расширить их функционал, но никак не через непосредственное изменение их кода, а через другие методы, например через наследование, интерфейсы, внедрение зависимостей, Events или в некоторых системах hooks, модули и плагины для CMS и так далее.
    В OpenCart же по сути вообще вся система расширений построена на модификаторах (ocmod) или на изменении кода самого движка, то есть на полном нарушении этого принципа. 
     
    Liskov Substitution Principle - Принцип подстановки Барбары Лисков
    Он говорит о том, что если какая-то программная сущность работает с объектом класса родителя то она точно также без каких-либо изменений кода должна работать и со всеми потомками этого родителя. То есть, чтобы мы могли вместо класса родителя подставить класс любого его потомка и при этом наша программа работала точно также как и работала до этого. Это также улучшает расширяемость приложения и переплетается со вторым принципом - открытости/закрытости.
    Как это достигается? Например через контроль всех возвращаемых данных методами классов, если метод родителя возвращает массив определенного формата то и все потомки должны точно также возвращать точно такой же формат массива. Или есть в родителе реализован какой-то метод то этот метод должен быть обязательно реализован и всеми потомками и так далее.
     
    Interface Segregation Principle - Принцип разделения интерфейсов
    Он говорит о том, что если какой-то класс реализовывает интерфейс, то он должен реализовывать абсолютно все его методы, а не только какие-то из них.
    Например, если нам нужно создать какой-то класс и мы видим, что у нас уже есть интерфейс, который очень похож на тот, который нам нужен, например там есть 10 методов из которых нам нужны 8, то использовать этот интерфейс для этого класса мы не можем, нужно разделить этот интерфейс на несколько более мелких и использовать именно то, что нам нужно (тем более что PHP поддерживает реализацию классом нескольких интерфейсов).
    Иначе получится ситуация, когда какой-то наш метод работая с этим интерфейсом будет предполагать, что в любом классе, который его реализует обязательно должен быть реализован какой-то метод, но в одних классах он будет реализован, а в других будет например выбрасываться исключение и нам придется в нашей программе в куче мест писать кучу условий и держать в голове всю логику в каком классе какие методы есть а каких нету.. зачем? если сама идея интерфейсов и состоить в том, чтобы оградить нас от всех этих проблем.
    К сожалению OpenCart, похоже, вообще не использует интерфейсы. Да, на весь движок из сотен файлов нету ни одного интерфейса, не считая сторонних библиотек. 
     
    Dependency Inversion Principle - Принцип инверсии зависимостей
    Еще один крайне важный принцип, который отлично реализован в Laravel через сервис контейнеры.
    Упрощенно он говорит о том, что все зависимости в приложении должны строится на базе интерфейсов, а не через конкретные реализации.
    Объясню лучше на примере.
    У нас есть больше приложение, которое сохраняет данные в базе данных. Для этого у нас есть класс DB и методы select() для получения данных из базы и insert() для сохранения. Все отлично работает, но в один момент нам (или заказчику) понадобилось реализовать сохранение данных в, например, файлах. И у нас даже есть готовый класс для этого FileStorage с методами read() и write() соответственно. Но беда в том, что нам теперь нужно переписать гору кода в десятках файлов чтобы заменить не только все названия методов но и их аргументы и возвращаемые значения.. А теперь представьте насколько было бы проще, если бы все было реализовано через интерфейсы и у нас был интерфейс StorageInterface, в котором бы были методы например get() и set() и везде в коде мы использует именно эти методы. Теперь, если нам нужно сохранять данные в базе, мы создаем класс DB который реализовывает наш интерфейс StorageInterface с определенными методами, а для файлов создаем другой класс, который реализовывает тот же самый интерфейс с теми же самыми методами. Если в будущем нам понадобиться работать с LLM и сохранять данные в какой-то векторной базе данных напр. Chroma или Pinecone, без проблем, мы просто реализуем новым классом VectorStorage наш интерфейс и без проблем сможет использовать этот класс в своем приложении и у нас ничего не поломается.
    Мы сможем даже подключать разные классы работы с данными динамически в зависимости от условий, например в зависимости от переменных окружения, если мы в режиме разработки то использовать один класс данных, если в продакшене то другой, а если в режиме тестирования то какой-нибудь FakeStorage и все будет замечательно работать без каких-либо изменений в коде.

    Надеюсь, у меня получилось донести что такое принципы S.O.L.I.D., как они работают и почему так важно их использовать в работе.

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

    И OpenCart это как раз очень наглядный пример как незнание или игнорирования базовых принципов программирования при построении больших систем может со временем парализовать развитие всего проекта. 
  3. sv2109
    Название темы очень неоднозначное, так как многие могут сказать, что это совсем разные вещи, сравнивать которые не имеет смысла. Но многие разработчики OpenCart считают OpenCart именно фреймворком, некоторые даже пишут что это не просто фреймворк, а самый лучший фреймворк, на котором можно сделать сайт любой сложности.. Поэтому и решил сравнить именно функционал фреймворков.
    Почему Laravel
    На сегодня это наверное самый популярный фреймворк на PHP. Он во много раз (и даже в десятки) популярнее самого OpenCart.
    Для примера: https://trends.google.com.ua/trends/explore?date=today 5-y&q=%2Fm%2F0jwy148,%2Fg%2F11b5m9hl85&hl=uk
    за последние 5 лет если популярность OpenCart упала больше как в 2 раза, то популярность Laravel наоборот выросла процентов на 30.
    Это фреймворк на котором пишут всё - от всевозможных API, серверлесс решений, SPA, бэкенда для мобильных приложений, ботов для мессенджеров до больших и сложных сайтов, интернет магазинов и маркетплейсов.
    Он простой, быстрый, функциональный, безопасный, что очень важно - очень активно поддерживается сообществом и развивается, совсем недавно вышла новая, 10 версия фреймворка, всего год назад - 9. Есть огромное количество бесплатных расширений, практически под любую задачу уже есть готовый пакет.
    Он отлично работает как с обычными css библиотеками типа bootstrap так и с реактивными фреймворками типа React и Vue.
    Я недавно начал более серьезно изучать этот фреймворк, скорее в качестве спортивного интереса и расширения кругозора, так как в последнее время постоянно о нем слышу с очень разных источников.
    И был очень приятно удивлен его красотой, удобством и функционалом. А также насколько радикально он отличается от опенкарта в плане кода и работы с ним для программистов.
    Тут автоматизировано почти все, что можно автоматизировать, многие действия делаются вообще в 1-2 строчки кода.
    Поэтому и решил написать данный пост, а заодно и немного сравнить функционал с OpenCart и даже показать примеры кода. 
    И так, некоторые возможности Laravel, которые больше всего понравились:
    Тут в полном объеме раскрываются все возможности PHP - классы, интерфейсы, наследование, трейты, Enums, SOLID, шаблоны проектирования (фасады вообще везде, DI, Factory..) итд.
    Работая с фреймворком реально начинаешь понимать всю красоту правильного подхода, когда в одну строчку кода можно изменить логику работы всего приложения если все спроектировано правильно. А не так как в опенкарт, когда чтобы поменять какую-то мелочь, нужно изменить сотни строк кода в десятках файлах, что и делается постоянно, достаточно посмотреть как в опенкарт сделана напр. пагинация или валидация форм или генерация ссылок или работа с базой..
    Чтобы не быть голословным. Если прочитать формулировку 5 принципа SOLID - инверсии зависимостей, то там будет вот это:
    A. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
    B. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
    Скорее всего, если вы читаете это впервые то  единственное что вы из этого поймете это то, что вы ничего не поняли))
    В то же время когда начинаешь работать с Laravel то там достаточно часто методы получают в параметрах не какие-то конкретные объекты и следовательно зависят от конкретных реализаций этих объектов, а интерфейсы, то есть эти методы зависят именно от абстракций. Что это дает? В настройках Laravel можно указать какой конкретный класс нужно использовать для данного интерфейса, можно даже сделать это через условие, например в режиме разработки использовать один класс, который напр. не отсылает никуда данные а только пишет в лог, а в продакшене использовать другой.
    При этом мы никак не изменяем логику самого метода, ему вообще без разницы какой объект ему передали, главное чтобы это был объект нужного интерфейса. И приложение получается очень гибким и без кучи ненужных условий, проверок и дублирования кода. Изменения делаются через изменение одной строчки кода и у нас уже все приложение работает по совсем другой логике.
    Консольные поманды
    php artisan - скрипт с помощью которого можно создавать огромное к-ва кода и запускать типовые действия через 1 комманду.
    Можно создавать контроллеры, модели, миграции, события, правила, ресурсы, реквесты, работать с базой данных, очередями, планировщиком, представлениями, окружение и многое другое.
    Можно также создавать свои кастомные консольные комманды или изменять логику работы уже существующих.
    То есть вам нужно что-то создать вы не пишете весь код вручную, вместо этого вводите 1 комманду в консоли напр.
    php artisan make:model ProductModel (+ различные параметры если нужно)
    и создаете сразу новую модель для товара вместе с фабрикой, миграцией, сидом, ресурсным контроллеров (в котором уже будут созданы все необходимые методы для CRUD) а также отдельными классами реквестов.
    Сколько времени это экономит? Особенно есть учесть что если писать столько кода вручную то полюбому где-то допустишь ошибку и потом еще потратить кучу времени чтобы понять почему оно не работает.
    Плюс мы также получаем однотипную структуру для всех проектов, что значительно упрощает работу.
    Очень классно реализована работа с базой
    Тут есть как отдельный билдер для создания запросов к базе и не нужно вручную писать кучу SQL запросов для кучи однотипных действий - получение, изменение, удаление записей в базе данных.
    Тут конечно есть и ORM.
    Вы просто создаете новую модель
    php artisan make:model ProductModel Это будет практически пустой класс без единой строчки SQL кода, но в контроллере вы уже сможете полноценно работать с базой, например
    $products = Product::all(); получит все товары, можно также добавить различные условия, лимиты, сортировку, связи итд.
    Мало того, что вы экономите кучу времени, так еще и все запросы к базе автоматически защищаются от всевозможных SQL инъекций и различных ошибок.
    Таблицы в базе данных создаются и изменяются с помощью миграций - специальный класс для изменения таблицы, с помощью которого можно как добавить изменения так и откатить их.
    например миграция для таблицы постов:
     
    Schema::create('posts', function (Blueprint $table) {             $table->id();             $table->string('title');             $table->text('content');             $table->unsignedBigInteger('category_id')->nullable();             $table->timestamps();               $table->index('category_id', 'post_category_idx');             $table->foreign('category_id', 'post_category_fk')->on('categories')->references('id');           });
    Можно использовать сиды - классы для заполнения таблиц какими-то данными.
    Сиды можно реализовывать через фабрики - класс для автоматического создания записи, есть также класс Faker для создания фейковых данных для полей - текстовых, числовых, различных дат, кодов, картинок, телефонов,
    емейлов итд. можно очень легко заполнить сайт тестовыми данными для тестирования, за пару секунд создать хоть 1000 постов с названием, описанием, картинкаим итд. Или кучу пользователей с емейлами, паролями итд.
    То есть как происходит стандартная работа - вы копируете какой-то проект на Laravel,
    Одной командой создаете все необходимые таблицы для работы
    Еще одной командой заполняете эти таблицы необходимыми для работы данными.
    Максимально простые контроллеры
    (что по сути и должно быть по стандарту MVC, а не то что мы сейчас видим в опенкарт)
    пример метода контроллера для получения поста
       public function show(Post $post)     {         return view('post.show', compact('post'));     }
    Обратите внимание, очень классная фишка Laravel - если в адресе страницы есть id поста (напр. /posts/123) то мы в качестве аргумента метода контроллера можем получить не этот идентификатор чтобы потом по нему вручную создать этот пост, а фреймворк за нас сам создаст этот пост и мы в качестве аргумента получаем сразу объект этого поста, осталось передать его представлению и все. Если пост не будет найден то фреймворк вернет страницу 404. Вроде мелочь, но таких мелочей там десятки, которые очень сильно ускоряют разработку.
    или контроллер для создания постов
     
     public function store(StoreRequest $request)     {         $data = $request->validated();           $this->service->store($data);           return redirect()->route('admin.post.index');     }
    StoreRequest - отдельный реквест для данного метода, опять же в качестве аргумента получаем готовый объект и нам не нужно его создавать вручную самостоятельно, в нем содержаться правила валидации запроса
     
      public function rules()     {         return [             'title' => 'required|string',             'content' => 'required|string',             'image' => 'required|file', // можно также указать что это также картинка, определенного типа и размеров.             'category_id' => 'required|integer|exists:categories,id', // тут сразу проверяется наличие этого идентификатора базе в таблице категорий, чтобы не создать пост с несуществующей категорией.             'tag_ids' => 'nullable|array',             'tag_ids.*' => 'nullable|integer|exists:tags,id',         ];     } то есть вам не нужно вручную для каждого поля, которое вы получаете, через кучу if конструкций прописывать кучу правил, обработку этих правил, вручную создавать и возвращать ошибки валидации, если эти правила не сработали или даже писать sql запросы если нужно проверить уникально записи в базе данных, нет. Просто создается массив со всеми правила (из коробки уже доступны десятки правил валидации с текстами ошибок, но можно создавать и свои собственные) и все.
    дальше, в
    $data = $request->validated(); попадет массив всех уже проверенных данных.
    Если валидация не прошла то фреймворк сам возвращает пользователя на старую страницу и возвращает все ошибки валидации
    все что вам нужно это прописать в шаблоне под полем
    @error('title')   <div class="text-danger">{{ $message }}</div> @enderror
    и фреймворк сам выведет нужные ошибки для всех правил для каждого поля, ошибки тоже можно настраивать и переопределять.
    дальше по коду
    $this->service->store($data); вся логика из контроллера вынесена в отдельный сервис для создания всех данных, для улучшения читабельности кода и чтобы не раздувать контроллеры.
    сам метод примерно такой:
       public function store($data) {         try {             // старт транзакции, так как есть работа с несколькими таблицами             DB::beginTransaction();               $data['image'] = Storage::put('/images', $data['image']);               $post = Post::сreate($data);               if (isset($tagIds)) {                 $post->tags()->attach($tagIds);             }               DB::commit();         } catch (\Throwable $th) {             // откат если произошла какая-то ошибка             DB::rollBack();         }     }
    Тут видно работу с транзакциями, которых вообще нету в OpenCart и очень зря, так как при сохранении напр. товара задействуется не одна таблица товара, а с десяток других - опции, атрибуты, акции, скидки, картинки, связи итд.
    И если где-то произойдет ошибка то в базу запишутся не валидные данные которые потом найти будет крайне сложно. Я достаточно часто встречаю ситуацию когда в базе опенкарт невалидные данные, особенно после использования различных модулей импорта.
    Очень просто сделана работа с файлами.
    Можно в настройках указать несколько файловых хранилищ (локальное, фтп, облачные хранилища) и легко переключаться между ними или какие-то данные загружать локально, какие-то в облако итд.
    Post::сreate($data); создаст новый пост
    через метод attach к этому посту добавятся новые теги, потому что в модели поста прописана связь этого поста с тегами
        public function tags() {         return $this->belongsToMany(Tag::class, 'post_tags', 'post_id', 'tag_id');     }
    Эта связь дает нам возможность как автоматически получать теги для постов (через $post->tags) так и изменять их.
    При этом мы не написать ни одной строчки SQL кода! Весь код со всеми связями, проверками итд. написал за нас фреймворк. И это не только очень сильно ускоряет весь процесс разработки экономя сотни часов времени, но и страхует от кучи возможных ошибок, в том числе ошибок безопасности, например можно какие-то данные при добавлении в базу не обработать и получить потенциальную ошибку безопасности.
    Понравилась такая фишка как безопасное удаление
    если в модели просто добавить трейт
    use SoftDeletes; то при удалении записей они не будут удаляться физически, а просто помечаться что были удалены, на сайте вы их не увидите, так как почти все методы работы с базой этих записей не видят, но они будут в базе и их легко можно восстановить при необходимости.
    Что еще, для примера - пагинация
    Если нужно добавить пагинацию то в контроллере при получении постов делаем
    $posts = Post::paginate(10); а в шаблоне
    добавляем всего одну строчку кода
    {{ $posts->links() }} и все, мы получаем рабочую пагинацию, стилизованную напр. под бутстрап, которая сама создает все ссылки.
    А теперь сравните какую простиню кода нужно написать в опенкарт для того чтобы добавить ту же самую пагинацию для каждой страницы.. это куча строк кода в каждом! контроллере.
       
    $url = '';       if (isset($this->request->get['filter_name'])) {       $url .= '&filter_name=' . urlencode(html_entity_decode($this->request->get['filter_name'], ENT_QUOTES, 'UTF-8'));     }       if (isset($this->request->get['filter_model'])) {       $url .= '&filter_model=' . urlencode(html_entity_decode($this->request->get['filter_model'], ENT_QUOTES, 'UTF-8'));     }       if (isset($this->request->get['filter_price'])) {       $url .= '&filter_price=' . $this->request->get['filter_price'];     }       if (isset($this->request->get['filter_quantity'])) {       $url .= '&filter_quantity=' . $this->request->get['filter_quantity'];     }       if (isset($this->request->get['filter_status'])) {       $url .= '&filter_status=' . $this->request->get['filter_status'];     }       if (isset($this->request->get['filter_image'])) {       $url .= '&filter_image=' . $this->request->get['filter_image'];     }       if (isset($this->request->get['sort'])) {       $url .= '&sort=' . $this->request->get['sort'];     }       if (isset($this->request->get['order'])) {       $url .= '&order=' . $this->request->get['order'];     }       $pagination = new Pagination();     $pagination->total = $product_total; // для этого нужно эту переменную еще вручную достать из базы, создав для этого отдельный метод с кучей sql кода и передать в контроллер.      $pagination->page = $page;     $pagination->limit = $this->config->get('config_limit_admin');     $pagination->url = $this->url->link('catalog/product', 'token=' . $this->session->data['token'] . $url . '&page={page}', true);       $data['pagination'] = $pagination->render(); Отличный концепт - очереди и задания.
    Если есть какие-то действия, напр. отправка почты или какие-то вычисления, для которых нужно обращаться к сторонним сервисам то вместо того чтобы долго ждать каждый раз пока сторонний сервер отдаст результат, можно создать новой задание Job и добавить его в очередь Queue после этого все действия в очереди будут спокойно обрабатываться в фоне и ничего на сайте не будет тормозить пока ожидается ответ от сервера.
    Еще одна отличная концепция - Middleware
    Это код который выполняется перед или после реквеста.
    Очень удобно делать разные ограничения доступа к некоторым страницам (например открыть доступ к странице только авторизованному пользователю или админу итд.) или обработку входящих данных, например по умолчанию для всех входных строк отображаются пробелы в начале и конце. При этом вся логика не пишется в одну кучу в контроллере через кучу условий, а лежит в отдельном классе. 
    Через этот механизм таже сделана защита CSRF (cross-site request forgery )
    все что вам нужно это написать в шаблоне для формы
    @csrf
    и все! фреймворк сам создаст нужные токены, передаст их в форму, выведет нужный инпут, а на входе проверит все запросы (кроме гет) есть ли там токер, совпадает ли он, если не совпадает то сделает возврат с ошибкой и не даст такой форме пройти дальше.
    Этот механизм работает для всех форм, то есть уже из коробки есть эта защита для всех форм. И этой защиты вообще нету в OpenCart.
    Через Middleware также из коробки реализован троттлинг, для API вы можете указать сколько запросов напр. в минуту должен сервер обрабатывать и не больше.
    Ну и так далее, то что я описал выше это очень малая часть возможностей фреймворка, просто для примера. Всех возможностей многократно больше.
    Я просто хотел показать насколько тут все продумано до мелочей, когда основные базовые действия автоматизированы настолько, что делаются буквально в 1-2 строчки кода.
    И как это контрастирует с опенкартом, где для любого действия нужно писать десятки строк кода да еще и дублировать это в десятках контроллеров.
    Наглядный пример сравнения когда в одном случае продукт делается программистами для программистов и когда в другом случае кто-то пишет код вообще не думая о том кто потом и как с этим кодом будет работать в будущем..
    Возможно поэтому популярность Laravel растет последние 5 лет, чего к сожалению не скажешь об OpenCart.. 
  4. sv2109

    OpenCart
    На данный момент продолжается работа над 4 версией движка. На сегодня для тестирования доступна версия 4.0.0.0_b. Сроков выхода новой версии пока нету, но уже можно посмотреть какие там запланированы изменения.    Из основного - минимальная версия PHP - 8 "Warning: You need to use PHP8 or above for OpenCart to work!"  
    - убрали модификаторы (ocmod)
    Вот только не понятно как можно убирать модификаторы, если с помощью событий еще можно сделать очень мало? И как при этом писать дополнения? Или будет как в версии 1.5 движка - отдельно OpenCart и отдельно все скачивали vQmod? 
    - добавлена схема для базы данных system/helper/db_schema.php  Опять таки, зачем она нужна если запросы к базе все еще пишутся в одну строчку?
      - для товара добавлены варианты
    Можно указать главный товар и его варианты, например один товар с различными вариантами цветов, теперь это будут разные товары для каждого цвета со своими наборами опций, ценой, остатками и другими полями   - папка дополнений переехала из /catalog и /admin в /extension/opencart/catalog /extension/opencart/admin Свои же дополнения будут храниться в  /extension/username/catalog /extension/username/admin спасибо @chukcha за уточнение

    Суть это не меняет, но структуру файлов всех дополнений придется переделывать.

    - неймспейсы теперь везде
    было class ModelCatalogProduct extends Model { стало namespace Opencart\Catalog\Model\Catalog; class Product extends \Opencart\System\Engine\Model {
    - и строгая типизация
    было public function getProducts($data) { стало public function getProducts(array $data = []): array {  
    Шаблон - Bootstrap обновлен до 5 версии 
    при этом поддержку font-awesome убрали, видимо иконки уже есть в Bootstrap
    - jQuery 3.6 вместо 2.1 
    - возможно, в движок будет добавлен React или Vue
    Разговоры об этом идут, я уже писал об этом на форуме, также писал о том, насколько маловероятно что это будет реализовано  
      - появилась новый шаблон  product/thumb.twig   
    для блока товара в категории, поиске, производителе итд. Более подробно тут   - появился новый шаблон  common/pagination.twig для пагинации   Админка
    - появился новый тип дополнений - Startup
    предположительно для добавления своих скриптов, которые будут выполняться при загрузке магазина

    - появились задания крона wget "http://localhost/opencart/4.0b/admin/index.php?route=common/cron" --read-timeout=5400
    - добавлено GDPR Approvals для пользователей

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


    Общие впечатления
    К сожалению, вот уже несколько новых мажорных версий, начиная со второй, вместо того, чтобы решать глобальные проблемы движка, такие как отсутствие нормальной системы расширений, отсутствие нормальных инструментов работы с базой данных, валидаторов, дублирование кода, устаревшее ядро движка, которое уже больше 10 лет как почти не изменяется, а также многие другие, OpenCart идет по пути "сделаем все красиво" и в каждой новой версии тратится куча времени для обновления дизайна, сначала добавили Bootstrap, потом в каждой новой версии его обновляют, добавили twig, обновили jQuery.. 
    Каких-то кардинальных изменений я совсем не заметил, на мажорную версию это никак не тянет, максимум на 3.1. 
    Хотя, работа над 4 версией еще не закончена, есть слабая надежда что еще что-то добавят. 

    Если что-то пропустил  - дополняйте или поправляйте в комментариях. 




  5. sv2109
    Предлагаю немного пофантазировать. Чего больше всего не хватает OpenCart, чтобы быть ну если не идеальным, то по крайней мере движком с которым было бы приятно работать всем нам? По моему мнению не так и много, как может показаться на первый взгляд.
     
    1. Конструктор форм. 
    Что есть сейчас?
    Каждый разработчик для каждого своего дополнения вручную пишет горы HTML кода со всеми классами, проверками валидности, javascript и так далее. А когда OpenCart меняет например версию Bootstrap с 4 на 5 то с этим меняются десятки css классов и весь этот HTML код нужно вручную переписывать для каждого модуля..  
    А теперь только представьте! Был бы в OpenCart какой-то простой конструктор форм, чтобы формы не создавать, как мартышки, вручную и потом изменять по пол дня каждую форму после очередного обновления. А чтобы форму создавать как-то так:
    $form = new Form(array(   'id' => 'my-module-form'   'action' => '...',   'field' => array(     'type' => 'input',     'name' => 'title',     'label' => 'Title'     'rules' => array (       'required' => true,       'min_lenght' => 3     )   ) ));
    и потом делаем например $form->render() и передаем результат в шаблонизатор. Все.  

    Что это даст?
    Модулю будет вообще все равно на какой версии bootstrap или twig работает админка движка, это все нужно знать только конструктору форм и со сменой версии он сам построит нужную форму со всем новым синтаксисом. То есть, мы можем еще под 1.5 создать в контроллере модуля свою форму и эта форма будет работать даже на OpenCart 4 и 5 версии бутстрапа! А если в каком-то OpenCart 5 появится React то нам и тогда будет все равно, потому что конструктор форм поменяется все за наc и модуль и дальше будет работать!  В конструктор форм можно добавить событие, напр. form/render/before и перед рендерингом всех! форм любой модуль может получить объект этой формы и изменить его как угодно - например добавить какие-то свои поля или целый новый таб с кучей своих полей итд. То есть любой модуль может легко изменить любую форму в админке и каталоге как самого движка так и любого другого модуля. При чем сделает это не через модификаторы которые особенно при изменении шаблонов добавляют кучу конфликтов, а правильным способом через события и добавление новых полей в объект формы.  В форму также можно добавить такие приятные плюшки как: автоматическую валидацию полей по заданным правилам, с выводом нужных сообщений об ошибках, причем валидация будет работать даже без перезагрузки страницы через аякс. Плюс будет куча встроенных правил для валидации напр. емейлов, ссылок, длины и так далее, просто добавил в правило поля напр. 'required' => true и все, форма сама создаст поле, проверку, вывод ошибки если условие не соблюдено и так далее. 
    2. Конструктор SQL запросов. 
    Я не говорю о какой сложной ORM, а об очень простом конструкторе запросов. 

    Что есть сейчас?
    Каждый разработчик пишет кучу SQL запросов вручную. При этом эти запросы изменить из своего модуля можно разве что через модификаторы, порождая тем самым кучу конфликтов. 
    А теперь представьте если бы в движке был конструктор запросов и запросы создавались как-то так:
    $query = $this->db->select('*')->from('product')->where(...)->limit(10); $results = $query->execute();
    Что это даст? 
    И читать и писать такой код легче и понятнее Можно в сам конструктор добавить и добавление префикса таблицы и автоматическую обработку данных перед выполнением, не нужно для каждого поля вручную делать $this->db->escape, а это в свою очередь и упростит написание запросов и сделает их надежнее и безопаснее.   Самое главное! Можно создать событие напр. db/execute/before и со своего модуля получить доступ ко всем! SQL запросам на сайте с возможностью изменить каждый, например добавить свой новый JOIN или условие, сортировку итд.  Имея конструктор в будущем намного проще перейти на новую базу данных, при этом не нужно будет изменять код всех модулей, а только код самого конструктора, чтобы он по готовым правилам создал другой запрос по правилам другой базы данных.  Для каких-то сложных запросов или ленивых разработчиков всегда останется возможно написать какой-то запрос вручную по-старому. 
    3. Нормальная система расширений. 
    Для этого:
    Полностью выбросить на свалку истории vqmod и ocmod, как причину огромного к-ва конфликтов Сделать нормальную систему Событий. Писал об этом выше как можно расширить движок при наличии конструктора форм и SQL запросов. Это далеко не все, что нужно для полноценной системы Событий, просто показывает на примере как можно достаточно просто создать огромные возможности для правильного! изменения движка через События. Добавить другие инструменты такие как валидаторы, хелперы для например создания хлебных крошек, пагинации и десятков других вещей, для которых в движке нужно дублировать кучу кода в каждом модуле.   
    Конечно, добавить еще можно много всего, но если хотя бы реализовать те 3 пункта что я описал выше мы уже бы получили качественно! другой движок. 
    Потому что извините, но в 21 году писать вручную SQL запросы, HTML формы и дублировать тысячи строк кода это.. мне даже слова сложно подобрать, чтобы это описать и никого не обидеть.. одним словом - сюр какой-то.
     
    И еще один важный вопрос - усложнят ли все эти нововведения движок? 

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

×
×
  • Створити...

Important Information

На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність.