그리고 1C 8.2 환경에서 코드 구조화, 관리 형식으로 데이터 전송 객체.

소개

"관리 양식"의 개념과 1C 플랫폼의 관련 개념에 대한 간단한 설명부터 시작하겠습니다. 플랫폼 전문가는 이 섹션을 건너뛸 수 있습니다.

2008년부터 사용 가능 새 버전플랫폼 1C: Enterprise 8.2(이하 Managed Application이라고 함)는 인터페이스로 작업의 전체 계층을 완전히 변경합니다. 여기에는 명령 인터페이스, 양식 및 창 시스템이 포함됩니다. 이는 구성에서 사용자 인터페이스 개발 모델을 변경할 뿐만 아니라 클라이언트 애플리케이션과 서버 간의 기능 분리를 위한 새로운 아키텍처를 제안합니다.
관리되는 애플리케이션은 다음 유형의 클라이언트를 지원합니다.

씩 클라이언트(일반 및 관리 시작 모드)
씬 클라이언트
웹 클라이언트

관리되는 응용 프로그램은 다음에 구축된 양식을 사용합니다. 새로운 기술. 그들은 호출 관리되는 양식. 쉽게 전환할 수 있도록 이전 양식(소위 일반 양식)도 지원되지만 해당 기능은 개발되지 않았으며 리치 클라이언트 실행 모드에서만 사용할 수 있습니다.
개발자를 위한 관리 양식의 주요 차이점:

구조에 대한 "픽셀 단위" 설명이 아니라 선언적입니다. 요소의 특정 배치는 양식이 표시될 때 시스템에서 자동으로 수행됩니다.
양식의 모든 기능은 양식에 설명되어 있습니다. 세부그리고 명령. 세부 정보는 양식이 작동하는 데이터이고 명령은 수행되는 작업입니다.
양식은 서버와 클라이언트 모두에서 실행됩니다.
클라이언트의 맥락에서 거의 모든 애플리케이션 유형을 사용할 수 없으므로 정보베이스의 데이터를 변경할 수 없습니다.
각 방법 또는 양식 변수에 대해 지정해야 합니다. 컴파일 지시어실행 위치(클라이언트 또는 서버) 및 양식의 컨텍스트에 대한 액세스 여부를 지정하는 A.

폼 메서드를 컴파일하기 위한 지시문은 다음과 같습니다.

&At클라이언트
서버에서(&O)
&OnServerWithoutContext
클라이언트에서서버에서(&A)WithoutContext

위의 내용을 예시해 보겠습니다. 스크린샷은 개발 모드에서 관리되는 양식 및 해당 모듈의 예를 보여줍니다. 선언적 설명, 소품, 컴파일 지시문 등을 찾습니다.

모든 추가 논의는 그림의 오른쪽, 모듈 코드를 구성하는 방법 및 효과적인 클라이언트-서버 상호 작용을 구현할 수 있는 원칙에 대한 것입니다.

문제를 정의하자

1C 플랫폼의 새 버전이 활발히 사용되고 1C와 수많은 파트너가 많은 솔루션(구성)을 출시한 지 몇 년이 지났습니다.
이 기간 동안 개발자가 양식을 만들 때 클라이언트-서버 상호 작용의 원칙에 대한 공통된 이해를 발전시켰으며 구현 방식이 변경되었습니까? 소프트웨어 모듈새로운 건축 현실에서?

동일한 일반적인 구성의 여러 형태의 코드 구조(폼 모듈)를 고려하고 패턴을 찾으십시오.
구조에서 우리는 이러한 메서드를 컴파일하기 위한 메서드 및 지시문을 그룹화하기 위해 개발자가 할당한 코드 섹션(대부분 주석 블록)을 의미합니다.
예 1:
이벤트 처리기 섹션 방법 - 클라이언트에서 방법 - 서버에서 방법 - 클라이언트에서 서비스 프로시저 및 기능 섹션 입력 제어 보조 기능
예 2:
서비스 절차 및 기능 결제 문서 귀중품 이벤트 핸들러
예 3:
서버의 서비스 절차 클라이언트의 서비스 절차 컨텍스트가 없는 서버의 서비스 절차 헤더 이벤트 핸들러 명령 이벤트 핸들러
예 4:
범용 절차 양식 이벤트 핸들러 "연락처 정보" 하위 시스템의 절차
실제로 코드 구조가 누락되었거나 가볍게 말하면 양식 8.1에 있었던 것과 유사합니다.

정보가 아닌 단어 "일반, 서비스, 보조."
Timid는 클라이언트와 서버 방법을 분리하려고 시도합니다.
종종 메소드는 인터페이스 요소 "테이블 부분 제품 작업, 연락처 정보"로 그룹화됩니다.
메서드 및 코드 그룹의 임의 배열. 예를 들어 이벤트 핸들러는 한 형식에서는 맨 위에 있고 다른 형식에서는 맨 아래에 있고 세 번째 형식에서는 전혀 강조 표시되지 않을 수 있습니다.
그리고 이것이 모두 동일한 구성 내에 있다는 것을 잊지 마십시오.
예, "일반, 서비스, 보조"라는 단어가 항상 같은 위치에 있는 구성이 있지만 ...

왜 코드 구조가 필요한가요?

