Цитата

А чтобы форму создавать как-то так:

ага, еще и по табам разбить

И сделать рендеринг с кучей ифов, которых так не любят в шаблонах, потому как это Логика


$query = $this->db->select('*')->from('product')->where(...)->limit(10);

а где же фильтры?
А как удалять/заменять не нужное из фильтра

Не проблема понять синтаксис любого билдера

Вам удобно? пользуйте свой

Будет в движке? Сильно соменваюсь
 

Цитата

Дублировать тысячи строк кода это..

Кто вам мешает использовать макросы в твиге?
 

Цитата

 так как нужно будет выучить новые инструменты. 

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

даже не знаю что добавить. вроде все сказано. может быть orm и composer (PSR).

4 часа назад, chukcha сказал:

ага, еще и по табам разбить

именно для табов подобный подход будет исключительно полезен, так как
тот, кому хоть раз приходилось делать форму в которой были табы с двойной или даже тройной вложенностью, те понимают какой это ад, я когда-то создавал с тройной вложенностью, был верхний горизонтальный, потом вертикальный и потом еще табы для разных языков. Эту форму я писал несколько дней. И если в ней вдруг забыть случайно закрыть какой-то див или удалить случайно что-то, то все, можно и пол дня искать причину.. 
В конструкторе же можно легко сделать
'tab' => array(

  'name' => 'Tab1',

  'fields' => (...),

)
или 

'tab' => array(

  'name' => 'Tab1',

  'tabs' => (...)

)

И все работает, и можно делать хоть 2 вложенности хоть 3 хоть даже больше. 
 

4 часа назад, chukcha сказал:

Вам удобно? пользуйте свой

вы или плохо читали пост или не поняли его суть. 
Суть не в том, чтобы каждый использовал свой собственный инструмент, потому что толку с этого не будет никакого. Мало того, это будет настоящий ад потому что придется изучать синтаксис каждого модуля отдельно чтобы понять как с ним работать. + вопросы совместимости, производительности, конфликтов итд. 
Нужно что бы это было в самом движке, только тогда можно сделать систему Событий, которая позволит со всем этим работать и сможет дать расширяемость движка и уменьшение конфликтов. 
Опять же если какому-то разработчику будет не удобно работать напр. с конструктором запросов или форм, то он по прежнему сможет писать код по старому и он будет работать. 

 

31 минуту назад, sv2109 сказал:

И все работает, и можно делать хоть 2 вложенности хоть 3 хоть даже больше. 

Не... ведь этот массив надо сформировать..
Это сложнее, чем тупо линейно

Я прекрасно вас понимаю, но это идеология Даниеля

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

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

С 1 и 2 категорически не согласен в такой реализации. 

1. Достаточно инклюдить готовые наборы (куски) форм, контроллеры (форм), не нужно придумывать интерфейсы и не лишаем гибкости в верстке или уникальных контроллеров UI. Просто обычный include 'common/input_checkbox' или, еще лучше, через closure функцию

<?php echo $input_text($title, 'title', $error_title); ?>

2. Именно из-за чистого SQL запроса мне и нравится этот двиг. Здесь вообще ничего не надо менять, разве что DB_PREFIX я бы добавлял где-то в либе и, может быть, парсил запрос на предмет int|string для автоматического экранирования данных. Все, не надо выдумывать цепочки методов, вы 100 процентов уткнетесь в ограничения при написании сложных запросов и тогда пойдут велосипеды и каша из новых и старых методов исполнения запросов.

9 минут назад, SooR сказал:

int|string для автоматического экранирования данных.

PDO?

11 минут назад, SooR сказал:

2. Именно из-за чистого SQL запроса мне и нравится этот двиг. Здесь вообще ничего не надо менять, разве что DB_PREFIX я бы добавлял где-то в либе и, может быть, парсил запрос на предмет int|string для автоматического экранирования данных. Все, не надо выдумывать цепочки методов, вы 100 процентов уткнетесь в ограничения при написании сложных запросов и тогда пойдут велосипеды и каша из новых и старых методов исполнения запросов.

А я на вот эту няшку смотрю http://wiki.ubilling.net.ua/doku.php?id=nyanorm

И думаю, ну не няшно ли?

4 минуты назад, chukcha сказал:

PDO?

Можно и через pdo, кому как удобней, но в самом opencart, если мы говорим о моделях, сам API запросов я бы не менял

5 минут назад, Vladzimir сказал:

А я на вот эту няшку смотрю http://wiki.ubilling.net.ua/doku.php?id=nyanorm

И думаю, ну не няшно ли?

Если вам няшно - пожалуйста, я вижу, что из одной строки условно простого запроса сделали 4. В чем упрощение? Не видеть SELECT * FROM?

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

Второе автоэкранирование данных.

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

Ну и по мелочи. Например читабельность запроса. Особенно если он на десяток строк.

$payments->where('cashtypeid', '=', '1');
$payments->orWhere('cashtypeid','=','4');

Серьезно? Вам проще писать строку с запятыми и кавычками, чем просто строку?

Проще же WHERE foo = 'bar' AND baz = 3.

А копировать запрос и делать отладку прямиком в базу? А откорректированный запрос вставить в $this->db->query()? Не проще ли?

1 минуту назад, SooR сказал:

$payments->where('cashtypeid', '=', '1');
$payments->orWhere('cashtypeid','=','4');

