И этот действительно богатый набор встроенного API по сути и выделяет его из массы других движков на сегодня и даёт вход в категорию CMF (content management framework), вроде как среднее звено между традиционным сайтовым движком и полноценным php web-фреймворком.
У WP или Joomla по вашему API меньше? Ссылку бы хотя бы на API оставили, чтобы понимать масштаб :) Забавно что вы мерите категорию фреймворк/не фреймворк размером API. Slim и емуподобные конечно грустят в сторонке от такого неравенства.
...стабильность движка с продуманной кодовой основой.
Что вкладывается в слово "стабильность"? Наличие мажорной цифры в номере версии? Малое число issue, а также отсутствие тестов (по крайней мере в репе) говорит скорее об обратном и том что могут быть скрытые дефекты.
Стабильно плохо - это все равно плохо :)
Касательно уникальности & гибкости дизайна - тут опять свобода (а это часто предполагает ответственность), задействуй css библиотечки на вкус и на тебе авторский сайт(!)
А у кого нет?
какие поля не создавай в админке, сообразно таблицы и типы формируются в базе, и далее манипулируются через ту же админ-панель.
А у кого нет?
Безопасность, производительность, ... - это всё про PW.
Плюс в комментариях выше правильно написали про использованную память. Я думаю стоит также добавить в статью сколько памяти сожралось при том или ином варианте.
Ну и еще как вариант можно запросы делать пачками по 1К, 10К, 100К элементов, а не собирать один большой монструозный запрос
В данном случае сущности 1 к 1 отражают таблицу и то как хранятся в базе сущности. Дополнительно к этому они нагружены еще и бизнес-логикой. У вас не получиться в эти объекты добавить логику и данные, которые будут идти в разрез с БД - доктрина подавится.
То что что в данных объектах нет метода save и delete, т.е. они не инкапсулируют в себе работу с базой, это еще не значит что они не AR (возможно не совсем в классическом понимании).
Партиции хранятся в одной БД, шардирование это разнос данных по разным БД. Условие разделение уже задаете какое вам нравится в обоих случаях (в случае с шардированием можете часть таблиц целиком вынести на другой сервер).
Ну то есть вы не разобрались как работает метод тестирования, какие есть у него варианты, не стали гуглить или хотя бы читать описание к самим методам, а просто решили написать статью о своей глупости?
Альтернатива: сниппет в IDE и не нужен никакой сомнительный велосипед
С несколько меньшей дальше пойдёт изучать язык. Станет отличным бекендером битрикса, ибо знает поверхность админки уже как свои пять пальцев
Опять же:
Только вопрос: как мне это развидеть? Что помешало сделать таблицы для компонентов, и для конфигов (а это конфиг реально), и вместо вороха строк передавать ID записи в базу?
1 компонент может иметь несколько шаблонов, и кучу мест использования (все это по вашей теории нужно хранить в базе). С таким же успехом предлагайте в Yii2 виджеты хранить в базе.
Плюс в таком варианте кеширование компонента будет работать все равно с базой, вместо того чтобы просто сразу все выплюнуть из кеша.
Ну и собственно такая простыня параметров нужна для того чтобы компоненты были как можно более универсально (чтобы люди могли спокойной в виз редакторе натыкать нужные параметры и не заглядывать в код или кастомизировать шаблон/компонент).
Ну и, опять же, в моём учебном проекте было ещё до меня... 744 таблицы
Это вы еще Битрикс24 не смотрели, где 1.3К таблиц. Правда если спросить "а в чем проблема?" вы вряд ли сможете дать ответ.
Веселят конечно люди, которые засирают Битрикс поработав на нем 1-2 дня/недели, и потом говорят насколько в нем все плохо. Ах да и пишут на старом коде версии этак 15-ой. С таким же успехом можно говнить Yii2 приводя примеры из Yii1. Если не нравится писать на файлах - пишите контроллеры к роутеру который есть в Битрикс (неожиданно правда, а он оказывается есть);
Судя по вашему описанию "есть карточка с артикулами, а остальное хранится в базе" вы вообще понятия не имеете как устроена архитектура: есть страница (на ней подключается пролог и эпилог), на этой странице указываются компоненты (хоть руками, хоть из виз. редактора), внутри компонента уже есть логика и шаблоны.
Если вы смотрите на задачу с точки зрения верстальщика, то вам нужны только шаблоны - обычные php файлы с версткой, которым компонент скормил данные для отображения (удивительно, но это ой как похоже на View из MVC, но в других фреймворках у вас это вопросы не вызывало, а тут почему-то вызывало).
Да и подключение файлов style.css и script.js к шаблону компонента происходит автоматически, и не обязательно дергать Assets для ручного подключения.
Прежде чем выплескивать кашу из своей головы, я думаю стоит почитать документацию как работать с Битрикс, а не какие-то рандомные статьи из интернета.
Опять же, двойные стандарты: почитать доку к какому то фреймворку - ок, так и нужно делать. А вот для Битрикса - нахер надо, по наитию не пойму - Битрикс говно. Логика - великолепная :)
Если нормально писать модули и компоненты то никакой проблемы нет (уже лет 5 наверное).
Все что внутри директории модуля /lib автоматически загружается (даже оказывается согласно PSR-4, но автору об этом знать не обязательно, пусть дальше живет в своих розовых фантазиях о ларавеле :)
PSR-4 это стандарт, а пространство имен уже языковая приблуда. В контексте компонентов пространство имен подразумевает директорию с компонентами одно вендора. Вас же почему-то не смущает, что пространство имен JS никакого отношения к PSR не имеет.
а) файл компонента component.php
Файл "class.php" в сторонке: ну да, ну да, пошел я на хер.
Спойлер: с трудом. Надо пойти в визуальный редактор, добавить тестовую страничку
Трудно - это наверное добавить вызов $APPLICATION->IncludeComponent там где это нужно без визуального редактора. Мне бы ваши трудности конечно.
Битрикс - не для хорошей жизни, терпеть его надо.
Когда нихера не умеешь и не знаешь, то вместо Битрикс с успехом можно подставить любую CMS и фреймворк ;-)
Время зависит от того какой у вас процесс разработки.
Если по SSH напрямую подключиться и на горячую внести правки, то это будет минут 20.
Если говорить про SVN: создали ветку, локально поправили, проверили, создали MR, отправили на ревью, смержили, отгрузили.
Если говорить про реалии: создали ветку, локально поправили, отвлекся на другую задачу (потерял контекст), вернулся к задаче (восстановил контекст), проверил, отвлекли в чате (потерял контекст), вернулся к задаче (восстановил контекст), создал MR, отправил на ревью, спустя 3 дня по ревью пришли правки, ну и т.д.
Так что 2-3 часа это оптимальный срок на решение задачи, а на написание кода действительно минут 10-20 потребуется :)
делов на минут 20... а тестировать то и нечего
Проверка правильной логики ресайза, проверка верстки, чтобы ресайз корректно садился, проверка на разных экранах/устройствах.
2-3 часа на тестирование отображения отресайзеной картинки, которые выливаются в 2 ветки условий в result_modifier.php с функцией CFile::ResizeImageGet?
И да, я имел ввиду трудозатраты на разработку, но тестинг точно займет не 2-3 часа, даже если это автотесты.
А по итогу всего-то надо было использовать встроенную функцию CFile::ResizeImageGet :-)
Теперь нам эту таблицу нужно скачать как обычную Excel таблицу
SQL запрос сделать товары join файлы, не?
И с помощью элемента множественная загрузка загружаем все наши фотографии.
Программисты, без комментариев.
Что вернет нам такой запрос? Таблицу с полными данными о файлах в файловой системе Битрикса
А все таки про SQL вы знаете :)
Ну и самый главный вопрос, а как вообще вас угораздило взяться за этот проект, если вы даже банально не можете положить рядом нужные скрипты на питоне и работать сразу с базой, а не "excel -> SQL -> загрузка файлов ручками -> поиск файлов в базе". Все решалось выводом отресайзеной картинки в шаблоне. Т.е. для тех кто работает с Битриксом часа 2-3, для вас наверное целая неделя ушла, оплата конечно соответствующая. Не стыдно так клиентов нагибать?)
Потому что Битрикс тоже умеет хранить категорию в отдельной таблице, конечно это делается через цать дополнительных запросов, и у Битрикса это не так быстро
А откуда вы знаете насколько Битрикс медленее? В нем как раз таки и реализован EAV : b_iblock_element (сущности), b_iblock_property (атрибуты), b_iblock_property_element (значения).
Запрос к категориям делается через 1 join, что мало похоже на "цать дополнительных запросов" :-)
У WP или Joomla по вашему API меньше? Ссылку бы хотя бы на API оставили, чтобы понимать масштаб :)
Забавно что вы мерите категорию фреймворк/не фреймворк размером API. Slim и емуподобные конечно грустят в сторонке от такого неравенства.
Что вкладывается в слово "стабильность"? Наличие мажорной цифры в номере версии? Малое число issue, а также отсутствие тестов (по крайней мере в репе) говорит скорее об обратном и том что могут быть скрытые дефекты.
Стабильно плохо - это все равно плохо :)
А у кого нет?
А у кого нет?
Пруфы?
Статья про транзакции, а не про вложенность. Вложенность работает так под капотом:
Статья хорошая, но в целом про работу с сохранением из коллекции в доке есть: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=11749&LESSON_PATH=3913.3516.5748.11743.11749
Плюс в комментариях выше правильно написали про использованную память. Я думаю стоит также добавить в статью сколько памяти сожралось при том или ином варианте.
Ну и еще как вариант можно запросы делать пачками по 1К, 10К, 100К элементов, а не собирать один большой монструозный запрос
Т.е. в сервис локаторе у вас лежит элемент с именем EXAMPLE, который подразумевает обработку команды и это по вашему ок?
Далее в системе появляется обработчик комманд от другого микросервиса, с таким же названием. Что делать в данном случае?
Не лучше завести отдельный диспетчер для задач и сконектить его с ларавельной логикой?
Ну собственно описанные сущности это и есть AR. Определение Мартина: https://martinfowler.com/eaaCatalog/activeRecord.html
В данном случае сущности 1 к 1 отражают таблицу и то как хранятся в базе сущности. Дополнительно к этому они нагружены еще и бизнес-логикой. У вас не получиться в эти объекты добавить логику и данные, которые будут идти в разрез с БД - доктрина подавится.
То что что в данных объектах нет метода save и delete, т.е. они не инкапсулируют в себе работу с базой, это еще не значит что они не AR (возможно не совсем в классическом понимании).
Точно?
Давайте разбираться: у нас есть объект который объединяет в себе логику и структуру БД (в данной статье
App\Entity\Car|Buggy|Auto).Где здесь маппер? :)
А можно ведь было сделать отдельные классы на сущности домена, мапить их при сохранении в таблицу и не насиловать бедные ActiveRecord'ы из доктрины :)
Если верить вики, то вы не весь список управляющих конструкций описали :) https://ru.wikipedia.org/wiki/BPMN
Плюс можно было бы написать какой софт использовать для их построения. Инструмента автоматизации которые работают на базе таких схем.
Короче тема не раскрыта :(
Партиции хранятся в одной БД, шардирование это разнос данных по разным БД. Условие разделение уже задаете какое вам нравится в обоих случаях (в случае с шардированием можете часть таблиц целиком вынести на другой сервер).
"Две пыхи" - РНР это язык. Либо вы имели ввиду что-то другое, либо с подачей информации ооооооооочень большие проблемы.
Ну то есть вы не разобрались как работает метод тестирования, какие есть у него варианты, не стали гуглить или хотя бы читать описание к самим методам, а просто решили написать статью о своей глупости?
Великолепие как оно есть :)
Исходный код и визуальный редактор это два вида языка? Чтооооооо?
Нифига себе, вы изобрели включаемые области которые есть в Битрикс с самого начала: https://dev.1c-bitrix.ru/api_help/main/reference/cmain/includefile.php
Альтернатива: сниппет в IDE и не нужен никакой сомнительный велосипед
Опять же:
1 компонент может иметь несколько шаблонов, и кучу мест использования (все это по вашей теории нужно хранить в базе). С таким же успехом предлагайте в Yii2 виджеты хранить в базе.
Плюс в таком варианте кеширование компонента будет работать все равно с базой, вместо того чтобы просто сразу все выплюнуть из кеша.
Ну и собственно такая простыня параметров нужна для того чтобы компоненты были как можно более универсально (чтобы люди могли спокойной в виз редакторе натыкать нужные параметры и не заглядывать в код или кастомизировать шаблон/компонент).
Это вы еще Битрикс24 не смотрели, где 1.3К таблиц. Правда если спросить "а в чем проблема?" вы вряд ли сможете дать ответ.
Веселят конечно люди, которые засирают Битрикс поработав на нем 1-2 дня/недели, и потом говорят насколько в нем все плохо.
Ах да и пишут на старом коде версии этак 15-ой. С таким же успехом можно говнить Yii2 приводя примеры из Yii1. Если не нравится писать на файлах - пишите контроллеры к роутеру который есть в Битрикс (неожиданно правда, а он оказывается есть);
Судя по вашему описанию "есть карточка с артикулами, а остальное хранится в базе" вы вообще понятия не имеете как устроена архитектура: есть страница (на ней подключается пролог и эпилог), на этой странице указываются компоненты (хоть руками, хоть из виз. редактора), внутри компонента уже есть логика и шаблоны.
Если вы смотрите на задачу с точки зрения верстальщика, то вам нужны только шаблоны - обычные php файлы с версткой, которым компонент скормил данные для отображения (удивительно, но это ой как похоже на View из MVC, но в других фреймворках у вас это вопросы не вызывало, а тут почему-то вызывало).
Да и подключение файлов style.css и script.js к шаблону компонента происходит автоматически, и не обязательно дергать Assets для ручного подключения.
Прежде чем выплескивать кашу из своей головы, я думаю стоит почитать документацию как работать с Битрикс, а не какие-то рандомные статьи из интернета.
Опять же, двойные стандарты: почитать доку к какому то фреймворку - ок, так и нужно делать. А вот для Битрикса - нахер надо, по наитию не пойму - Битрикс говно.
Логика - великолепная :)
Вам наверное неизвестно что такое "обратная совместимость"
Если нормально писать модули и компоненты то никакой проблемы нет (уже лет 5 наверное).
Все что внутри директории модуля
/libавтоматически загружается (даже оказывается согласноPSR-4, но автору об этом знать не обязательно, пусть дальше живет в своих розовых фантазиях о ларавеле :)PSR-4 это стандарт, а пространство имен уже языковая приблуда. В контексте компонентов пространство имен подразумевает директорию с компонентами одно вендора. Вас же почему-то не смущает, что пространство имен JS никакого отношения к PSR не имеет.
Файл "class.php" в сторонке: ну да, ну да, пошел я на хер.
Трудно - это наверное добавить вызов
$APPLICATION->IncludeComponentтам где это нужно без визуального редактора. Мне бы ваши трудности конечно.Когда нихера не умеешь и не знаешь, то вместо Битрикс с успехом можно подставить любую CMS и фреймворк ;-)
Не угодишь никому :)
Время зависит от того какой у вас процесс разработки.
Если по SSH напрямую подключиться и на горячую внести правки, то это будет минут 20.
Если говорить про SVN: создали ветку, локально поправили, проверили, создали MR, отправили на ревью, смержили, отгрузили.
Если говорить про реалии: создали ветку, локально поправили, отвлекся на другую задачу (потерял контекст), вернулся к задаче (восстановил контекст), проверил, отвлекли в чате (потерял контекст), вернулся к задаче (восстановил контекст), создал MR, отправил на ревью, спустя 3 дня по ревью пришли правки, ну и т.д.
Так что 2-3 часа это оптимальный срок на решение задачи, а на написание кода действительно минут 10-20 потребуется :)
Проверка правильной логики ресайза, проверка верстки, чтобы ресайз корректно садился, проверка на разных экранах/устройствах.
Не сказал бы что нечего)
2-3 часа на тестирование отображения отресайзеной картинки, которые выливаются в 2 ветки условий в result_modifier.php с функцией CFile::ResizeImageGet?
И да, я имел ввиду трудозатраты на разработку, но тестинг точно займет не 2-3 часа, даже если это автотесты.
А по итогу всего-то надо было использовать встроенную функцию
CFile::ResizeImageGet:-)SQL запрос сделать товары join файлы, не?
Программисты, без комментариев.
А все таки про SQL вы знаете :)
Ну и самый главный вопрос, а как вообще вас угораздило взяться за этот проект, если вы даже банально не можете положить рядом нужные скрипты на питоне и работать сразу с базой, а не "excel -> SQL -> загрузка файлов ручками -> поиск файлов в базе". Все решалось выводом отресайзеной картинки в шаблоне.
Т.е. для тех кто работает с Битриксом часа 2-3, для вас наверное целая неделя ушла, оплата конечно соответствующая. Не стыдно так клиентов нагибать?)
Посмотрите в сторону того как фасетный индекс у Битрикс устроен, вопросы по поводу нескольких куч отпадут)
А откуда вы знаете насколько Битрикс медленее? В нем как раз таки и реализован EAV : b_iblock_element (сущности), b_iblock_property (атрибуты), b_iblock_property_element (значения).
Запрос к категориям делается через 1 join, что мало похоже на "цать дополнительных запросов" :-)