위젯 개발을 위한 일반 가이드라인

  • 릴리스 버전: Zurich
  • 업데이트 날짜 2025년 07월 31일
  • 소요 시간: 5분

    • 사용자 지정 위젯을 개발할 때는 최적의 성능, 확장 가능한 개발 및 우수한 사용자 환경을 위해 다음과 같은 일반 가이드라인을 염두에 두어야 합니다.

    최종 사용자에게 예시를 제공하는 기본 상태 생성

    페이지에 처음 추가될 때 위젯에 정의된 인스턴스 옵션이 없습니다. 이 빈 상태의 위젯은 비어 있어 표시되어 혼동을 일으킬 수 있습니다. 위젯에 초기 구성이 필요한 상황에서는 필요한 구성을 관리자에게 알려주는 기본 상태가 위젯에 있는지 확인하십시오.

    데모 데이터를 사용하여 위젯을 생성할 수도 있습니다. 데모 데이터를 사용하여 다음을 수행할 수도 있습니다.

    • 사용자에게 위젯 기능을 명확하게 시연합니다.
    • 위젯 편집기에서 위젯을 미리 볼 때 데이터를 제공합니다. (데모 데이터는 디자이너에 표시되지 않습니다.)

    자세히 알아보기: 자습서: 사용자 지정 위젯 빌드.

    가능한 경우 복제가 아닌 위젯 포함

    기존 위젯을 사용자 지정 위젯에 포함하면 코드를 복제하거나 복제하지 않고도 기존 기능을 활용할 수 있습니다. 여전히 매개변수를 포함된 위젯에 전달하여 동작을 제어할 수 있습니다.

    자세히 알아보기: 기존 위젯 포함

    성능 향상을 위해 대규모 데이터 세트를 사용하지 않도록 합니다.

    데이터 쿼리, ACL 평가, 비즈니스 규칙 실행, 데이터 처리에는 시간이 걸리고 성능이 저하될 수 있습니다. 포털 사용자에게 필요한 데이터의 양을 결정한 다음 스크립트와 쿼리에 적절한 제한과 필터를 적용합니다. 중요한 데이터 또는 처리가 필요한 위젯을 포털의 자체 개별 페이지로 격리합니다. 큰 데이터 세트를 사용하는 다음 항목을 구현하지 마십시오.

    • 많은 양의 데이터를 로드하는 스크립팅된 메뉴 항목으로 인해 포털의 모든 페이지가 느리게 로드될 수 있습니다.
    • 첨부 파일 [sys_attachment] 테이블의 고화질 미디어 파일 또는 글꼴과 같은 큰 파일 및 첨부 파일.
    • 위젯 자동 새로 고침 위젯의 클라이언트 컨트롤러가 server.update(),spUtil.update(),server.refresh() 또는 spUtil.refresh()를 호출할 때마다 애플리케이션은 위젯의 서버 스크립트를 실행하고 데이터 객체를 클라이언트로 다시 보냅니다.
    • 필터링되지 않은 기록 감시자입니다. recordWatch() 함수는 테이블 또는 필터에 대한 업데이트를 감시하고 콜백 함수에서 값을 반환합니다. 조사할 특정 필드에 대한 필터를 추가하면 위젯이 서버에 대해 수행하는 호출 수가 줄어듭니다. 콜백 함수에 업데이트가 있음을 클라이언트에 알리는 기록 생성자에 대한 응답으로 위젯을 새로 고칠 시기를 지정하면 성능을 향상시킬 수도 있습니다.
    • setLimit 함수가 없는 GlideRecord 쿼리가 있는 서버 측 스크립트. setLimit 함수를 사용하면 반환되는 레코드 수를 제한하고 쿼리의 응답 시간을 개선할 수 있습니다. 유연성을 높이기 위해 하드 코딩된 값(예: gr.setLimit(options.limit || 100))을 할당하는 대신 이 제한을 인스턴스 옵션에 연결할 수 있습니다.
    자세히 알아보기:
    복잡한 위젯을 포함하는 대신 지시문 작성

    서버에서 포함된 위젯을 호출하면 해당 위젯과 연결된 모든 스크립트가 반환됩니다. 위젯의 하위 섹션만 필요한 경우 전체 위젯을 포함하면 불필요한 오버헤드가 발생합니다. 대신 지시문을 사용하여 위젯 간에 간단한 코드를 공유하십시오. 예를 들어, 지시어는 UI 구성요소를 빌드할 때 유용합니다. 서버 측 및 클라이언트 측 기능이 있는 복잡한 구성요소는 위젯으로 남겨두는 것이 가장 좋습니다. 포함된 위젯 대신 지시문을 사용하여 다음을 수행합니다.

    • 범위 또는 사용자 지정 범위 동작을 여러 위젯과 공유합니다.
    • 위젯의 재사용 가능한 경량 하위 섹션을 공유합니다.
    • 목록 또는 아바타와 같은 공통 UI 기능을 공유합니다.
    • 위젯 동작을 확장합니다.

    자세히 알아보기: Angular 공급자를 통해 구성요소 재사용.

    서비스 또는 팩터리를 사용하여 데이터를 공유하고 상태를 유지

    데이터 서비스 및 팩터리는 서버에 대한 여러 호출 없이 위젯에서 상태를 유지 및 유지하므로 다음을 수행할 수 있습니다.

    • 기록 또는 필터를 변경할 때 위젯을 동기화된 상태로 유지합니다.
    • 위젯 간에 데이터를 공유합니다.
    • 더 성능이 뛰어난 위젯을 개발합니다.

    자세히 알아보기: Angular 공급자를 통해 구성요소 재사용.

    게시/구독 서비스로 이벤트 처리

    DOM에서 $broadcast 사용하지 마십시오. $broadcast 등록된 리스너에게 알리는 이벤트 이름을 모든 하위 범위에 디스패치합니다. 이는 $rootScope 전역 객체를 사용해야 하는 비용이 많이 드는 호출일 수 있습니다.

    대신 게시/구독 서비스를 사용하여 이벤트를 처리하십시오. 게시/구독 서비스를 사용할 때 콜백 핸들러를 통해 위젯 간에 명확한 관계가 형성됩니다. 이 모델에서는 이벤트 상태를 보다 잘 제어할 수 있습니다.

    REST 호출 또는 server.get 을 사용하여 서버에서 데이터를 가져옵니다.

    server.update()를 호출하면 전체 위젯이 서버에서 반환됩니다. 위젯에 서로 다른 코드 경로가 포함된 경우 서버를 업데이트하기 위해 여러 번 호출하면 성능에 영향을 줄 수 있습니다. 일반적으로 서버 스크립트를 사용하여 위젯의 초기 상태를 설정합니다. 후속 업데이트의 경우 인스턴스에서 스크립트 포함을 호출하는 스크립트된 REST API를 사용합니다. 이 방법은 다음과 같습니다.

    • UI 요소에서 비즈니스 논리를 분리합니다.
    • 코드를 중앙 집중화하여 한 곳에서 변경할 수 있도록 합니다.
    server.get을 사용하여 서버에 정보를 전달할 수도 있습니다. 이 함수를 input.action과 함께 사용하여 서버 스크립트의 특정 부분을 실행합니다.
    현지화, 접근성 및 UI를 염두에 두고 개발

    사용자에게 최상의 환경을 제공하려면 다음 가이드라인을 따르세요.

    • 모바일 환경에서 위젯의 영향을 고려하십시오. 예를 들어 마우스 오버 및 모바일 장치로 변환되지 않는 기타 이벤트를 사용하지 마십시오.
    • SCSS 변수를 사용하여 항목을 재사용합니다. SCSS 변수 문서를 참조하십시오.
    • 색상을 사용할 때 변수 이름을 사용합니다.
    • 현지화 API에서 번역을 위해 문자열을 래핑합니다. 위젯 국제화 문서를 참조하십시오.
    클라이언트 스크립트에서 사용하지 않는 Angular 제공자 제거
    보다 손쉬운 유지관리를 위해 클라이언트 스크립트 함수 문에 삽입되어 사용되지 않은 Angular 제공자를 제거합니다.
    사용하지 마십시오. <script> tags in HTML templates
    에서 프로덕션 문제의 가능성을 줄이려면 서비스 포털, 를 사용하여 인라인 템플릿을 사용하지 마십시오. <script> tags in a widget's HTML template. Instead, create a related Angular ng-template record for the widget.