유지 보수의 단순화.
학습을 단순화하십시오.
일반/중요/성공 원칙 수정.
...당신의 선택

1C의 기존 개발 표준이 도움이 되지 않는 이유는 무엇입니까?

관리되는 양식을 작성할 때 권장되는 ITS 디스크 및 다양한 "개발자 가이드 ..."에 게시된 원칙을 살펴보겠습니다.

서버 호출 수를 최소화하십시오.
서버의 최대 컴퓨팅.
비컨텍스트 서버 호출은 컨텍스트 호출보다 빠릅니다.
클라이언트-서버 상호 작용을 염두에 두고 프로그램하십시오.
등.

이것들은 절대적으로 사실인 슬로건이지만 어떻게 실현될 수 있습니까? 호출 수를 최소화하는 방법, 클라이언트-서버 모드에서 프로그래밍한다는 것은 무엇을 의미합니까?

디자인 패턴 또는 세대별 지혜

클라이언트-서버 상호 작용은 수십 년 동안 다양한 소프트웨어 기술에서 사용되었습니다. 이전 섹션에서 설명한 질문에 대한 답은 오랫동안 알려져 왔으며 두 가지 기본 원칙으로 요약됩니다.

원격 외관(이하 원격 액세스 인터페이스)
데이터 전송 개체(이하 데이터 전송 개체라고 함)

마틴 파울러(Martin Fowler)에게 이러한 원칙에 대한 설명을 전합니다.

… 잠재적으로 원격 액세스를 위한 각 객체는 다음을 가지고 있어야 합니다. 낮은 세분성 인터페이스, 특정 절차를 수행하는 데 필요한 호출 수를 최소화합니다. … 인보이스와 그 모든 포인트를 따로 요청하는 대신, 한 번의 호출로 인보이스의 모든 포인트를 읽고 업데이트해야 합니다. 이것은 객체의 전체 구조에 영향을 미칩니다...기억하십시오: 원격 액세스 인터페이스 도메인 논리를 포함하지 않음.
... 내가 돌보는 어머니라면 분명히 자녀에게 "데이터 전송 개체를 작성하지 마십시오!"라고 말할 것입니다. 대부분의 경우 데이터 마이그레이션 개체는 부풀어 오른 들판… 이 역겨운 괴물의 가치는 오로지 가능성에 있다 한 번의 호출로 네트워크를 통해 여러 정보 항목 전송- 분산 시스템에 매우 중요한 기술입니다.

1C 플랫폼의 템플릿 예

관리되는 양식을 개발할 때 개발자가 사용할 수 있는 API에는 이러한 원칙에 대한 많은 예가 포함되어 있습니다.
예를 들어, 일반적인 "거친" 인터페이스인 OpenForm() 메서드가 있습니다.
OpenParameters = 새 구조("매개변수1, 매개변수2, 매개변수3", 값1, 값2, 값3); Form = OpenForm(FormName, OpenParameters);
v8.1 스타일과 비교하십시오.
Form = GetForm(양식명); Form.Parameter1 = 값1; Form.Parameter2 = 값2; Form.Open();

관리되는 양식의 컨텍스트에서 "데이터 전송 개체" 집합입니다. 구분 가능 전신의그리고 개발자 정의.
시스템은 하나 이상의 양식 데이터 요소 형식으로 클라이언트의 응용 프로그램 개체를 모델링합니다. 양식 세부 사항에 대한 바인딩 외에는 만들 수 없습니다.

DataForms구조
DataFormsCollection
DataFormStructureCollection
DataForms트리

데이터 전송 시스템 객체를 애플리케이션 유형으로 또는 그 반대로 변환하는 작업은 다음 방법으로 수행됩니다.

값VDataForm()
FormDataToValue()
CopyFormData()
ValueVFormProps()
FormAttributeToValue()

기존 솔루션을 조정할 때 종종 명시적 변환이 사용됩니다. 메서드는 FormDataCollection이 아닌 ValueTable과 같은 (기능) 입력 매개 변수를 예상하거나 메서드가 응용 프로그램 개체의 컨텍스트에서 정의되어 양식에서 직접 호출할 수 없게 되었습니다.
예 1C v8.1:
// FillUsersCache(DepartmentReference) 형식의 컨텍스트에서 클라이언트에서
예 1C v8.2:
// 서버에서 ProcessingObject = FormAttributeToValue("Object") 형식의 컨텍스트에서; ProcessingObject.FillCacheUsers(DepartmentReference); ValueVFormAttribute(ProcessingObject, "객체");

개발자가 구조를 정의하는 데이터 마이그레이션 개체는 클라이언트와 서버 모두에서 사용할 수 있는 유형의 작은 하위 집합입니다. 대부분의 경우 "거친" 인터페이스 메서드의 매개 변수 및 결과로 다음이 사용됩니다.

기본 유형(문자열, 숫자, 부울)
구조
적합성
정렬
응용 프로그램 개체에 대한 링크(고유 식별자 및 텍스트 표현)

