3.0.0.0 или Что нас ждет

[sv2109]

Если кому интересно что такое Shopify.

Решил изучить немного, так как много о нем слышал, но все вокруг да около. 
А тут такая динамика роста на фоне упадка всех движков, что аж интересно стало. Спасибо @RGB за графики. 

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

Создал я тестовый магазин, все очень красиво, удобно, юзабилити на высоте, разобрался со всем за 3 минуты. 
По функционалу из коробки - достаточно слабо, по сравнению напр. с опенкарт там функций из коробки раза в 2 если не в 3 меньше. НО есть расширения, которыми можно добавить много всего. 
 

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

По коду
Писать расширения можно на любом серверном языке - RoR, php, Java, ASP итд. Но так как Shopify написан на RoR, то и больше всего инфы, книг итд. к сожалению именно на RoR.
Расширения сделаны необычно. То есть расширение в Shopify это не набор файлов, которые нужно загрузить на сервер, нет. 
Расширение в Shopify работает на своем сервере (PaaS типа heroku.com) и взаимодействует с магазином, где оно установлено, через webhooks (события) и API.
webhook - это событие, напр. создание товара, покупка товара итд. 
То есть если произошло событие, то Shopify уведомляет об этом расширение и расширение через API уже что-то делает (добавляет, удаляет, изменяет) С помощью API можно сделать что угодно, даже добавить и изменить свой html. 
То есть получается движок, который имеет очень хороший инструмент для расширения, свой магазин можно изменять как угодно. 
 

Короче, платформа очень крутая, интересная, популярная (говорят, что больше 300 тыс. пользователей), популярность только растет, но перейти на нее из опенкарта будет очень не просто, так как тут не просто другой движок или фреймворк, тут даже другой язык программирования, со своим шаблонизатором и кучей своих нюансов + SaaS, + PaaS + своя нестандартная система расширений, где все через API, + инфы для php достаточно мало. 
Но за подобными сервисами будущее, так как зачем кому-то учить 10 лет программирование, чтобы запустить магазин, если все можно сделать за 5 минут кликая мышкой?.. Вопрос риторический, наверное поэтому и такая популярность Shopify.
 

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

PS
если кому интересно, нашел книгу по разработке под Shopify, уже процентов 70 прочитал, правда читается достаточно тяжело, так как все примеры на RoR, а там очень специфичный язык, совсем не как php

https://drive.google.com/file/d/0B2qVovNZWDJlQkF4MmV5VHoxUkk/view?usp=sharing
 

Змінено 27 квітня 2017 користувачем sv2109
Добавил книгу

[markimax]

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

Если кому интересно что такое Shopify.

"SaaS" для домохозяек которые не знают что такое ftp, хостинг и т п
Я бы сказал "постричь" обывателей и выбить побольше монет из них.
Такой себе конструктор магазинов.
Хотите Enterprise ? Magento
Кстати по статистике
Есть в Firefox такой себе wappalazer - он не дает точных данных но дает четкое представление о соотношении
1. Фукоммерс (ну понятное дело WP же)

2. Shopify (здесь тоже понятно - домохозяйки) Кстати не далеко ушел от Opencart и Magento

3. Magento
4. Opencart

5. Presta

[sv2109]

3 minutes ago, markimax said:

"SaaS" для домохозяек которые не знают что такое ftp, хостинг и т п

этих "домохозяек" уже почти 400 000 и они дают оборот почти 400 млн.$ в год.. и если посмотреть на тренды, то популярность Shopify растет бешеными темпами, в то время, как все обычные движки проседают и это продолжается уже года 3 и дальше будет продолжаться. SaaS может нравится или нет, но цифры говорят сами за себя. 
Да, для большого, сложного и нестандартного магазина это не подойдет, но такие магазины это 2,3, ну самый макс. 5%, а 95-98% это самые обычные магазины, с самыми обычными товарами, категориями, производителями, статьями, корзиной итд.. Для таких магазинов и используется опенкарт (не для больших и сложных, а именно для таких), престашоп и другие. И для таких магазинов Shopify подойдет на ура, пару кликов мышки - и готовый магазин. Еще пару - и установлены и работают десяток модулей, еще пару - тема. Все, магазин можно запускать. Для пользователя главное не движок или SaaS или ftp или php или еще что-то, для него главное - прибыль. И если движок приносит прибыль, да еще и с минимальными затратами денег и времени, то его популярность будет только расти. 

