Впечатления новичка от opencart (код)

[ArtemPitov]

Это просто очень плохой пример. В реальности Active Record намного удобней, понятней и читабельней, чем голый SQL.

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

[pantagruel964]

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

Да хотя бы примеры из документации Laravel.

[ArtemPitov]

Да хотя бы примеры из документации Laravel.

спасибо, изучу 

[Dotrox]

покажите хороший пример

Вот так бы выглядело, например, получение данных товара:

$product = Product::find()->where(['id' => '111'])->one();

А использование полученных данных выглядело бы так:

$product->name
$product->price

Создание товара:

$product = new Product;
$product->name = $name;
$product->price = $price;
$product->insert();

А оптимизация происходит под капотом в зависимости от полученных параметров.

 

Ну и Active Record - это наивысший уровень абстракции, где все данные представлены в виде объекта модели.

 

Вот пример с меньшей абстракцией (выборка товаров из категории):

$products = (new Query())
    ->select(['id', 'name'])
    ->from('product')
    ->leftJoin('product_to_category', 'product.product_id = product_to_category.product_id')
    ->leftJoin('product_description', 'product.product_id = product_description.product_id')
    ->where(['product_category_id' => '55'])
    ->limit(10)
    ->all();

[chukcha]

и еще вопрос, как их оптимизировать тогда ?

Что оптимизировать?

 

Ведь по сути, вы получаете ту же саму sql строку..

 

Вот и Марк, говорит, что где-то это лучше

 

потому что

 

в такую конгструкцию

 

$t = $this->db
->select('ostatok')
->from('prod')
->where('art', $art)
->get()

 

проще вставить

 

$t = $this->db
->select('ostatok')
->from('prod')
->where('art', $art)

->where('quantity >0')

->get()

 

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

 

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

 

$myEvent = SetEvent('getProducts')   // добавить условия в getProducts

 

function getProducts($data)

$query = new $Query;

$query->select('*')
->from('product')

->leftjoin('product_description')
->where('art', $art)

//вызов события

 

$query->get()

 

Я показал приблизительную структуры, как это делается.

[ArtemPitov]

Это реально удобнее! Спасибо за примеры 

[proctoleha]

Вот если попробовать подвести итог неожиданно бурному обсуждение, по поводу моих тупых вопросов, то он следующий: проблема не в том, что нужно документировать, не нужно, нужно подкручивать active_record, не нужно ...

 

Суть в том, что opencart - это открытый бесплатный проект, и если что-то не нравится - идем на гит и форкаем. ВСЁ! Не нравится бесплатный - покупаем платный и долбаем разрабов.

[Dotrox]

Суть в том, что opencart - это открытый бесплатный проект, и если что-то не нравится - идем на гит и форкаем. ВСЁ!

Вы создали эту тему, чтобы призвать всех контрибутить в код ОК? :)

 

Видимо, вы плохо знаете Дэниэля Керра (автор ОК). Если вы скажите ему, что в ОК что-то неправильно - он вам расскажет, какой вы аматор ничего не понимающий в разработке. Попробуете сделать пулл реквест с какой-то концептуальной правкой - он его отклонит без каких либо вразумительных объяснений.

[chukcha]

Всем любителям ORM читать непременно: Тарасов С. В. "Дефрагментация мозга. Софтостроение изнутри", глава "ORM, или объектно-реляционный проектор".

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

 

Я задам несколько вопросов

SELECT и select отличаются или нет?

SELECT p.id,pd.name

SELECT p.id, pd.name

отличаются или нет?

 

И. будут ли отличаться "скомпилированные" запросы