예: 메서드는 상태를 변경하기 위해 주문 목록을 수락하고 오류에 대한 설명을 클라이언트에 반환합니다.
&OnServerWithoutContext 함수 ServerChangeOrderStatus(Orders, NewStatus) 오류 = New Match(); // [주문][오류 설명] 주문 루프의 각 주문에 대해 StartTransaction(); 시도 DocOb = Order.GetObject(); …. 주문뿐만 아니라 다른 작업... Exception CancelTransaction(); Errors.Insert(주문, 설명 오류()); 시도의 끝; 사이클 종료; 반환 오류; EndFunction // ServerChangeOrderStatus()

코드 구조화

관리형 양식 모듈이 솔루션에 반영하고 접근해야 하는 주요 목표입니다.

클라이언트와 서버 코드의 명확한 분리.실행 시점에 이들은 두 개의 상호 작용하는 프로세스이며 각 프로세스에서 사용 가능한 기능이 크게 다릅니다.
원격 액세스 인터페이스의 명확한 선택, 클라이언트에서 호출할 수 있는 서버 메서드와 호출할 수 없는 메서드는 무엇입니까? 원격 인터페이스 메서드의 이름은 접두사 "Server"로 시작합니다. 이를 통해 코드를 읽을 때 제어권이 서버로 전환되는 것을 즉시 확인할 수 있으며 상황별 힌트 사용이 간소화됩니다. 공식 권장 사항(ITS)에서는 ChangeOrderStatusOnServer()와 같이 접미사가 있는 이름 지정 방법을 제안합니다. 그러나 다시 말하지만 클라이언트에서 모든 서버 메서드를 호출할 수 있는 것은 아니므로 컴파일 위치보다 논리적 액세스 가능성이 더 중요합니다. 따라서 "Server" 접두사를 사용하여 클라이언트에서 사용할 수 있는 메서드만 표시하고 예제 메서드는 ServerChangeOrderStatus()라고 합니다.
가독성.취향에 따라 모듈이 서버에서 양식을 만드는 절차와 원격 액세스 방법으로 시작할 때 순서를 수락합니다.
유지 보수성.새 코드를 추가할 위치를 명확하게 정의해야 합니다. 중요 포인트메소드 스텁 구성자에 의해 자동으로 생성되는 은 모듈의 끝에 추가됩니다. 폼 엘리먼트 이벤트 핸들러는 대부분 자동으로 생성되기 때문에 각 핸들러를 모듈의 다른 위치로 끌지 않도록 해당 블록을 마지막에 배치합니다.

아래는 나열된 목표를 구현하는 모듈의 기본 구조입니다.

그래픽 옵션 - 주요 실행 흐름을 명확하게 보여줍니다.
텍스트 버전은 다음을 위한 템플릿 디자인의 예입니다. 빠른 삽입구조를 새로운 양식 모듈로 변환합니다.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="" 날짜=""/> // <Описание> // // ////////////////////////////////////////////////// / /////////////////////////// // 모듈 변수 /////////////// / //////////////////////////////////////////////// // ////////////// // 서버에서 //******* 서버에서 이벤트 ******* &On The Server 프로시저 On CreationOn The Server( 실패, StandardProcessing) //처리기 EndProcedure의 내용 삽입 //******** 원격 액세스 인터페이스 ******* //******* BUSINESS LOGIC ON THE SERVER **** *** ///////// ////////////////////////////////////// ///////////// /////////////////// // 일반적인 클라이언트 및 서버 방법 ///////// /////////////// /////////////////////////////////// //////////////// //////// // 클라이언트에서 //******** 클라이언트에서 비즈니스 로직 ******* //******** 명령 ***** //********* 클라이언트의 이벤트 ****** /////////////// ////////////////// //////////////////////////////// ///////////////// / / 메인 프로그램 연산자

관리 양식 정보 1C(시작)

씬 클라이언트

더 얇은 곳이 없습니다. 이제 클라이언트 응용 프로그램은 데이터베이스를 쿼리하지 않습니다(이는 서버의 업무입니다). 클라이언트 애플리케이션은 단순히 인터페이스와 데이터를 표시합니다.

이러한 변환으로 인해 코드 구조가 더욱 복잡해졌다는 점은 주목할 가치가 있습니다. 클라이언트에는 참조, 개체, 값 테이블이 없습니다... 기본 유형만 사용할 수 있습니다(문자열, 날짜, 부울, 배열, 구조...). 이는 프로그래머가 이제 서버에 무엇을 가져올지, 그리고 최소 비용으로 이를 수행하는 방법에 대해 생각해야 함을 의미합니다.

클라이언트-서버 상호 작용

클라이언트와 서버 간의 상호 작용에 대한 새로운 접근 방식을 통해 새로운 사용자 인터페이스 모델을 만들 수 있었습니다. 이제 인터페이스가 선언되었습니다(!). 인터페이스 디자인은 데이터, 세부 정보 및 테이블 섹션으로 시작됩니다. 소품을 만들 때 인터페이스에서 어떻게 보일지, 필요한지 여부, 다른 소품과 어떻게 관련되는지를 생각해야 합니다...

서버에 컨텍스트(상태) 없음

1C 서버는 "무국적"(영어 무국적) 원칙에 따라 작동합니다. 즉, 서버는 요청에만 응답하고 동시에 두 요청 사이에 아무 것도 저장하지 않습니다(이 목적을 위한 임시 저장소가 있음).

FormDataToValue,FormDataCollection,FormData...