[markimax]

2 часа назад, sv2109 сказал:

этих "домохозяек" уже почти 400 000 и они дают оборот почти 400 млн.$ в год..

 

И да, "домохозяйки" они такие   Можем вспомнить golos тот же... 
Им не важна "ваша" архитектура и FW. Им главное меньше думать про разные хостинги, ftp и т.п.

Пару кликов и магазин "готов" продавать
Т.е. Shopify  как бы удаляет "посредника" - хостера

Сами и ответили

Цитата

Да, для большого, сложного и нестандартного магазина это не подойдет

 

А в opencart сошлось все вместе. И простота для домохозяек и простая современная архитектура без лишнего "перегруза" для разработчиков

Думаю Даниэлю лучше на базе opencart отделить форк (типа opencartcloud) и сделать свой облачный сервис без "хостинга, ftp"  и т п  для домохозяек

 

А opencart подпилить для более серьезных целей, а не мешать все в одну кучу
 

[andrus]

Господа, немного удивило читать упоминания об вордпрессовском  WooCommerce, его положительных или отрицательных сторонах. К чему спор? Все эти "ВиртуМарты" и вукомерцы - это же просто надстройка поверх универсально-народного движка-CMS. По всему миру, владельцы блогов на WP положительно восприняли этот модуль, как на автомате - "есть и здесь такое? ну и отлично же!". В Джумла, на которой можно построить любой тип сайта, тоже не обошли стороной наличия у себя такого дополнения. 
Популярность и похвалу этим надстройкам создали пользователи, потому что на период 2005-2010  "знаменитыми CMS" с поддержкой и сообществами(форумы) являлись выше упомянутые. Немного стадный эффект, из-за отсутствия рабочих на тот момент других решений. Большинство других были на стадии допиливания и выяснения что нужно туда вкл. Создать Инет-магазин, даже DLE предлагали)

Тут больше интерес к сложному CMF, после юзания CMS. Еще и этот SaaS появился, тащащий полностью к себе клиента. И я так понял даже выручку магазинов, размещённых у них, малость  отбирают себе? Поясните что это такое, может и не то понял: Комиссия за транзакции от 0,5% до 2,0% (по этой ссылке таблица прайсов) Модуль "Восстановить брошенную корзину" - это какой-то особый у них функционал, что его нет на минимальном тарифе? Магазин дополнений что-то не нашёл.

Зная Opencart, и то что можно на нём построить (а создать на ocStore 2.1.0.2 можно очень функциональный магазин!) что из ниже перечисленных CMF/CMS можно взять во внимание? Т.е. помимо опенкарта хотелось бы изучить CMF, но какую? Я даже не понимаю кто из них теперь SaaS, а кто продают свой  исходный код для дальнейшего размещения на любом хостинге:

- MODX
- UMI.CMS
- HostCMS
- CS-Cart
- Simpla
- Amiro.CMS

Змінено 27 квітня 2017 користувачем andrus

[HyperLabTeam]

Я вам один умний весч скажу - но ви толко необижайтес.

Берите всей толпой 2.3 и развивайте в своём направлении нах вам Дениэль с его причудами?
всё что нужно из модулей для магаза есть на форуме, и если каждый разработчик будет предлагать, вкладывать свои наработки в направлении к улучшению движка то скоро там от опенкарта только история останется. Чем мы хуже не пойму?
И даже если и не плевать в сторону опенкарта у многих уже все модули под пачку версий, вот будет одна для осStore вторая для опенкарта а у кого то и вовсе универсальная.
Я так думаю.
))

