Базовый курс. Решение ДЗ №5
23.04.2011
комментариев 16
Представляем решение пятого домашнего задания.
К сожалению, у Вас недостаточно прав для просмотра этой записи. Если Вы еще не залогинены на сайте
— залогиньтесь.
— залогиньтесь.
Если не активировали токен — посмотрите видео-инструкцию (видео N5)
Если вы залогинены, у Вас активирован токен доступа, но вы все равно видите эту запись —
напишите нам на e-mail поддержки.
Все-таки я считаю, что при разборе решения не стоило использовать Запрос и ФормуВыбора, так как на момент ДЗ мы не проходили этих объектов. Мне кажется, что более верным для обучения было бы решение задачи с использованием тех инструментов, с которыми мы знакомы.
Подобное “забегание вперед” очень часто встречается в курсе, и оно весьма осложняет восприятие материала.
Спасибо, учтем.
Выполнил задание 5 – извиняюсь, что поздно,? нет времени, к сожалению, все вовремя делать. Однако решил с Регистрацией по времени входа/выхода одной функцией с параметром.
Функция ГрафикРаботыВБД(ВремяСеанса,Параметр=1) Экспорт
Результат = Ложь;
Если Параметр = 1 Тогда
РабочееВремя = ОбщиеПроцедурыФункцииСервер.ПолучитьЗначениеРасписания(1);
Если НЕ РабочееВремя = Дата(1,1,1) Тогда
Если РабочееВремя > Дата(1,1,1,Час(ВремяСеанса), Минута(ВремяСеанса), Секунда(ВремяСеанса)) Тогда
ПредставлениеРабочееВремя = Строка(Час(РабочееВремя))+”:”+Строка(Минута(РабочееВремя))+”:”+Строка(Секунда(РабочееВремя));
Предупреждение(“В базе можно работать с “+ПредставлениеРабочееВремя, 10);
Результат = Истина;
КонецЕсли;
КонецЕсли;
Иначе // это выход
РабочееВремя = ОбщиеПроцедурыФункцииСервер.ПолучитьЗначениеРасписания(0);
Если НЕ РабочееВремя = Дата(1,1,1) Тогда
Если РабочееВремя > Дата(1,1,1,Час(ВремяСеанса), Минута(ВремяСеанса), Секунда(ВремяСеанса)) Тогда
ПредставлениеРабочееВремя = Строка(Час(РабочееВремя))+”:”+Строка(Минута(РабочееВремя))+”:”+Строка(Секунда(РабочееВремя));
Ответ = Вопрос(“А может поработем?”, РежимДиалогаВопрос.ДаНет);
Если Ответ = КодВозвратаДиалога.Нет Тогда
Результат = Истина;
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецЕсли;
Возврат Результат;
КонецФункции
Функция ГрафикРаботыВБД(ВремяСеанса,Параметр=1) Экспорт Результат = Ложь; Если Параметр = 1 Тогда РабочееВремя = ОбщиеПроцедурыФункцииСервер.ПолучитьЗначениеРасписания(1); Если НЕ РабочееВремя = Дата(1,1,1) Тогда Если РабочееВремя > Дата(1,1,1,Час(ВремяСеанса), Минута(ВремяСеанса), Секунда(ВремяСеанса)) Тогда ПредставлениеРабочееВремя = Строка(Час(РабочееВремя))+”:”+Строка(Минута(РабочееВремя))+”:”+Строка(Секунда(РабочееВремя)); Предупреждение(“В базе можно работать с “+ПредставлениеРабочееВремя, 10); Результат = Истина; КонецЕсли; КонецЕсли; Иначе // это выход РабочееВремя = ОбщиеПроцедурыФункцииСервер.ПолучитьЗначениеРасписания(0); Если НЕ РабочееВремя = Дата(1,1,1) Тогда Если РабочееВремя > Дата(1,1,1,Час(ВремяСеанса), Минута(ВремяСеанса), Секунда(ВремяСеанса)) Тогда ПредставлениеРабочееВремя = Строка(Час(РабочееВремя))+”:”+Строка(Минута(РабочееВремя))+”:”+Строка(Секунда(РабочееВремя)); Ответ = Вопрос(“А может поработем?”, РежимДиалогаВопрос.ДаНет); Если Ответ = КодВозвратаДиалога.Нет Тогда Результат = Истина; КонецЕсли; КонецЕсли; КонецЕсли; КонецЕсли; Возврат Результат; КонецФункции
Просматривая авторское решение синхронизации, отметил для себя новый аспект работы с уникальным значением, однако если у пользователя нет прав на чтение/запись в Справочник Пользователя – записываться туда, логично предположить, ничего не будет. (по симу понимаю, что это решение только для этой узкой задачи).
Я немного запоздало пишу, но не было времени. Хочу несколько покритиковать решение.
1. Синхронизация пользователей по гуиду в данном случае не очень правильно. Работники приходят на работу и увольняются, соответственно, список пользователей регулярно чистится. Вручную. Достаточно один раз случайно удалить не того пользователя и начнутся проблемы, так как восстановленный пользователь, для системы уже будет совсем не тем же самым. В типовых используется проверка из модуля сеанса с синхронизацией по коду и инициализацией параметра сеанса, что более предпочтительно чем использование глобальных переменных.
2. Писать функции которые одновременно и возвращают значение, и изменяют входной параметр нехорошо – это не повышает читабельность кода. Данная экономия на спичках совсем не оправдана. Можно показать как фичу, но считаю обязательным обратить внимание учеников, что в общем-то за такое не жалуют.
3. Зачем городить запрос для проверки наличия обедов, если можно использовать Возврат Выбрать(, Владелец, ОтборПоДате).Следующий().
Спасибо за обратную связь.
1. Предлагаемый вариант решения возможен.
Однако представленное нами решение можно было бы доработать таким образом:
В справочнике пользователей администраторам предоставлять визуализацию пользователя БД и возможность его выбора вручную.
Тогда, в описанном Вами случае, проблема решается так: сисадмин создает ранее удаленного пользователя, вручную выполняет синхронизацию.
2. Спасибо, проанализируем.
3. Всегда стараюсь использовать запросы, особенно при использовании RLS.
2. Да, это нехорошая практика.
Хочу обратить ваше внимание на то, что практически любая оптимизация ведет к ухудшению читабельности кода.
И именно ваше высказывание об “экономии на спичках” неоправданно. Любой разговор об оптимизации должен базироваться на вполне конкретной ситуации. Заказчику важно, чтобы все работало быстро; разработчику важно, чтобы с кодом было удобно работать. И мы, как программисты, должны найти компромисс между этими зачастую противоположными вещами.
Я считаю, что изначально нужно писать понятный код, а оптимизировать (читай, ухудшать читабельность в угоду производительности) необходимо только по итогам конкретного тестирования на производительность.
И все-таки оптимальный код зачастую читается очень просто, хотя иногда для этого требуется не “новичковая” квалификация.
В целом с Вами согласен, но вот только момент тестирования кода зачастую разработчиками не выполняется. Поясню.
Разработчик сделал требуемую доработку, на следующее утро работа торговой компании была парализована, поскольку конфигурация “медленно проводила документы”.
И еще… Для применения метода СправочникМенеджер.НайтиПоРеквизиту(…) не обязательно требовать от реквизита поиска быть индексированным (как в 7.7)?
Да верно.
Требование индексации реквизита присутствует только в методе Выбрать, когда передаем значение Отбора.
Судя по решению ДЗ-5, если бы новому пользователю НЕ было прав на ИЗМЕНЕНИЕ справочника “Пользователи”, то система бы не позволила ему войти?… Пытаюсь понять, насколько оправдано мне было выносить проверку пользователя в модуль СЕАНСА.
Верно, если у пользователя не будет прав на программное чтение и добавление в справочник “Пользователи” возникнет ошибка во время исполнения кода.
И вход в систему будет невозможен.
Поэтому:
– Либо такие права нужно давать (именно программные, не интерактивные);
– Либо устанавливать привилегированный режим на время синхронизации пользователей.
Использовать модуль сеанса не нужно.
Использовать запрос было нельзя! Мы же его ещё не проходили. :) Я поэтому и использовал выборку… :)
Система помнит сама, потому что на ГУИД ориентируется, я это так понимаю. В справочнике “ОбедыПользователей” какая информация? “Менеджер”. Обед кто выбрал? Виктор Иванович. На мой взгляд – путаница выйдет… Для простого пользователя соответствия же не видно. Или я в чём-то не прав?
Теперь проблема, описанная в первом вопросе, понятна.
Решений может быть несколько:
1. В наименовании элементов справочника “Пользователи” указывать кроме должности ФИО.
2. Справочно в форме элемента справочника “Пользователи” выводить соответствие пользователя ИБ.
Этого можно добиться модифицировав форму элемента “Пользователей”, использовать событие “ПриСозданииНаСервере”, где заполнять значение реквизита формы.
Может я конечно и не прав )))
К вопросу про смену имени пользователя в приведённом примере… У меня конечно нет практики внедрения и может на самом деле такое сплошь и рядом бывает, но возникает вопрос конкретно по нашему заданию: в один ужасный день МарьСтепановна (которая как я понял секретарь и занимается обедами работников) уволится и на её место возьмут новую девочку…. Где новому секретарю потом искать список соответствия имён пользователей в программе и имён в справочнике? Кому именно обед предназначается?
Наверное всё-таки имя пользователя проверять надо и при необходимости менять его в справочнике? Как лучше сделать?
Пока остроты проблемы не замел. Нужен более подробный пример.
Соответствия “Пользователь ИБ – Пользователь (справочник)” система помнит сама.
Зачем секретарю “искать список соответствия имён пользователей в программе и имён в справочнике”?
>Кому именно обед предназначается?
Эта информация есть в справочнике “ОбедыПользователей”.