우리는 서버로 향했고 그는 우리를 위해 모든 것을 했고 데이터를 삭제하고 우리가 온 것을 잊었습니다. "FormData" + "something there"라는 이름의 모든 개체는 두 서버 호출 간에 데이터를 저장하는 데 도움이 됩니다.

임시 저장

임시 저장소는 양식 세부 정보 외에도 서버에 상태를 저장할 수 있는 특별한 장소입니다. 저장소는 클라이언트에서 사용할 수 없는 데이터(즉, 양식 세부 정보에 배치할 수 없는 데이터)를 저장할 수 있습니다.

임시 저장소로 작업하려면 MoveToTempStorage() 메서드 구문: PlaceToTempStorage(<Данные>, <Адрес>) 설명: 직렬화 가능한 값을 임시 저장소에 저장합니다. 가용성: 씬 클라이언트, 웹 클라이언트, 서버, 씩 클라이언트, 외부 연결, 모바일 애플리케이션(클라이언트), 모바일 애플리케이션(서버). 메서드 호출은 서버를 호출합니다.<Адрес>(선택 사항) 유형: UniqueIdentifier; 선. 데이터가 배치되고 새 주소가 반환될 임시 저장소가 있는 양식의 고유 ID입니다. 또는 데이터를 배치해야 하는 임시 저장소의 주소입니다. 주소는 이 방법을 사용하여 미리 얻어야 합니다. 양식 UniqueIdentifier 또는 저장소의 주소가 전달되면 양식이 닫힌 후 값이 자동으로 삭제됩니다. 양식의 고유 식별자가 아닌 UniqueIdentifier가 전달되면 사용자 세션이 종료될 때 값이 삭제됩니다. 매개변수를 지정하지 않으면 배치된 값은 공유 모듈의 다음 서버 요청 후, 양식의 컨텍스트 및 비컨텍스트 서버 호출, 명령 모듈의 서버 호출 또는 양식 가져오기에서 삭제됩니다. 참고: 한 세션에서 생성된 임시 저장소는 다른 세션에서 액세스할 수 없습니다. 예외는 백그라운드 작업에서 임시 저장소를 사용하여 백그라운드 작업을 시작한 세션으로 데이터를 전송하는 기능입니다. 이러한 전송의 경우 상위 세션에서 임시 저장소에 빈 값을 배치하고 양식 식별자를 전달합니다. 그런 다음 받은 주소를 백그라운드 작업의 매개변수를 통해 백그라운드 작업에 전달합니다. 또한, 이 주소가 매개변수에서 사용되는 경우<Адрес>, 결과는 백그라운드 작업이 시작된 세션에 복사됩니다. 백그라운드 작업의 임시 저장소에 있는 데이터는 백그라운드 작업이 완료될 때까지 상위 세션에서 사용할 수 없습니다. 및 GetFromTempStorage() 구문: GetFromTempStorage(<Адрес>) 설명: 임시 저장소에서 값을 가져옵니다. 가용성: 씬 클라이언트, 웹 클라이언트, 서버, 씩 클라이언트, 외부 연결, 모바일 애플리케이션(클라이언트), 모바일 애플리케이션(서버). 메서드 호출은 서버를 호출합니다. 참고: 실행 결과는 캐시되지 않으며 메서드가 호출될 때마다 서버가 호출됩니다.

서버 코드 호출

서버 코드에 대한 모든 호출은 항상 전송된 데이터를 직렬화합니다. 모든 매개변수는 문자열 형식으로 압축되어 네트워크를 통해 전송됩니다. 작업 결과물 역시 직렬화된 형태로 다시 전송되어 친숙한 오브제로 복원된다.

모듈 플래그 할당

플래그는 모듈 코드가 컴파일될 위치를 나타냅니다(서버, 클라이언트, 외부 연결).
모듈이 여러 곳에서 컴파일되면 플래그에 따라서만 표시됩니다.
코드 실행의 양도는 현재 실행 컨텍스트에 호출된 모듈이 없고 다른 곳에 존재하는 경우에만 가능합니다(모듈이 서버에만 있고 클라이언트에는 없으면 서버가 호출됨)

서버 호출 플래그

1C:Enterprise 8.2 플랫폼부터 "서버 호출" 플래그가 추가되었습니다. 다른 기계로의 전환 조건을 "해결"하는 데 도움이 됩니다. 이 플래그가 모듈에 할당되면 클라이언트에서 모듈을 볼 수 있고, 그렇지 않으면 클라이언트에서 호출을 시도하면 오류가 발생합니다. 모듈 코드는 전혀 존재하지 않는 것처럼 보이지 않습니다.

따라서 일반 씩 클라이언트에서는 클라이언트에서 공통 모듈을 호출하는 경우에만 코드를 서버로 전송할 수 있습니다.

서버 체크박스 선택
"서버 호출" 확인란이 선택되었습니다.
모든 "클라이언트" 확인란 제거

1C Enterprise 8.2 플랫폼의 출현으로 사용자 인터페이스 개발 메커니즘이 크게 변경되었습니다. 이제 관리되는 양식과 응용 프로그램을 만들 수 있습니다(그림 1).

그림 1

또한 클라이언트 애플리케이션과 서버 간의 기능 분리를 위한 새로운 시스템을 제안합니다.
관리되는 애플리케이션은 다음 유형의 클라이언트를 지원합니다.