[destreser]

В 27.04.2017 в 11:22, AWARO сказал:

Берите всей толпой 2.3 и развивайте в своём направлении нах вам Дениэль с его причудами?

И тишина... (что характерно). Видимо, не такая уж 3й версия и плохая будет

[chukcha]

Да причем здесь это?
Есть два шаблонизатора.
Вот и будут они оба дружить..
Ну, и лишние запросы, будут порезаны.

Так что ставить крест на 3-ке рано.
А с переходом на 7.х можно будет и последнюю версию твига зацепить

 

[sv2109]

1 hour ago, destreser said:

И тишина... (что характерно). Видимо, не такая уж 3й версия и плохая будет

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

У меня появилась идея перенести опенкарт на какой-то популярный фреймворк.. Было бы здорово, так как у опенкарта есть очень хороший функционал магазина из коробки (разные скидки, купоны, опции итд.) но очень ужасное ядро. А у фреймворков наоборот - очень хорошее ядро, но нету никакого функционала магазина, все нужно писать. А если бы объединить, то мне кажется был бы почти идеальный движок - и функциональный и с хорошей архитектурой и с кучей готовых библиотек. 
+ у популярного фреймворка есть куча сторонник, которые его знают, и начать иcпользовать движок, который на нем написан для них вообще не проблема. 
Первым на ум пришел CodeIgniter за счет того, что он очень простой и быстрый и даже по синтаксису многим напоминает опенкарт, некоторые люди при первом знакомстве с опенкартом сразу спрашивают "он что, на CodeIgniter-е написан?" Возможно Даниел и взял кое что из этого фреймворка при создании движка. НО CodeIgniter это сильно устаревший и полумертвый фреймворк. Сейчас новая команда хочет его воскресить и выпустить 4 версию, но не понятно когда это будет, и что с этого выйдет. А для работы нужно брать популярный, активно развивающийся фреймворк. 
Другой вариант - Yii, я как раз серьезно начал его изучать. Тут нету тех недостатков, которые есть в CodeIgniter, он очень популярный, активно развивается, а также очень быстрый и гибкий, и при этом также относительно простой (в сравнении с напр. Symfony с классами типа AbstractInterruptibleBatchPreparedStatementSetter и неймспейсами типа \Symfony\Bundle\SecurityBundle\DependencyInjection\Security\Factory\SecurityFactoryInterface).

[Dotrox]

В 28.04.2017 в 18:56, sv2109 сказал:

нету никакого функционала магазина, все нужно писать.

Если переносить ОК на фреймворк, то первым делом придётся переписать все модели и в идеале не просто обернуть запросы в DAO (в случае Yii), а хотя бы переписать на Query Builder (в случае, опять же, того же Yii). И модели - это просто самый лаконичный, но при этом объёмный пример, но далеко не единственный.

 

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

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

 

Ну, и если делать публичный движок, то первая задача, которую надо перед собой поставить - это нормальная система расширений (чем ОК похвастаться вообще не может)!

[markimax]

Все такие "вумные" насчет перевода на FW ... начинает "тошнить" от занудства вашего, без обид.

Ну перевели Drupal на Symfony 2... и что ? Вообще почти "потух" проект. Скорость снизилась в 2-3 раза, куча лишнего перегруженного кода, расширения старые не подходят, новые никто писать не хочет...
Вы это хотите ?!
Заканчивайте демагогию по FW. В opencart все нормально с архитектурой. Добавить только "людский" формирователь запросов и немного оптимизировать архитектуру БД.

[Dotrox]

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

Ну перевели Drupal на Symfony 2... и что ? Вообще почти "потух" проект.

Это была его судьба. Вы тут распинались, какое дерьмо WP, так вот, Друпал - это было тоже самое, но в квадрате. А тормознутым он был и без Симфони!

 

 

32 минуты назад, markimax сказал:

Заканчивайте демагогию по FW.

 

Цитата

