Как быть если валидация зависит от контекста? Допустим наш Order может создаваться различными путями, и для всех этих путей должна быть разная валидация?
Как быть с историческими данными? Допустим у нас есть Order, которые раньше могли создаваться с неактивными продуктами. Затем у нас появилось новое правило, о том что Order можно создавать только с активными продуктами.
Как быть в случае, когда валидность Entity завязана на большой пласт бизнес логики, которая по сути находится за пределами этой Entity? Например. мы не можем создавать Order если товаров нет в нужном количестве на складе, но при этом, есть некоторые комбинации складов и товаров, которые допускают создания Order с товарами без наличия.
А что будет если использовать маску с напечатанным на ней лицом?
Что если сделать грим на лицо, нарисовать скажем еще один глаз?
Видел в одном сериале, убийца одевал капюшон в который была встроена подсветка. Из за яркого свечения распознать лицо с камеры было невозможно. Возможно ли так защититься?
Кепка с такой же идеей инфракрасной подсветки лица.
В ЕС уже давно ведутся обсуждения на эту тему. Google штрафовали за некачественное продвижение своего сервиса покупок. Недавно в Bloomberg писали, что ЕС планирует законодательно ограничить «отдавать преимущество в поиске своим сервисам». Мне кажется это правильным, потому что речь идет об использование собственной монополии в борьбе с конкурентами.
Оптимизация размера изображений тянет на отдельный продукт. Вы же хотите чтобы оно происходило без потери качества, да еще и так чтобы работало на большинстве хостингов. Нормально так, ставишь битрикс, и открываешь сервис по сжатию изображений аля tinyimg.
И даты активности в форме ввода товара стоит задвинуть ниже, кому надо, тот поставит.
Это как вы уже написали ваше субъективное мнение. Поля и вкладки можно настраивать как угодно, хоть для одного пользователя хоть для всех сразу. Продукт позволяет это делать. Ругать Битрикс за то что он не настроил поля специально под вас это так себе.
Sale Order AJAX
Они много раз говорили про это на партнерских конференциях. Процесс оформления заказа сложен (оплаты, доставки, профили, типы плательщиков, скидки, купоны и т.п.) Был выбран подход, когда они хотели сделать компонент максимально настраиваемым. Чтобы без изменения кода можно было его настроить. Они сами рекомендовали не изменять код компонента а всегда использовать стандартный шаблон.
Разработчики стали жаловаться. На каждой партнерской конференции по 100 раз задают этот вопрос. Они на партнерских конференциях уже озвучили что его переделывают, на сколько я помню будет на vueJs. Дату релиза никто не знает.
Почему я должен закупать аж 2 сторонних модуля синхронизации свойств и статусов заказов?
Они не будут ломать бизнес партнерам. Тоже неоднократно говорили об этом. По вашей логике они должны скупать лучшие решения из маркета и внедрять их в продукт. Партнеры сделали удобную интеграцию быстрее чем сами Битрикс, пользуйтесь модулями партнеров.
пару комментариев написал в стиле «да всё у нас есть и работает»
Это правильно. Хейтеров, которые не знают всех внутренностей продукта, компании, стратегии, планов очень много. Каждый считает себя экспертом, и думает что он больше знает и понимает, чем сотрудники Битрикса. Если каждому отвечать, то времени на работу не останется. Вы где то видели чтобы разработчики фреймверков вступали в срач с хейтерами? Зачем им это? Никого не заставляют пользоваться продуктом.
Где ваша техподдержка?
Вы же не знаете сколько у них обращений в день? Сколько человек в ней работает? На сколько обращений они отвечают? Есть же приоритеты, кто то платит за поддержку, кто то золотой партнер, а кто то Вася Пупкин с форума, они же не могут отвечать всем одинаково быстро и качественно.
Обращения по разработке и багам передаются в тех отделы, но у них тоже есть планы, сроки, приоритеты и т.п.
Я вот слежу за этими темами, и пока что все аргументы на самом деле так себе. Очень много субъективных мнений. Темы за которые можно действительно поругать Битрикс проскакивают мельком в комментариях но не в текстах статей.
Вы можете предложить способ работы со вложенными коллекциями проще? На сколько я помню ORM позволяет строить запросы с JOIN. На мой взгляд работа с коллекциями куда лучше чем работа с массивами. Я правильно вас понял, Битрикс плохой потому что в print_r печатает вам 1.6 мб логов?
Дайте пример про ->getName(), ->getId() и про ->getField("...").
Я бы посмотрел на эту миграцию. Битрикс это продукт который живет уже очень много времени. Это все ровно что выкинуть код Photoshop и переписать его с нуля. Даже типовые решения займут кучу времени. У них же есть еще и Битрикс24, и отраслевые решения и т.п. Кода очень много.
или vue (которое просто содержится в библиотеке BX без каких либо явных причин и надстроек )
Причина в конфликте версий. Битрикс может использовать в своих компонентах Vue одной версии, а вы можете захотеть использовать Vue другой версии. И разные версии Vue могут между собой конфликтовать.
Это же равносильно смерти. Выбросить рабочий продукт, и начать писать новый. В чем бизнес плюсы? Придется поддерживать и старую и новую версию на Yii.
Для них очень важна совместимость версий. Активная лицензия позволяет получать все последние обновления. Вы можете поставить Битрикс 9 версии, и обновится до последней и при этом все должно остаться рабочим.
Как быть с историческими данными? Допустим у нас есть Order, которые раньше могли создаваться с неактивными продуктами. Затем у нас появилось новое правило, о том что Order можно создавать только с активными продуктами.
Как быть в случае, когда валидность Entity завязана на большой пласт бизнес логики, которая по сути находится за пределами этой Entity? Например. мы не можем создавать Order если товаров нет в нужном количестве на складе, но при этом, есть некоторые комбинации складов и товаров, которые допускают создания Order с товарами без наличия.
Что если сделать грим на лицо, нарисовать скажем еще один глаз?
Видел в одном сериале, убийца одевал капюшон в который была встроена подсветка. Из за яркого свечения распознать лицо с камеры было невозможно. Возможно ли так защититься?
Это как вы уже написали ваше субъективное мнение. Поля и вкладки можно настраивать как угодно, хоть для одного пользователя хоть для всех сразу. Продукт позволяет это делать. Ругать Битрикс за то что он не настроил поля специально под вас это так себе.
Они много раз говорили про это на партнерских конференциях. Процесс оформления заказа сложен (оплаты, доставки, профили, типы плательщиков, скидки, купоны и т.п.) Был выбран подход, когда они хотели сделать компонент максимально настраиваемым. Чтобы без изменения кода можно было его настроить. Они сами рекомендовали не изменять код компонента а всегда использовать стандартный шаблон.
Разработчики стали жаловаться. На каждой партнерской конференции по 100 раз задают этот вопрос. Они на партнерских конференциях уже озвучили что его переделывают, на сколько я помню будет на vueJs. Дату релиза никто не знает.
Они не будут ломать бизнес партнерам. Тоже неоднократно говорили об этом. По вашей логике они должны скупать лучшие решения из маркета и внедрять их в продукт. Партнеры сделали удобную интеграцию быстрее чем сами Битрикс, пользуйтесь модулями партнеров.
Это правильно. Хейтеров, которые не знают всех внутренностей продукта, компании, стратегии, планов очень много. Каждый считает себя экспертом, и думает что он больше знает и понимает, чем сотрудники Битрикса. Если каждому отвечать, то времени на работу не останется. Вы где то видели чтобы разработчики фреймверков вступали в срач с хейтерами? Зачем им это? Никого не заставляют пользоваться продуктом.
Вы же не знаете сколько у них обращений в день? Сколько человек в ней работает? На сколько обращений они отвечают? Есть же приоритеты, кто то платит за поддержку, кто то золотой партнер, а кто то Вася Пупкин с форума, они же не могут отвечать всем одинаково быстро и качественно.
Обращения по разработке и багам передаются в тех отделы, но у них тоже есть планы, сроки, приоритеты и т.п.
Я вот слежу за этими темами, и пока что все аргументы на самом деле так себе. Очень много субъективных мнений. Темы за которые можно действительно поругать Битрикс проскакивают мельком в комментариях но не в текстах статей.
Дайте пример про ->getName(), ->getId() и про ->getField("...").
Причина в конфликте версий. Битрикс может использовать в своих компонентах Vue одной версии, а вы можете захотеть использовать Vue другой версии. И разные версии Vue могут между собой конфликтовать.
Для них очень важна совместимость версий. Активная лицензия позволяет получать все последние обновления. Вы можете поставить Битрикс 9 версии, и обновится до последней и при этом все должно остаться рабочим.