씩 클라이언트(일반 및 관리 실행 모드),
씬 클라이언트,
웹 클라이언트.

관리되는 양식을 만드는 메커니즘은 기존 양식과 크게 다릅니다. 우선, 관리되는 양식은 특별한 설정에 따라 시스템에서 자동으로 생성된다는 점에서 다릅니다. 이제 프로그래머는 각 양식을 자세히 그릴 필요가 없습니다. 양식의 모든 기능은 세부 정보 및 명령 형식으로 설명됩니다. 세부 정보는 양식이 작동하는 데이터이고 명령은 수행되는 작업입니다. 각 메서드 또는 양식 변수에 대해 실행 위치(클라이언트 또는 서버)를 결정하는 컴파일 지시문을 지정해야 합니다. 컴파일 지시문은 다음과 같습니다.

&At클라이언트,
서버에서(&O),
&OnServerWithoutContext,
클라이언트에서(&A) 서버에서(&A)WithoutContext.

또한 관리되는 양식은 작동하는 데이터 유형이 일반 양식과 다릅니다. 일반 양식이 1C:Enterprise에서 제공하는 대부분의 유형(DirectoryObject, DocumentObject 등 유형 포함)에서 작동하는 경우 관리되는 양식에서 유형의 다음 범주를 구분할 수 있습니다.

양식에서 직접 사용되는 유형은 씬 및 웹 클라이언트 측에 존재하는 유형입니다(예: Number, ReferenceReference.Products, GraphicScheme, SpreadsheetDocument).
특수 데이터 유형으로 변환될 유형은 관리되는 양식 데이터 유형입니다. 이러한 유형은 예를 들어 (CatalogObject.Products)와 같이 괄호 안에 있는 양식 속성 목록에 표시됩니다.
동적 목록.

관리되는 양식의 기능에는 다음과 같은 특징이 있습니다(그림 2).

양식은 클라이언트와 서버 모두에 존재합니다.

클라이언트-서버 상호 작용(데이터 전송 및 요소의 디자인 속성)을 수행합니다.

양식이 응용 프로그램 개체와 작동하지 않음

그림 2

양식은 특별한 일반 개체를 사용합니다.
데이터 양식(그림 3).

그림 3

응용 프로그램 개체는 서버에서만 특정 작업 중에만 작동합니다.
양식을 열 때:

데이터베이스에서 개체를 읽습니다.
개체는 형식 데이터로 변환되며,
개체가 제거됩니다(메모리에서).
양식 데이터가 클라이언트에 전달됩니다.

녹음할 때:

양식 데이터는 클라이언트로부터 수신되며,
양식 데이터는 객체로 변환되며,
개체가 데이터베이스에 기록됩니다.
개체가 제거됩니다(메모리에서).

지난 수업에서는 일반(뚱뚱한) 클라이언트에 대해 고려했습니다. 플랫폼 버전 1C 8.2에서. 그들은 새로운 화면 양식 1C 8.2를 사용합니다. 관리 양식 1C 8.2라고합니다.

관리 양식 1C 8.2는 1C의 미래입니다. 특수 설정을 기반으로 시스템에서 자동으로 생성된다는 점에서 일반 1C 8.2 형식과 다릅니다("일반" 형식은 단순히 프로그래머가 마음대로 그립니다).

관리 양식 1C 8.2의 개발과 일반적인 양식의 차이점은 중요합니다. 따라서 관리 양식 1C 8.2의 생성 및 수정에 대해 별도로 논의하기 위해 오늘 모였습니다.

관리 양식 1C 8.2

이전에 1C 구성을 개발한 적이 있는 경우 1C 8.2 관리 양식 편집기를 열면 마우스로 1C 8.2 양식에 전혀 영향을 미칠 수 없다는 사실에 즉시 혼란스러워할 것입니다.

1C 8.2 양식을 변경할 수 없으며 요소를 이동할 수 없으며 이전과 같이 1C 8.2 양식에서 필드를 두 번 클릭하여 필드 속성을 볼 수도 없습니다.

이제 1C 8.2 양식 개발의 기초는 필드를 양식의 좌표에 바인딩하는 것이 아니라 특수 설정입니다. 시스템은 이러한 설정을 기반으로 관리 양식 1C 8.2를 자동으로 생성합니다.

설정은 왼쪽 상단 모서리의 편집기에 있는 1C 8.2 양식 요소 목록으로 구성됩니다. 양식 1C 8.2의 요소는 다음과 같습니다.

요건
명령(새로운 개념 1C 8.2, 버튼이나 메뉴 항목처럼 보일 수 있음)
그룹(세부 사항과 명령을 결합하기 위해).

따라서 이러한 요소의 설정은 필드의 속성이 아니라 이러한 설정 요소의 속성(오른쪽 클릭 메뉴, 속성 항목)에 있습니다.

관리 양식 1C 8.2 작동 방식

관리 양식 1C 8.2 작업은 사용자마다 다릅니다. 그들은 더 많은 기능을 가지고 있지만 오랫동안 1C로 작업해온 사람들에게는 이례적입니다.

우선, 1C 8.2 형식의 일반적인 요소 위치가 다릅니다. 명령 모음은 항상 맨 위에 있습니다.

