JetBrains как всегда на высоте! Услышали меня с форматированием структур Twig. Может и следующее пожелание услышат:
Хотелось бы, что бы была настройка Smart-Checkout при переключении между ветками, которая позволяла бы текущие незакомиченные изменения отправлять в Shelf автоматически и возвращать при переключении обратно.
Да, согласен. Стоило указать, что в нашем приложении переопределен класс CDbConnection, а в нем метод beginTransaction
public function beginTransaction()
{
Yii::trace('Starting transaction','system.db.CDbConnection');
$this->setActive(true);
$this->getPdoInstance()->beginTransaction();
return $this->_transaction = new DbTransaction($this);
}
Эхххх, а я надеялся, что по этому поводу уже есть красивое решение. Разрыв связи при серфинге сайта — достаточно серьезный недостаток web-телефона. Ведь оператору CRM постоянно приходится во время звонка проверять состояние заказа клиента, возможно устанавливать скидку, ну собственно много операций производить, которые могут привести к перезагрузке страницы… На фоне этого отображение карточки клиента во время звонка — сомнительный профит для web-телефона. Статистику и записи звонков на примере Астериска можно получить в интерфейсе CRM и другими способами. Сейчас думаем над альтернативными вариантами отображения карточки клиента. Вариант браузерного расширения интересен, но не кроссплатформенен и требует опыта разработки браузерных расширений, которого у нас пока нет в наличии.
Подскажите пожалуйста, как вы решаете проблему ухода со страницы во время звонка? На сколько я понимаю, при активном звонке нельзя обновлять страницу или переходить по ссылкам. Мне видится только вариант создания в основном шаблоне iframe, в котором и будет происходить работа с системой (в вашем случае CRM), а web-телефон всегда должен будет располагаться в родительском окне, которое будет постоянно даже при переходе по ссылкам. Или я чего-то не знаю о технологии WebRTC и в ней уже все предусмотрено?
Если вы в целом против собак, но считаете целесообразным использование их в исключительных случаях, например в процессе записи лога в файл, как это сделано в Yii, то с такой точкой зрения очень сложно спорить. В таком случае странно, что тема вообще оказалась в заявках на devconf.
Я надеюсь автор пользуется xDebug`ом не только для получения значения переменных в заданном breakpoint. А еще пошагово отлаживает код, в том числе с проваливанием в вызываемые функции. А еще умеет вычислять выражения в той или иной точке кода.
Да я знаю, что в PhpStorm есть подсветка синтаксиса Twig, вполне себе приемлемая, но в остальном все не очень удобно. Например автоформатирование json-массивов. Например вот как форматируется следующий код:
А так же хотелось бы хотя бы через описание переменных в комментариях получить автокомплит. Понимаю, что основная проблема описания переменных в комментариях твига связанна с отсутствием стандартов, но даже некоторые внутренние функции не определяются, например void. Еще хотелось бы автокомлит html мнемоник в шаблонах twig, например ввожу &, и программа предлагает nbsp; и т.д.
Другими словами, я действительно говорил о улучшенной поддержке.
В 2014 году:
1. Выйдет стабильный релиз фреймворка Yii 2.
2. Думаю выпустят мажорную версию PHP 5.6, вряд ли будет даже альфа PHP 6.
3. Хочется надеяться на выход PHPStorm 8.0, уже с поддержкой Twig из коробки, а не только Smarty.
4. Думаю благодаря инвестициям Symfony выпустит еще пару мажорных версий.
Таблица с итоговыми данными — не разгрузит сервер, потому что для того чтобы данные туда положить, нужно выполнить тот же агрегатный запрос, и производить эту агрегацию так же часто, как и в нашем случае, ведь на этих данных планируется построить бизнес логику. Сервер разгрузит, сворачивание регистров, что мы и планируем делать в своем приложении.
По поводу поведений, что значит, модель не должна восстанавливаться после отката транзакции, неужели бывают юзкейсы, когда плохо, что модель не отражает актуального состояния???
Я уже говорил, что валидаторы в нашем случае не подходят. Точнее, валидаторы мы конечно используем, но существуют случаи, когда они не могут проверить всю бизнес логику. Не хотел в данном посте описывать регистры, видимо придется. Постараюсь привести показательный пример.
Есть модель ProductMovement (перемещение товаров). Эта модель после сохранения, само собой разумеется производит запись в свою таблицу, а так же после своего сохранения производит сохранение моделей регистра ProductRest (остаток товара на складе). Это можно проиллюстрировать примерно так:
Представим, что мы создаем документ «Перемещение 3». Бизнес требование заключается в том что сумма по колонке кол-во всегда должно быть положительным ( SUM('кол-во') > 0 ), кроме того это требование настолько важно, что коллизий не должно быть при конкурентных сохранениях, поэтому при проверках, эту таблицу будем блокировать. Рассмотрим два решения этой задачи.
1. Ваш вариант — проверка перед сохранением, его можно реализовать валидатором.
а. Считаем кол-во, которое мы планируем вставить.
б. Блокируем таблицу регистров.
в. Считаем остаток в таблице регистров агрегатным запросом.
г. Складываем результат с планируемой суммой.
д. Валидируем итоговую сумму.
е. Снимаем блокировку.
2. Наш вариант — проверка после сохранения, его нельзя реализовать валидатором.
а. Производим запись в таблицу регистров.
б. Блокируем таблицу регистров.
в. Считаем остаток в таблице регистров агрегатным запросом.
г. Валидируем итоговую сумму.
д. Снимаем блокировку.
А теперь представим себе, что в реальности в регистре несколько миллионов записей и десяток полей по которым нужно сгруппировать при агрегатном запросе и при вычислении планируемых и итоговых сумм. А так же самих регистров участвует в сохранении несколько.
Обратите внимание, что в первом варианте, блокировка таблицы вызывается раньше, а сами вычисления сложнее, к тому же они будут вызываться при любой валидации, например ajax-валидации. Все это приведет к усложнению кода, большой нагрузке на сервер и длительным блокировкам таблиц.
В нашем случае исключение может быть вызвано не только ошибкой на уровне БД, но и по случаю передачи неверных данных с точки зрения бизнес-логики. В таком случае нужно восстановить модель и показать вьюшку со старыми данными и описанием ошибки. Вероятно для некоторых, приведенный код не показателен в отрыве от бизнес логики. Постараюсь объяснить на словах. В 1С часто используется подход (особенно в новых редакциях типовых конфигураций), когда все данные сначала пишутся в базу данных, а потом проверяются на корректность, это характерно для проведения по регистрам (что такое регистры и как мы их применили в своем проекте, я создам как-нибудь отдельный пост). Именно такой подход мы решили применить и в своем проекте, так как он очень удобен для учетных систем. Как раз это заставляет нас производить вложенные сохранения и выбрасывать пользовательские исключения после сохранения исходной модели.
Вы видимо не внимательно читали, в данной статье решается совершенно другая проблема — восстановление модели, после отката транзакции. Помимо это, ваш код имеет ряд недостатков:
1. Код не будет работать если инициализирована транзакция на более высоком уровне, например в контроллере.
2. Нельзя использовать вложенное сохранение, например в afterSave() использовать сохранение другой модели. Ваш код вывалит Exception.
Хотелось бы, что бы была настройка Smart-Checkout при переключении между ветками, которая позволяла бы текущие незакомиченные изменения отправлять в Shelf автоматически и возвращать при переключении обратно.
А хотелось бы вот так:
А так же хотелось бы хотя бы через описание переменных в комментариях получить автокомплит. Понимаю, что основная проблема описания переменных в комментариях твига связанна с отсутствием стандартов, но даже некоторые внутренние функции не определяются, например void. Еще хотелось бы автокомлит html мнемоник в шаблонах twig, например ввожу &, и программа предлагает nbsp; и т.д.
Другими словами, я действительно говорил о улучшенной поддержке.
1. Выйдет стабильный релиз фреймворка Yii 2.
2. Думаю выпустят мажорную версию PHP 5.6, вряд ли будет даже альфа PHP 6.
3. Хочется надеяться на выход PHPStorm 8.0, уже с поддержкой Twig из коробки, а не только Smarty.
4. Думаю благодаря инвестициям Symfony выпустит еще пару мажорных версий.
По поводу поведений, что значит, модель не должна восстанавливаться после отката транзакции, неужели бывают юзкейсы, когда плохо, что модель не отражает актуального состояния???
Есть модель ProductMovement (перемещение товаров). Эта модель после сохранения, само собой разумеется производит запись в свою таблицу, а так же после своего сохранения производит сохранение моделей регистра ProductRest (остаток товара на складе). Это можно проиллюстрировать примерно так:
Представим, что мы создаем документ «Перемещение 3». Бизнес требование заключается в том что сумма по колонке кол-во всегда должно быть положительным ( SUM('кол-во') > 0 ), кроме того это требование настолько важно, что коллизий не должно быть при конкурентных сохранениях, поэтому при проверках, эту таблицу будем блокировать. Рассмотрим два решения этой задачи.
1. Ваш вариант — проверка перед сохранением, его можно реализовать валидатором.
2. Наш вариант — проверка после сохранения, его нельзя реализовать валидатором.
А теперь представим себе, что в реальности в регистре несколько миллионов записей и десяток полей по которым нужно сгруппировать при агрегатном запросе и при вычислении планируемых и итоговых сумм. А так же самих регистров участвует в сохранении несколько.
Обратите внимание, что в первом варианте, блокировка таблицы вызывается раньше, а сами вычисления сложнее, к тому же они будут вызываться при любой валидации, например ajax-валидации. Все это приведет к усложнению кода, большой нагрузке на сервер и длительным блокировкам таблиц.
1. Код не будет работать если инициализирована транзакция на более высоком уровне, например в контроллере.
2. Нельзя использовать вложенное сохранение, например в afterSave() использовать сохранение другой модели. Ваш код вывалит Exception.