Серьезно? Вам проще писать строку с запятыми и кавычками, чем просто строку?

 

Проще же WHERE foo = 'bar' AND baz = 3.

А копировать запрос и делать отладку прямиком в базу? А откорректированный запрос вставить в $this->db->query()? Не проще ли?

Экономим на запятых?

1 минуту назад, Vladzimir сказал:

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

С этим согласен, но на практике это будет не всегда так.

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

2 минуты назад, Vladzimir сказал:

Ну и по мелочи. Например читабельность запроса. Особенно если он на десяток строк.

Ну смотрите. Вы пишите сложный запрос, перед вами запрос в исходном виде, читаете док по мускулу или ищите другую инфу в сети по каким-то частям запроса, везде вы видите чистый запрос, во всех примерах и разборах только чистые запросы, переключаетесь в редактор, а там куча вызовов через php конструктора запросов. Как они работают закулисами? Что добавляют эти методы? Добавляют `` или нет? Каждый раз смотреть в ман по api? При этом держать в голове сам запрос, еще и думать как его расписать) По-моему не совсем удобно.

3 минуты назад, Vladzimir сказал:

Экономим на запятых?

Сводим к минимуму опечатки. Запятая не всегда на своей клавише, как и '

Но всегда же можно вывести "скомпилированный" запрос.

3 минуты назад, Vladzimir сказал:

Но всегда же можно вывести "скомпилированный" запрос.

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

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

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

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

27 минут назад, SooR сказал:

$payments->where('cashtypeid', '=', '1');
$payments->orWhere('cashtypeid','=','4');

Серьезно? Вам проще писать строку с запятыми и кавычками, чем просто строку?

 

Проще же WHERE foo = 'bar' AND baz = 3.

А копировать запрос и делать отладку прямиком в базу? А откорректированный запрос вставить в $this->db->query()? Не проще ли?

не проще. потому что в вашем случае, например, вы строку не экранируете

38 минут назад, SooR сказал:

Проще же WHERE foo = 'bar' AND baz = 3.

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

Конструкторы усложнят код - да, не сильно но усложняют. 
Но они дают преимущества, которые с лихвой перекрываю это. 
Одно из самых больших преимуществ - возможность использовать систему Событий для изменения любого! запроса в движке. И при системе событий и 2 и 3 и даже больше модулей могут изменить один запрос и конфликтов при этом будет в десятки раз меньше, так как все будет делаться через понятный api а не через str_replace или preg_replace. 

 

31 минуту назад, lexxkrt сказал:

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

смотрите в 4-ку
По идее почти так, например стандартные модули от опенкарт собраны в

extension\opencart\
 

25 минут назад, lexxkrt сказал:

не проще. потому что в вашем случае, например, вы строку не экранируете

А вы уверены, что обертка экранирует '1' как int, а не string? А как на счет экранирования bigint(20)?

Каждый судит по своему опыту и профилю. У меня, например, ни с чем из перечисленного проблем никогда не было. А с обертками были бы, потому что вот такой запрос переписывать в api обертки - увольте.

SELECT * FROM ( 
  SELECT 
    SUM(IF(f.result = 'success', 1, 0)) AS total_forecast_success, 
    SUM(IF(f.result = 'unknown', 1, 0)) AS total_forecast_unknown, 
    ROUND(SUM(IF(f.result = 'success', f.payable, f.amount)) - SUM(f.amount)) AS series_profit, 
    GROUP_CONCAT(f.forecast_id) AS forecasts_id, 
    COUNT(f.forecast_id) as total, 
    MIN(f.date_added) as date_start, 
    MAX(f.date_added) as date_end, 
    c.customer_id 
    
    FROM ( 
      SELECT customer_id, forecast_id, date_added, payable, amount, result, 
        
        IF(customer_id = @customer_id, @sequence, @sequence := @sequence + 1) AS c1, 
        IF(customer_id = @customer_id, @customer_id, @customer_id := customer_id) AS c2, 
        IF(result = 'unknown', @result := 'success', @result := result) AS r2, 
        IF(@result = @previous, @sequence, @sequence := @sequence + 1) as sequence, 
        IF(@result = @previous, @result, @previous := @result) AS r3 
         
        FROM forecast, 
        (SELECT @sequence := 0, @previous := '', @result := '', @customer_id := '') AS init 
          WHERE is_paid = '0' ORDER BY customer_id, forecast_id
     ) f 
     
     LEFT JOIN customer c ON (f.customer_id = c.customer_id) 
     WHERE (f.result = 'success' OR f.result = 'unknown') 
     GROUP BY sequence HAVING total > 1 
     ORDER BY total_forecast_success DESC, total_forecast_unknown ASC, series_profit DESC
) series WHERE date_end >= '2021-05-17'
GROUP BY customer_id 
ORDER BY total_forecast_success DESC, total_forecast_unknown ASC, series_profit DESC

1 минуту назад, chukcha сказал:

смотрите в 4-ку
По идее почти так, например стандартные модули от опенкарт собраны в

extension\opencart\
 

нет я сосем про другое. там просто папка расширения вынесена, но контроллеры модели а также папки расширений лежат раньше самих файлов. я же предлагаю порядок extensions/author/module_name/{controller,model,language,view}. т.е. модуль целиком в единой папке, а не по разным