명령 모음의 왼쪽은 사용자 지정할 수 있습니다. 일반적으로 Record 및 Post와 같은 일반적인 버튼이 포함되어 있습니다.

명령 패널의 오른쪽은 1C 형식의 모든 작업의 새로운 표준 메뉴입니다. 이 메뉴를 사용하면 ACS 보고서의 설정을 통해 보고서의 모양을 크게 변경할 수 있는 것과 유사하게 원하는 대로 1C 8.2 형식을 관리할 수 있습니다.

임의 메뉴 항목 1C 모든 작업

이 양식 1C 8.1이 하나 또는 다른 것에 속하는지에 따라 메뉴는 이 개체를 관리할 수 있는 항목으로 채워집니다. 예를 들어 디렉토리 목록 형식이라면 Create 또는 Edit와 같은 명령이 있을 것입니다.

항목 사용자 정의 메뉴 목록 1C 모든 작업

1C 8.2 형식에 목록이 있으면 메뉴에 목록 설정 및 목록 표시 명령이 있습니다.
Output List 명령이 이미 친숙한 경우 Excel에서 1C의 목록을 저장/인쇄할 수 있으며 두 번째 명령은 새 명령입니다.

이미 알고 있듯이 목록 명령 모음에는 더 이상 선택 단추가 없습니다. 대신에 작동하는 찾기 버튼이 나타납니다 (입력 할 때 목록에서 현재 비활성화 된 커서 위치 지정)-불만 사항이 있습니다.

물론 찾기 버튼의 기능은 선택 항목과 비교할 수 없지만 아무데도 사라지지 않았습니다!
이제 사용자 정의 목록 메뉴 항목 아래에 있습니다. 이제 모든 필드에서 선택을 수행할 수 있으며 그 외에도 SKD 보고서에서 수행할 수 있는 것과 동일한 방식으로 정렬 및 조건부 서식을 수행할 수 있습니다.

항목 변경 메뉴 양식 1C 모든 조치

양식 변경 항목을 사용하면 1C 8.2 양식의 목록뿐만 아니라 1C 8.2 양식 자체도 유사하게 변경할 수 있습니다.

사용자는 1C 8.2 양식, 너비 및 높이, 열 때 기본 필드 활성화 등에서 필드의 가시성을 독립적으로 활성화 또는 비활성화할 수 있습니다.

관리 양식 1C 8.2 및 일반 양식 1C 사용

기본적으로 일반 1C 양식은 씩(일반) 1C 클라이언트 구성에 사용되고 관리 양식은 씬 및 웹 1C 클라이언트 구성에 사용됩니다. 그러나 두 가지 형태의 1C는 동시에 포함하여 모든 구성에서 사용할 수 있습니다.

이렇게 하려면 구성 속성(구성 창의 맨 위 요소)도 입력해야 합니다.

1C 8.2의 구성 속성에는 1C 양식의 비표준 사용을 활성화할 수 있는 두 개의 새로운 확인란이 있습니다.

관리되는 양식 만들기 8.2

새로운 양식 1C 8.2를 추가하는 것은 키보드의 Ins 버튼이나 추가 버튼을 사용하여 이전과 동일한 방식으로 수행됩니다. 기존 항목을 입력하려면 마우스로 두 번 클릭하십시오.

기본적으로 구성에 설정된 양식(일반 또는 관리)이 생성됩니다(구성 속성의 기본 시작 모드 속성 참조).

생성자는 양식 유형(요소의 양식, 목록)을 선택하라는 메시지를 표시합니다. 여기에서 양식에 명령 모음을 추가하거나 제거할 수 있습니다. 대부분의 경우 이러한 설정은 기본적으로 그대로 유지됩니다.

기본적으로 채워진 양식이 열립니다. 여기에 추가된 1C 객체의 모든 세부 정보가 열립니다. 생성자의 두 번째 탭에서 특정 필수 필드 목록을 선택할 수 있습니다.

양식 편집기는 세 부분으로 구성됩니다.

왼쪽 상단 모서리에는 양식 요소 목록이 있습니다. 항목을 결합할 수 있는 필드, 명령 및 그룹으로 구성됩니다. 명령 목록은 명령 인터페이스 탭에서 별도로 볼 수 있습니다.
오른쪽 상단 모서리에는 사용 가능한 양식 속성 및 개체 속성 목록이 있습니다(개체 속성 옆에 있는 십자가 열기).
아래는 결과 양식의 미리보기입니다.

사용 가능한 세부 정보를 왼쪽으로 드래그하면 양식 요소(양식의 필드)가 됩니다.

버튼이나 메뉴 항목을 추가해야 하는 경우 - 명령 탭의 오른쪽에서 새 명령을 생성해야 합니다. 이것은 양식 모듈의 함수에 대한 래퍼입니다. 실제로 호출할 함수를 지정하는 것 외에도 기능 옵션에 대한 가시성의 종속성뿐만 아니라 그림과 같은 표시를 할당할 수 있습니다.

명령도 왼쪽으로 드래그됩니다. 부모가 명령 모음이면 명령 모음 단추가 됩니다. 그렇지 않으면 단추만 됩니다.