Демагогия (др.-греч. δημαγωγία «руководство народом; заискивание у народа») — набор ораторских и полемических приёмов и средств, позволяющих ввести аудиторию в заблуждение и склонить её на свою сторону, с помощью ложных теоретических рассуждений, основанных на логических ошибках (софизмах).

https://ru.wikipedia.org/wiki/Демагогия

 

И вот вам пример демагогии: Друпал переписали на фреймворк и он "потух" - значит переписывание на фреймворк вредно.

[markimax]

17 минут назад, Dotrox сказал:

Это была его судьба. Вы тут распинались, какое дерьмо WP, так вот, Друпал - это было тоже самое, но в квадрате. А тормознутым он был и без Симфони!

 

Да был и без Symfony 2 тормозом и даже тормознее WP
Но после перевода на Symfony 2- стал еще тормознее в 3 ! раза чем 7-я версия

Opencart сам по себе становится FW. И не надо ему перегруженности. 
"Drupal" - это хороший наглядный пример тем кто сопли пускает по FW -кам

 

[HyperLabTeam]

мне один с пеной у рта  хвалил вот это
https://phalconphp.com/ru/
говорит лучше нема)

 

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

отсюда
http://www.skillz.ru/dev/php/article-popular-php-frameworks-benchmarks.html

и тут
https://github.com/kenjis/php-framework-benchmark

вот это в анекдоты можно засунуть
http://www.skillz.ru/dev/php/article-first_c_otkake.html

[sv2109]

22 hours ago, Dotrox said:

Если переносить ОК на фреймворк, то первым делом придётся переписать все модели и в идеале не просто обернуть запросы в DAO (в случае Yii), а хотя бы переписать на Query Builder (в случае, опять же, того же Yii). И модели - это просто самый лаконичный, но при этом объёмный пример, но далеко не единственный.

 

 

Я не еще не очень хорошо знаю Yii, но даже при моих знаниях понятно, там все нужно переписывать..  если использовать фреймворк, то мне кажется, нужно использовать его по полной, а не только поменять несколько базовых классов, тогда уже модель делать через Active Records, добавлять правила валидации, фильтры итд. Переписывать представления, добавлять Active Forms, хелперы, блоки, виджеты. Переписывать контроллеры, так как там будет все не так. 
Да даже саму базу нужно изменять, переводить на InnoDB так как там есть поддержка связей, а они нужны для Active Records переводить все под стандарт фреймворка. Правда не понятно, если делать модель через Active Records то как ее потом из модулей изменять через события. Моих базовых знаний фреймворка для этого пока не достаточно. А система расширений должна быть очень хорошей. 
Короче, работы там не просто много, а очень много + нужно не просто знать и даже не хорошо знать, а желательно очень хорошо знать фреймворк, чтобы перевести на него магазин типа опенкарта. Нужна команда человека 3 мин. с хорошими (а желательно очень хорошими) знаниями фреймворка и опытом работы с ним + времени с год минимум (это только кажется что все быстро и просто, за месяц сделается.. ) Но если это сделать то перспективы очень неплохие если его еще и получится раскрутить (а если сделать действительно хорошо, то я верю, что да, так как и с опенкарта могут перейти многие и с сообщества фреймворка). Так как можно и магазины делать клиентам на своем движке (причем все типы, даже большие и сложные в отличии от опенкарта, так как новый движок для этого подойдет), оказывать поддержку от разработчиков за очень хорошие деньги, это и свой магазин расширений и в будущем может даже свой SaaS итд. Короче, если сделать, то и работа и деньги будут. Но сделать очень непросто. 

 

21 hours ago, AWARO said:

мне один с пеной у рта  хвалил вот это
https://phalconphp.com/ru/
говорит лучше нема)

 

