* Основные отличия
управляемых форм от обычных:
*Возможность разделять выполнение кода в форме на сервере и на клиенте. Для этого служат специальные директивы
компиляции: &НаСервере, &НаКлиенте, &НаСерверБезКонтекста, &НаКлиентеНаСеревереБезКонтекст а, &НаКлиентеНаСервере.
*Нет необходимости в «прорисовке» формы и установлении привязок. Разработчик просто декларирует положение нужного элемента на форме, а система сама, автоматически, разместит его на форме. Как следствие этого, пользователь в режиме приложения может самостоятельно настраивать форму на свой вкус.
*Управление формой происходит посредством команд. Если в обычных формах Вы рисовали кнопку, потом писали обработчик события нажатия на кнопку, то в управляемых формах Вам нужно разместить кнопку, а потом привязать к кнопке или команду формы, или стандартную команду, или какую-нибудь глобальную команду. Подробно о командах мы узнаем во второй части нашего курса.
*Помимо реквизитов, которые есть и у обычных форм, у управляемых форм появились параметры. Параметры необходимы для управления функциональностью формы при её открытии. Т.е. при создании обычной формы, перед её открытием, вы можете присвоить реквизитам формы какие-либо значения, которые впоследствии будете использовать. В случае управляемых форм механизм открытия другой. Подробно мы его изучим в 3 части этого курса, пока отметим лишь то, что при открытии мы не можем передать данные в реквизиты формы напрямую, как было в обычных
Окно настройки управляемой формы в конфигураторе 1С выглядит так:
Режим запуска может быть (разные архитектуры связи между клиентом и сервером):
-толстый клиент -тонкий клиент
1. Толстый клиент - когда |
мы имеем дело с реальным предприятием, где при |
||||||||
|
помощи 1С автоматизированы все отделы, то становится понятно, что нужно все |
||||||||
|
важные и нужные для всех отделов данных выносить на один сервер. Клиентские |
||||||||
|
машины должны работать с сервером по сети. Необходимо выбрать товар из |
||||||||
|
всего ассортимента, справочник с товаром хранится на сервере. Для того, чтобы |
||||||||
|
получить несколько данных, нам приходится запросить все данные и получить на |
||||||||
|
клиентскую машину все данные, а потом с помощью обработки выбираются эти |
||||||||
|
несколько необходимы данных. Тут 1с сервер не должен быть мощным, но нужна |
||||||||
2. |
мощная клиентская машина. |
|
|
|
|
|
|||
Тонкий клиент - клиентская машина существует только для того, чтобы |
|||||||||
|
интерфейс рисовать. В данном случае обработка находится на сервере и нам не |
||||||||
|
нужно получать все данные на клиентскую машину. Нагрузка на сеть |
||||||||
|
уменьшается, уменьшается критерии клиентской машины. Но тут нужен мощный |
||||||||
3. |
сервер. |
|
|
|
|
|
|
|
|
Веб-клиент не требует какой-либо |
предварительной |
установки |
на компьютер. |
||||||
|
В отличие |
от толстого |
и тонкого |
клиентов, |
он исполняется не в среде |
||||
|
операционной |
системы |
компьютера, |
а в среде |
интернет-браузера (Internet |
||||
|
Explorer, Mozilla |
Firefox, Google |
Chrome или Safari). |
Поэтому |
пользователю |
||||
|
достаточно |
всего лишь |
запустить свой браузер, |
ввести адрес веб-сервера, |
|||||
|
на котором опубликована информационная база — и веб-клиент «сам приедет» |
||||||||
4. |
к нему на компьютер и начнет исполняться. |
|
|
|
|||||
Мобильный клиент — это тонкий клиент для мобильных устройств, который |
|||||||||
|
обладает интерфейсом, аналогичным мобильной платформе. |
|
|||||||
Способы сохранения файла:
1.Сохранения файла базы - находим файл базы и куда-то его копируем.
2.Сохранение dt файла - файл базы, заархивированный в отдельный файл. Конфигурация | Сравнить, объединить с конфигурацией из файла.
3.Файл с расширением сfu — это файл обновления конфигурации, который сам по себе конфигурацией быть не может. Мало того, если обновление не подходит к обновляемой конфигурации (не та версия, например), то обновить конфигурацию не удастся.
Конфигурация | Поддержка | Обновить конфигурацию.
4.Сохранения cf файла - в отличии от dt файла, где есть данные которые вводит пользователь, где идет просто сохранение конфигурации. Обновлять рабочую конфигурацию в этом случае мы будем не путем обновления, а путем сравнения и объединения конфигураций.
Классификация объектов и типы данных
Объект – это некоторая математически- программно описанная сущность, элемент окружающего нас мира, с которым мы встречаемся в повседневной жизни.
Реальные объекты имеют две характеристики:
*состояние, определяемое некоторым набором свойств;
*поведение этого объекта.
Командный интерфейс – это основное средство доступа пользователя к функциональности приложения, средство, которое позволяет перемещаться между формами и выполнять те или иные действия. Одной из важных особенностей командного интерфейса является то, что он описывается декларативно. Разработчик не прорисовывает его в деталях, а просто описывает правила его формирования.
Порядка разработки командного интерфейса.
1.Первоначально определяется структура системы с точки зрения прикладной области (определяется структура подсистем).
2.Определяется состав ролей (это можно сделать и позже).
3.При создании объектов конфигурации они относятся к нужным подсистемам, настраиваются права доступа.
4.При необходимости меняется расположение и видимость команд.
Основные элементы окна Конфигуратора:
*дерево конфигурации — древовидная структура всех элементов конфигурации: константы, справочники, документы, отчеты и подчиненные им формы, программные модули и печатные формы;
*меню — сгруппированные по смыслу команды в верхней части окна Конфигуратора;
*панели инструментов — панели с командами-кнопками, расположенные ниже меню, дублирующие наиболее часто используемые команды меню и предназначенные для быстрого доступа к ним;
*рабочий стол программы — собственно говоря, основное рабочее поле. Здесь будут располагаться открытые нами формы и программные модули, здесь мы будем заниматься визуальным конструированием и писать программный код;
*строка состояния — вспомогательная область с текущей информацией, расположенная в нижней части окна Конфигуратора.