양식 요소(필드) 목록에서 객체/양식의 속성을 드래그할 수 있을 뿐만 아니라 간단히 추가할 수도 있습니다(버튼 추가 또는 Ins). 특히 새 양식 개체인 그룹을 만들 수 있습니다.

그룹은 명령 패널이 될 수 있습니다(커서가 양식 라인에 있어야 함). 그런 다음 명령을 끌어다 놓으면 버튼이 됩니다.

그룹은 "일반"일 수 있습니다. 그런 다음 수직 및 수평으로 필드를 그룹화하는 방법입니다. 속성에서 그룹 이름을 제거할 수 있습니다.

그룹은 패널(페이지)이 될 수 있습니다. 맨 위에 추가된 그룹은 패널이고 이 유형의 중첩된 그룹은 페이지입니다. 필드는 이미 페이지로 드래그되고 있습니다.

목록에서 양식 요소를 삭제하여 불필요한 양식 요소를 제거합니다.
양식에서 필드의 위치는 요소 목록(수직) 또는 그룹(수평)의 순서에 따라 결정됩니다. 너비와 높이는 양식 요소의 속성에서 설정됩니다.

양식 요소 속성이 크게 확장되었으며 모양 제어(선택 및 지우기 버튼) 및 기본값 확인과 같은 유용한 기능이 많이 포함되어 있습니다.

차원을 포함하여 양식 자체의 속성은 이름이 Form인 양식의 루트 요소에 설정됩니다.

이벤트 처리기(사용자 작업에 대한 응답)는 이제 두 가지 유형으로 나뉩니다. 이전 항목 - 이전과 마찬가지로 양식 및 필드의 속성(예: OnChange 및 OnOpening the form)에 지정됩니다. 새로 만들기 - 명령이 되었으며 메뉴 항목 및 버튼에 사용됩니다.

플랫폼 버전 8.2부터 1C는 데이터베이스와의 인터페이스 및 사용자 상호 작용을 구축하기 위해 새로운 원칙을 사용하기 시작했습니다. 새로운 기술을 관리형 애플리케이션이라고 합니다. 양식 구성 메커니즘과 1C 서버 사용자와 데이터베이스 간의 상호 작용 방식이 가장 많이 처리되었습니다. 일반 모드는 플랫폼에서 여전히 지원되지만 시간이 지남에 따라 모든 1C 사용자는 관리 양식으로 전환됩니다.

일반 사용자의 경우 1C 문서의 관리 형식은 일반적인 형식과 모양 만 다릅니다. 개발자에게 이것은 자체 규칙, 법률 및 조건이 있는 새로운 메커니즘입니다. 많은 영역이 변경되었지만 경험이 풍부한 1C 개발자에게는 다음과 같은 혁신이 핵심으로 간주됩니다.

양식 구조의 독립적인 형성 및 플랫폼에 의한 필드 배치. 이전 개발자가 픽셀을 지정하여 필드의 위치를 설명했다면 지금은 그룹화 유형만 지정할 수 있습니다.
양식은 양식 데이터를 나타내는 속성과 수행되는 절차 및 기능인 명령으로 구성됩니다.
양식 코드는 서버와 클라이언트 측 모두에서 실행됩니다. 결국 양식 자체는 서버에서 생성되어 클라이언트에 표시되는 구성 개체입니다. 이것은 클라이언트와 서버 부분을 결합한다는 것을 의미합니다.
클라이언트 측에서는 많은 유형의 데이터를 사용할 수 없게 되었으며 이제 정보베이스의 데이터를 변경할 방법이 없습니다.
각 프로시저 또는 함수에 대해 특수 설정(컴파일 지시문)을 지정해야 합니다. 코드가 실행되는 위치를 담당하며 다음 값을 가질 수 있습니다.
- 클라이언트에서;
- 서버에서;
- ServerWithoutContext에서;
- 온클라이언트온서버;
- 클라이언트에서 컨텍스트 없이 서버에서.

마지막 요점은 관리 양식 모드에서 특히 심각합니다. 개발자가 지시문 또는 클라이언트-서버 상호 작용에 정통하지 않은 경우 관리되는 양식을 만드는 것이 매우 어려울 것입니다. 1C:Enterprise 8.3에서 관리되는 양식을 구축하기 위한 모든 새로운 원칙은 3계층 아키텍처의 일반 개념으로 통합됩니다. 여기에는 클라이언트 컴퓨터, 1C 서버 및 데이터가 저장되는 DBMS가 포함됩니다.

구성자에서 관리되는 양식을 편집하는 것도 달라졌습니다. 많은 측면이 변경되었으며 관리되는 양식이 없었던 버전 7.7의 개발자는 놀랄 수 있습니다. 구성 개체의 양식을 열어 볼 수 있는 양식 디자이너의 모양도 변경되었습니다. 개체를 열면 여러 섹션으로 나누어진 창이 표시됩니다.

양식 인터페이스 요소. 왼쪽 상단에는 프로그램과 사용자의 상호 작용을 보장하는 선택한 양식에 표시된 모든 필드를 나열하는 창이 있습니다.
양식 세부 정보. 오른쪽 상단에는 양식이 작동하는 모든 데이터가 있습니다. 정보가 클라이언트 측에 저장되는 것은 그들 안에 있습니다.
관리되는 양식을 표시합니다. 아래에서 인터페이스 요소를 기반으로 한 모양의 미리보기를 볼 수 있습니다.
양식 모듈. 이 양식에서 사용하는 절차 및 기능을 포함하는 섹션입니다. 여기에서 프로그램과 사용자 및 데이터베이스의 상호 작용을 위한 알고리즘 코드를 찾을 수 있습니다.