Мне кажется, что идеального фреймворка нету априори. Ведь фреймворк - это инструмент, а инструмент нужно использовать там, где он лучше всего подходит, для одного проекта подойдет один, для другого другой итд. Какой-то фреймворк очень простой, но мало функциональный, какой-то имеет очень хороший функционал, но слишком сложный в изучении, какой-то работает быстро, какой-то медленно, наличие документации, сообщества, поддержка последних версий php, развивается ли он или уже 3 года не обновляется итд. Поэтому оценивать фреймворк нужно обязательно с проектом для которого он будет использоваться. А говорить, что фреймворк (или движок) х лучше всех может только человек, который кроме этого фремворка (или движка) ни с чем лучше не работал, поэтому конечно, для него именно это будет наилучшим.. Вот у нас тут markimax говорит, что опенкарт самый крутой движок и даже фреймворк с просто идеальной архитектурой  

Смотрю этот фалкон, это оказывается фреймворк, который поставляется как C расширение.. да, из-за этого он просто мега быстрый, но его нужно специально устанавливать на сервер через "sudo apt-get install php5-phalcon", подключив его репозиторий + устанавливать доп. библиотеки типа gcc, поэтому на шаред хостинге его не установишь (то есть для магазина, которым будут пользоваться все уже не подойдет) + код не прочитаешь + популярность наверное из-за этого у него небольшая, сообщество маленькое, по сравнению с другими фреймворками. Так что да, скорость большая, а все остальное наоборот. Вот и "супер" фреймворк. 

[ocdev_pro]

Зря вы за фреймворки заговорили) Все равно этого никогда не будет и не 1 разумный разработчик не станет Opencart переносить на  FW.
1 нужно куча времени
2 за это никто не заплатит
3 учитывая первых 2 пункта, поддержка сама собой отпадает...
Написать его еще ладно люди может и найдутся (на энтузиазме), продать этот продукт крайне сложно. 
Сделать можно только если есть команда (может студия), под себя делать продукт и пропихивать в массы, а параллельно делать на нем же проект для новых клиентов, что бы хоть как-то оправдывало затраты..

Но как по мне это утопия..

[Dotrox]

В 01.05.2017 в 01:02, AWARO сказал:

мне один с пеной у рта  хвалил вот это

Первый пункт киллер-фич гласит:

Цитата

Расширения на Zephir/C загружаются вместе с PHP один раз, при запуске демона веб-сервера

И мне сразу же вспомнился Python под uWSGI, где при запуске вассалов (воркеров) не только используемый фреймворк (любой), но и всё приложение в целом обрабатывается интерпретатором и загружается в память, откуда и принимает запросы (и, вроде, он так работает с любым WSGI сервером). В принципе, код на С всё равно должен быть заметно быстрее ввиду строгой статической типизации, но не уверен, насколько этим преимуществом можно воспользоваться, если этот код выполняет роль php фреймворка.

 

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

 

 

5 часов назад, sv2109 сказал:

Правда не понятно, если делать модель через Active Records то как ее потом из модулей изменять через события.

ActiveRecord напичкан событиями!

Например, если надо перехватить выполнение перед вставкой:

Event::on(ActiveRecord::className(), ActiveRecord::EVENT_BEFORE_INSERT, function ($event) {
    //обработка события
});

А в $event->sender будет экземпляр ActiveRecord, на котором сработало событие.

 

 

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

не 1 разумный разработчик не станет Opencart переносить на  FW.

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

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

 

 

В 01.05.2017 в 00:41, markimax сказал:

Но после перевода на Symfony 2- стал еще тормознее в 3 ! раза чем 7-я версия

По графикам выше хорошо видно, что Symfony далеко не самый быстрый фреймворк (очень далеко), что, в общем-то, и так общеизвестный факт, для тех, кто интересуется фреймворками. Если на этих графиках сравнить Symfony2 и Yii2, можно заметить, что Symfony почти в 4 раза медленнее и при этом жрёт почти в 3 раза больше памяти.

 

В 01.05.2017 в 00:41, markimax сказал:

Opencart сам по себе становится FW. И не надо ему перегруженности. 

Каким местом он становится фреймворком? Вопрос не риторический и хотелось бы увидеть конкретные примеры из кода!

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

 

 

В 01.05.2017 в 00:41, markimax сказал:

"Drupal" - это хороший наглядный пример тем кто сопли пускает по FW -кам

Вам стоит ещё раз перечитать статью в Вики про демагогию

 

А Друпал это пример только того, что дерьмовый движок фреймворком не спасти.

 

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

 

Любой фреймворк - только инструмент, всё остальное зависит от прямоты рук (и не прямоты извилин) тех, кто его использует.
 

[sv2109]

12 hours ago, Waha said:

Зря вы за фреймворки заговорили) Все равно этого никогда не будет и не 1 разумный разработчик не станет Opencart переносить на  FW.
1 нужно куча времени
2 за это никто не заплатит
3 учитывая первых 2 пункта, поддержка сама собой отпадает...
Написать его еще ладно люди может и найдутся (на энтузиазме), продать этот продукт крайне сложно. 
Сделать можно только если есть команда (может студия), под себя делать продукт и пропихивать в массы, а параллельно делать на нем же проект для новых клиентов, что бы хоть как-то оправдывало затраты..

Но как по мне это утопия..

 

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

 

7 hours ago, Dotrox said:

 

Event::on(ActiveRecord::className(), ActiveRecord::EVENT_BEFORE_INSERT, function ($event) {
    //обработка события
});

А в $event->sender будет экземпляр ActiveRecord, на котором сработало событие.

 

 

 

это я знаю, что в Active Records есть свои события, да таким образом можно выполнить свой код, добавить напр. какой-то Behavior, я имел ввиду как изменить сам sql запрос. Если например из модуля нужно добавить какое-то свое новое условие в запрос или подключить новую таблицу, получить новое поле из нее итд. Active Records это же по сути она таблица со связями.. Если делать через конструктор запросов то можно через событие модулю передать какой-то объект $query и из своего модуля сделать что-то типа $query->addWhere() или $query->addJoin() итд. то есть полностью изменить запрос и вернуть уже измененный класс конструктора запросов и движок уже выполнит этот запрос вместо старого. А как такое сделать с Active Records не понятно, ведь нужно дать модулям возможность изменять практически любой запрос..

[ocdev_pro]

sv2109, Вот все такие умные бы были... почему до сих пор никто не портировал? Дело не в том что можно сделать.. не спорю, но 2 главных вопроса - кто кодить будет? И кто продавать его будет? Если лохов энтузиастов еще можно найти в сей стартап и пообещать за пару лет их жизни  "золотые горы" - что платформа взлетит, то продажник нормальный сюда и не сунется.
Вы господин продажник прям от бога или маркетолог великий? .. вот и я нет, как и множество других разработчиков. Поэтому сделаете свое чудо, но пока оно выстрелит и начнет покрывать расходы на свое создание вся команда помрет от голода.
 

Можно на YII писать, на Laravel или Symphoni (смотря что лучше знаете) - но потом будут приколы с обновлением самого FW, пакетов к нему итд... Насколько эта платформа сможет подстраиваться? 
У нас был случай когда проект написанный на Laravel 4 обновляли на Laravel 5.. Убили тонну времени - удовольствия было 0.
Так что все эти разговоры о e-commerce "типо opencart или даже лучше" на FW - не более чем пустой звук.... пиз**больство

 

Вот в этой ветке еще немного попишем как было бы круто и каким бы мир стал после выпуска "своего" opencart на FW, а потом выйдет Opencart 3+ все успокоятся, пуканы остынут и дальше будем пилить модули, магазины и жизнь примет прежнее русло.. Так что не надрывайтесь этот недуг у всех скоро пройдет.

[Dotrox]

2 часа назад, sv2109 сказал:

я имел ввиду как изменить сам sql запрос.

Этого не надо делать! Если выбран ActiveRecord, то работать нужно исключительно с объектами. Для работы с SQL в чистом виде есть DAO, для более абстрактного подхода - Query Builder. Но, на самом деле в этом всём нет необходимости (подробнее ниже).

 

 

2 часа назад, sv2109 сказал:

Active Records это же по сути она таблица со связями

Не совсем. За основу взята одна таблица, но экземпляр ActiveRecord даёт доступ ко всем данным объекта. То есть, если это товар, то через этот объект можно получить и описание, и опции с атрибутами (со всеми потрохами) и любые другие данные, которые могут понадобиться. Для этого есть внешние ключи и ленивая загрузка.

 

2 часа назад, sv2109 сказал:

ведь нужно дать модулям возможность изменять практически любой запрос..

Я такое часто вижу при переходе людей с Apache на nginx - они пытаются писать конфиги по аналогии с Apache. Вот и вы сейчас думаете критериями ОК. Модулям не нужна возможность менять непосредственно запросы - в ОК это продиктовано отсутствием хоть каких-либо альтернатив. В случае ActiveRecord модули могут работать на более высоком уровне абстракции.

 

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

Event::on(Product::className(), ActiveRecord::EVENT_BEFORE_INSERT, function ($event) {
    $slug = Translit::t($event->sender->name);
    $event->sender->slug = $slug;
});

Хотя, это тоже не совсем Yii way, ибо такое в Yii принято делать через бихейверы. И, кстати, это тоже вариант расширяемости: модули в виде бихейверов. Но главное, что тут нет и намёка на прямую работу с запросом.

Тут главный вопрос - как организовать динамические атрибуты в ActiveRecord. Само поле то в базу добавить через миграцию при установке модуля - не проблема, но ActiveRecord должен узнать о его существовании, иначе он не сможет с ним полноценно работать. В принципе, в Yii2 есть DynamicModel, но с ходу не особо представляю, как это всё организовать.

 

 

 

[Dotrox]

 

49 минут назад, Waha сказал:

но потом будут приколы с обновлением самого FW, пакетов к нему итд... Насколько эта платформа сможет подстраиваться? 
У нас был случай когда проект написанный на Laravel 4 обновляли на Laravel 5.. Убили тонну времени - удовольствия было 0.

 

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

Движок не должен использовать фреймворк в качестве скелета, он должен его использовать только в качестве альтернативы написания определённого не доменного функционала с нуля.

[sv2109]

7 hours ago, Waha said:

Можно на YII писать, на Laravel или Symphoni (смотря что лучше знаете) - но потом будут приколы с обновлением самого FW, пакетов к нему итд... Насколько эта платформа сможет подстраиваться? 
У нас был случай когда проект написанный на Laravel 4 обновляли на Laravel 5.. Убили тонну времени - удовольствия было 0.
Так что все эти разговоры о e-commerce "типо opencart или даже лучше" на FW - не более чем пустой звук.... пиз**больство

 

а я не вижу вообще никаких проблем с обновлением
1. новые версии фреймворка, которые имеют какие-то кардинальные изменения выходят не так и часто. В Yii смотрю по вики, первая версия - 2008 год, вторая - 2014, то есть 6 лет. Между этим выпускаются какие-то минорные версии, где добавляются какие-то новые компоненты, исправляются какие-то баги, но в основном никаких проблем с совместимостью по логике быть не должно, если и есть то очень небольшие и все документируется.
2. не обязательно обновляться сразу на следующий день как только выйдет какая-то новая версия фреймворка, зачем? Если куча систем которые годами работают на не самых новых версиях фремворка. По крайней мере год-два вполне можно, за это время вполне можно неспеша перенести все на новую версию. 
3. обычно есть куча документации и мануалов как обновиться с одной версии на другую.

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

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

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

7 hours ago, Dotrox said:

...
Тут главный вопрос - как организовать динамические атрибуты в ActiveRecord. Само поле то в базу добавить через миграцию при установке модуля - не проблема, но ActiveRecord должен узнать о его существовании, иначе он не сможет с ним полноценно работать. В принципе, в Yii2 есть DynamicModel, но с ходу не особо представляю, как это всё организовать.