select(array(p.id,pd,name)

 

А также.. был показан пример быстрого, беззатратного добавления condition в запрос.

[chukcha]

и вдогонку, неверно построенная архитектура, никоим образом не оправдывает неиспользование ORM

 

Так же можно поговорить об  оптимизации. - А почему бы и нет. И сказать - оптимизация вред и привести примеры неудачной ранней (преждевременной) оптимизации.

[proctoleha]

Всем любителям ORM читать непременно: Тарасов С. В. "Дефрагментация мозга. Софтостроение изнутри", глава "ORM, или объектно-реляционный проектор".

 

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

 

Зачастую, ещё вчерашние новички, научившись достаточно элементарным вещам, любят порассуждать о том, что изобретение велосипедов – пустое дело...

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

Золотые слова

 

Знания, навыки, велосипеды у меня есть. Но я, новичок без репутации,  осмелился беспокоить маститых гуру своими вопросами-велосипедами! Умереть не встать. Ответы по сути поставленных вопросов можно пересчитать по пальцам на  одной руке на 5-ти страницах.

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

 

Я не писал, что в OK всё плохо. Если бы это было так, ОК не стала бы тем, чем она есть. И это понятно любому внимательно читающему образованному человеку, кроме местных гуру.

Змінено 5 грудня 2016 користувачем proctoleha

[Dotrox]

Я не писал, что в OK всё плохо. Если бы это было так, ОК не стала бы тем, чем она есть.

Вот видите, как плохо вы знаете ОК! А всё действительно плохо. Одно только сознательное и полнейшее повсеместное игнорирование DRY чего стоит.

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

 

Такое огромное количество различных сборок на основе ОК как раз и вызвано тем, что оригинальный ОК малопригоден для реального использования.

[proctoleha]

@Dotrox,  у меня сейчас поедет крыша.

 

Тема называется  

Впечатления новичка

Еще раз по буква новичка!!! Как я могу хорошо знать ОК? Как скажите мне пожалуйста. И я вывалил то, что на поверхности. Что сразу же бросилось в гллаза.

Змінено 5 грудня 2016 користувачем proctoleha

[chukcha]

@Dotrox, ну не надо...

В каком месте малопригоден?

 

Для запуска большого проекта?

Неужели все магазины сразу выходят на 200к товаров?

И в первый же месяц имет хотя бы 10 заказов в день

Неужели магазин, который имеет от 20 (это минимум, когда уже нужна поддержка) заказов не может иметь нанятого специалиста?

 

то, что на поверхности

Что на поверхности? Что вы выявили?

[Otvet]

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

кроме сайтмапа проблем вызывающих генерацию дольше 1-2 сек (без подсчета естесственно) на среднестатическом хостинге до 10-15 тыс товаров нет

модули уже другой вопрос, тут всё от степени кривизны рук автора

[JohnnyVega]

Вот видите, как плохо вы знаете ОК! А всё действительно плохо. Одно только сознательное и полнейшее повсеместное игнорирование DRY чего стоит.

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

 

Такое огромное количество различных сборок на основе ОК как раз и вызвано тем, что оригинальный ОК малопригоден для реального использования.

 

 

Соглашусь, пожалуй. Популярность OC обусловлена его простотой, относительно неплохой архитектурой (не хорошей, не идеальной, не жопной как в wp, а просто не плохой), относительной дешевизной обслуживания. Пожалуй и всё. Неплохой движок для обучения php, для старта ИПшэк или мелких фирм... Этакий автоваз или hyundai среди ecommerce...

 

Таже простота движка и как следствие "простота входа" в oc-разработку оказывается недостатком, когда заходит речь о качестве модулей, поддержки

[proctoleha]

Что на поверхности? Что вы выявили?

 

Вы издеваетесь? Выявляют беременность на ранних стадиях. Я же ничего не выявлял.

[Dotrox]

Неужели все магазины сразу выходят на 200к товаров?

Ну, от тебя то это слышать странно. Я сам сталкивался, когда магазин на 3к товаров еле открывался. Добавление индексов в базу его ускорило на порядок.

Ну, и дело ж не только в проблемах с количеством. А оригинальная система ЧПУ? А куча весёлых багов?

 

генерацию дольше 1-2 сек (без подсчета естесственно) на среднестатическом хостинге

Если ожидание ответа сервера (TTFB) для тела страницы занимает больше 500мс - это уже не нормально!

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

Как это ещё объяснить, если не тем, что он не подозревает, что бывают магазины, где больше тысячи товаров (да и на тысячи такой сайтмап генерируется не особо моментально).

[Otvet]

Как это ещё объяснить, если не тем, что он не подозревает, что бывают магазины, где больше тысячи товаров

стратегия нее? 

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

почему кабель для айфона защищен сертификатами? 

[chukcha]

И я вывалил то, что на поверхности.

Т.е. это не выявил, или навалил?

[JohnnyVega]

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

 

Как пример. Вместо улучшения архитектуры/апи/событий/поддержки пространства имён (выбрать нужное) впиливается адаптивность бутстрапа...

 

С точки зрения Даниэля всё ОК. Смысл делать движок, который из коробки будет работать как надо и подойдёт большинству пользователей? Тогда продажи модулей встанут...

 

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

[Dotrox]

Смысл делать движок, который из коробки будет работать как надо и подойдёт большинству пользователей? Тогда продажи модулей встанут...  

Для модулей и так места хватит. Сравнить, например, что есть из коробки в ОК и в ПрестаШоп. ОК до коробочного состояния ПрестаШопа модулями пихать и пихать. Но там другая беда: излишне сложный код и огромная прожорливость на любом количестве товаров (особенность архитектуры).

 

Так вот, если коробочный функционал настолько беден по сравнению с конкурентами, почему бы не сделать, чтоб хоть то, что есть, работало нормально?

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

[chukcha]

Для какой нормальной работы?

Чего не хватает в стандартной обертке?

[Dotrox]

Чего не хватает в стандартной обертке?

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

 

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

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

 

Про ЧПУ уже сказал выше.

 

Это то, что сейчас первым вспомнилось.

 

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

Змінено 5 грудня 2016 користувачем Dotrox

[chukcha]

про сайтмап

 

существует - принцип - формирования output

Есть спрос на карту изображений

Нате вам приблизительный интсрумент

В результате - уменьшается стоимость внешних модулей.

 

 

Количество товаров

Это не баг..

Это наследство... В поздних версиях этого нет?
потмоу что количество товаров растет

А при малом количестве товаров - и "так сойдет"

 

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

 

Это .. система учета.

ОК - торговая площадка, а не система учета. Работающая в реалиях ихнего мира.
 

 

Ты еще скажи что система учета НДС неверная.