1C 개발자는 클라이언트가 관리 양식으로 전환하도록 선동하고 있으므로 관리 양식 개발 원칙을 배우는 것은 시간 문제입니다. 이러한 유형의 양식으로 작업을 시작하면 이것이 개발 표준화 및 단일 규칙 준수를 향한 단계임을 이해하게 될 것입니다. 따라서 1C 8.3에서 관리되는 양식으로 작업하는 기능은 1C 개발자로서의 수준을 높입니다.

관리되는 양식 디자인 지침

우선 1C 관리 모드의 메커니즘을 이해하려면 양식이 서버와 클라이언트 모두에 존재한다는 점을 기억해야 합니다. 또한 클라이언트에서 이 개체는 프로그램과의 사용자 상호 작용 인터페이스의 이미지일 뿐입니다. 모든 계산, 알고리즘, 계산 및 처리는 서버 측에서만 발생해야 합니다. 이것은 클라이언트에서 많은 기능과 매개 변수를 사용할 수 없다는 것뿐만 아니라 성능 요구 사항에 의해 결정됩니다.

폼 모듈에서 각 프로시저 및 함수 앞에 작성해야 하는 디렉티브의 이름으로 프로시저가 수행되는 위치를 파악할 수 있습니다. "컨텍스트 없음"이라는 문구는 관리되는 양식의 데이터가 서버의 이 프로시저에 전달되지 않음을 나타냅니다. 따라서 이러한 절차에서는 사용자가 입력한 값을 기반으로 알고리즘을 작성할 수 없습니다. 이 문구를 지정하지 않으면 양식 전체가 모든 세부 정보와 함께 전송되며 액세스할 수 있습니다.

1C 개발자는 컨텍스트가 아닌 서버 호출을 사용하여 가능한 한 그 수를 줄이고 클라이언트에서 계산을 수행하지 않는 것이 좋습니다. 이론적 배경이 없는 초보 개발자가 이러한 모든 규칙을 준수하고 코드를 올바르게 변경하는 것은 어렵습니다. 직접 작업을 시작하기 전에 관리되는 구성 양식을 열고 구문과 클라이언트와 서버가 상호 작용하는 방식을 살펴보는 것이 유용할 것입니다.

&НаСервере Процедура ПолучитьПлатежноРасчетныеДокументыИзХранилища(НовыйАдресВХранилище) &НаСервереБезКонтекста Функция ЕстьРасчетыСКлиентом(ДокументОснование) &НаСервереБезКонтекста Процедура ЗаполнитьСписокВыбораКПП(СписокВыбора, Контрагент, ДатаСведений) &НаКлиенте Процедура ЗаполнитьГоловногоКонтрагентаЗавершение(ВыбранноеЗначение, ДополнительныеПараметры) &НаСервере Процедура УстановитьТекстПлатежноРасчетныхДокументов() &НаСервере Функция ЕстьЗаполненныеИсходныеДокументы()

1C 양식 개발을 위한 새로운 규칙은 모든 개발자가 준수한다면 큰 도움이 될 것입니다. 또한 프로그래머, 1C에서 일하는 회사, 프랜차이즈 및 1C 개발자 모두가 더 나은 변화를 느낄 것입니다. 1C에서 관리 양식의 올바른 작동의 주요 결과:

구성 유지 관리가 쉽고 코드 가독성이 향상됩니다. 이것으로부터 우리는 한 개발자가 작성한 알고리즘을 많은 시간을 들이지 않고도 다른 직원이 항상 수정할 수 있다는 결론을 내릴 수 있습니다.
클라이언트와 서버에서 실행되는 코드의 분리. 이러한 측면에서 사용 가능한 기능이 얼마나 다른지를 고려할 때 이들을 분리하는 것이 올바른 조치입니다.
개발자는 플랫폼 논리, 클라이언트-서버 상호 작용 및 작성하는 알고리즘을 더 깊이 이해합니다. 버전 8.0 및 이전 버전에서는 클라이언트-서버 부분을 이해하지 않고 개발된 문서 또는 디렉토리 형식을 찾는 것이 매우 일반적이었습니다.
구성 속도를 높이고 클라이언트 컴퓨터의 부하를 줄입니다.
강력한 PC를 구입할 필요가 없기 때문에 업무용 컴퓨터 구입 비용을 줄입니다.

기본 1C 시작 모드로 관리되는 양식을 선택하면 많은 놀라움을 가져올 수 있습니다. 그러나 올바른 접근 방식을 사용하면 이 단계는 큰 배당금을 가져올 것이므로 러시아 전역에서 점점 더 많은 1C 사용자가 이를 결정합니다. 1C 회사가 향후 관리 양식 개발에 의존하고 있다는 사실을 고려할 때 구식 기존 양식을 유지하는 것은 위험합니다.

1c 8.3 관리 양식 이벤트. 관리되는 양식의 내부

소개