Спасибо, понял что мне еще много всего нужно выучить в Yii
По динамическим атрибутам - а зачем? Это и реализовать сложно и потом тем, кто будет писать модули разобраться с этим будет еще сложнее. 

Как вариант сделать как-то так:
class BaseProduct extends \yii\db\ActiveRecord
тут Active Records
дальше

class Product extends BaseProduct
тут методы работы через QueryBuilder, напр.
getProduct() {
  // событие before
  получение товара через $query
  // событие after
}

то есть вместо динамических атрибутов дать возможность модулям самим добавить любое поле (или изменить существующее) динамически, но не через Active Records а в методе Product. Как-то так. Не знаю насколько это правильно, но зато очень просто. 

Или посмотреть как это у других реализовано, в Yii должны быть какие-то cms готовые с системой расширений реализованной. 

[Dotrox]

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

По динамическим атрибутам - а зачем? Это и реализовать сложно и потом тем, кто будет писать модули разобраться с этим будет еще сложнее. 

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

 

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

Как вариант сделать как-то так:
class BaseProduct extends \yii\db\ActiveRecord
тут Active Records
дальше

class Product extends BaseProduct
тут методы работы через QueryBuilder, напр.

Так нельзя делать. Если Product - это потомок ActiveRecord, он не должен использовать QueryBuilder. По крайней мере не для работы с собственными же полями!

Да и такая смесь сильно усложнит архитектуру моделей.

Для начала нужно попытаться реализовать всё через ActiveRecord. Если окажется, что это невозможно, тогда использовать только QueryBuilder.

 

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

[sv2109]

10 hours ago, Dotrox said:

Так нельзя делать. Если Product - это потомок ActiveRecord, он не должен использовать QueryBuilder. По крайней мере не для работы с собственными же полями!

Да и такая смесь сильно усложнит архитектуру моделей.

Для начала нужно попытаться реализовать всё через ActiveRecord. Если окажется, что это невозможно, тогда использовать только QueryBuilder.

 

я этот код взял из кода, который был сгенерирован через Gii, он не может быть не правильным, вот например:
 

Spoiler

class User extends \yii\db\ActiveRecord

class UserSearch extends User
{
...
    public function search($params)
    {
        $query = User::find();
    
        // add conditions that should always apply here
    
        $dataProvider = new ActiveDataProvider([
            'query' => $query,
        ]);
    
        $this->load($params);
    
        if (!$this->validate()) {
            return $dataProvider;
        }

        // grid filtering conditions
        $query->andFilterWhere([
            'id' => $this->id,
            'date_entered' => $this->date_entered,
        ]);

        $query->andFilterWhere(['like', 'username', $this->username])
            ->andFilterWhere(['like', 'email', $this->email])
            ->andFilterWhere(['like', 'pass', $this->pass])
            ->andFilterWhere(['like', 'type', $this->type]);

        return $dataProvider;
    }
}

 

только для меня это пока еще магия )) есть Active Records, Active Query, Active Data Provider, есть просто Query Builder я пока запутался и не понимаю что с чем и как взаимодействует.  

[Dotrox]

1 час назад, sv2109 сказал:

я этот код взял из кода, который был сгенерирован через Gii, он не может быть не правильным, вот например:

Ну, этот пример то правильный, но здесь ведь нет QueryBuilder

Всё происходит через User, который потомок ActiveRecord. Кроме того, это модель поиска - она не является репрезентацией объекта User (все атрибуты и правила их обработки уже объявлены в классе User).

 

А методы типа andFilterWhere - это часть QueryTrait, который используется многими классами, в том числе ActiveQuery, который под капотом у ActiveRecord.

QueryBuilder - это более низкоуровневый интерфейс, вся суть которого отражена в названии: он просто помогает писать запросы к базе не используя в коде SQL (без крайней необходимости).

 

Главное логическое отличие между ActiveRecord и QueryBuilder в том, что ActiveRecord понимает с чем он работает и знает как правильно эти данные обрабатывать, а QueryBuilder - просто абстракция над SQL, для которой все данные формально одинаковы.

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

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