테마 설정용 Objects 유형

새로운 type: objects테마 설정에 지원되는 유형에 도입합니다. 이 유형은 곧 비추천(deprecate)할 예정인 기존 json_schema 유형을 대체하는 데 사용할 수 있습니다.

objects 유형 테마 설정 정의

objects 유형 테마 설정을 만들려면 먼저 설정 이름으로 사용될 최상위 키를 다른 테마 설정과 동일하게 정의합니다.

links: ...

이어서 설정에 type, default, schema 키워드를 추가합니다.

links:
  type: objects
  default: []
  schema: ...

type: objects는 이 설정이 objects 유형임을 나타내며, default: [] 주석은 설정의 기본값을 빈 배열로 설정합니다. schema가 정의된 후에도 기본값을 객체 배열로 설정할 수 있음을 참고하세요. 이 부분은 나중에 시연하겠습니다.

스키마를 정의하려면 먼저 다음과 같이 스키마의 name을 정의합니다:

links:
  type: objects
  default: []
  schema:
    name: link

다음으로, 스키마에 properties 키워드를 추가하여 각 객체가 어떤 형태여야 하는지 정의하고 검증할 수 있게 합니다.

links:
  type: objects
  default: []
  schema:
    name: link
    properties:
      name: ...

위 예제에서는 link 객체에 name 속성이 있음을 명시하고 있습니다. 예상되는 데이터 유형을 정의하려면 각 속성에 type 키워드를 정의해야 합니다.

links:
  type: objects
  default: []
  schema:
    name: link
    properties:
      name:
        type: string

위 스키마 정의는 link 객체에 string 유형의 name 속성이 있음을 나타내며, 이는 해당 속성에 문자열 값만 허용됨을 의미합니다. 현재 지원되는 유형은 다음과 같습니다:

  • string: 속성 값이 문자열로 저장됩니다.
  • integer: 속성 값이 정수로 저장됩니다.
  • float: 속성 값이 부동소수점으로 저장됩니다.
  • boolean: 속성 값이 true 또는 false입니다.
  • upload: 속성 값이 첨부 파일 URL입니다.
  • enum: 속성 값은 choices 키워드에 정의된 값 중 하나여야 합니다.
    links:
      type: objects
      default: []
      schema:
        name: link
        properties:
          name:
            type: enum
            choices:
              - name 1
              - name 2
              - name 3
    
  • categories: 속성 값이 유효한 카테고리 ID 배열입니다.
  • groups: 속성 값이 유효한 그룹 ID 배열입니다.
  • tags: 속성 값이 유효한 태그 이름 배열입니다.
  • icon: 속성 값은 Discourse 아이콘 세트의 단일 아이콘 이름입니다. 선택된 아이콘은 자동으로 스프라이트 시트에 추가되므로 별도로 등록하지 않고도 렌더링할 수 있습니다.

스키마가 정의된 이제 설정의 기본값을 다음과 같이 yaml에서 배열을 정의하여 설정할 수 있습니다:

links:
  type: objects
  default:
    - name: link 1
      title: link 1 title
    - name: link 2
      title: link 2 title
  schema:
    name: link
    properties:
      name:
        type: string
      title:
        type: string

필수 속성

정의된 모든 속성은 기본적으로 선택 사항입니다. 속성을 필수로 표시하려면 단순히 속성에 required: true를 주석으로 추가합니다. 속성을 선택 사항으로 표시하려면 required: false를 주석으로 추가할 수도 있습니다.

links:
  type: objects
  default: []
  schema:
    name: link
    properties:
      name:
        type: string
        required: true
      title:
        type: string
        required: false

사용자 정의 검증

특정 속성 유형의 경우, validations 키워드로 주석 처리하여 선언할 수 있는 내장 사용자 정의 검증이 있습니다.

links:
  type: objects
  default: []
  schema:
    name: link
    properties:
      name:
        type: string
        required: true
        validations:
          min: 1
          max: 2048
          url: true

string 유형의 검증

  • min_length: 속성의 최소 길이. 키워드 값은 정수여야 합니다.
  • max_length: 속성의 최대 길이. 키워드 값은 정수여야 합니다.
  • url: 속성이 유효한 URL인지 검증합니다. 키워드 값은 true/false일 수 있습니다.

integerfloat 유형의 검증

  • min: 속성의 최소 값. 키워드 값은 정수여야 합니다.
  • max: 속성의 최대 값. 키워드 값은 정수여야 합니다.

tags, groups, categories 유형의 검증

  • min: 속성의 최소 레코드 수. 키워드 값은 정수여야 합니다.
  • max: 속성의 최대 레코드 수. 키워드 값은 정수여야 합니다.

그룹 멤버십 해결

Object 설정은 현재 사용자를 위해 type: groups 속성을 불리언 값으로 해결할 수 있습니다. 이는 테마 코드가 현재 사용자가 구성된 그룹 중 하나에 속하는지 여부만 알아야 하는 경우 유용합니다. currentUser.groups에는 사용자에게 표시되는 그룹만 포함되기 때문입니다.

groups 속성에 resolve_group_membership: true를 추가합니다:

menu_sections:
  type: objects
  default:
    - name: section 1
      groups:
        - 1
        - 3
  schema:
    name: menu section
    properties:
      name:
        type: string
      groups:
        type: groups
        resolve_group_membership: true

관리자 UI와 저장된 설정 값은 여전히 원래 groups 배열을 사용합니다. 프론트엔드 런타임 settings 객체에서 Discourse는 각 객체에서 그룹 ID를 제거하고, 동일한 속성 이름에 user_in_ 접두사가 붙은 불리언 값을 추가합니다:

for (const section of settings.menu_sections) {
  if (section.user_in_groups) {
    // 사용자는 이 섹션에 대해 선택된 그룹 중 하나에 속합니다.
  }
}

이 옵션은 type: groups인 객체 스키마 속성에서만 유효합니다. 중첩된 객체 스키마 및 logged_in_usersanonymous_users와 같은 자동 그룹에서도 작동합니다.

중첩된 객체 구조

객체는 객체 배열을 포함하는 속성을 가질 수도 있습니다. 중첩된 객체 구조를 만들려면 속성에 type: objects와 관련된 schema 정의를 주석으로 추가할 수 있습니다.

sections:
  type: objects
  default:
    - name: section 1
      links:
        - name: link 1
          url: /some/url
        - name: link 2
          url: /some/other/url
  schema:
    name: section
    properties:
      name:
        type: string
        required: true
      links:
        type: objects
        schema:
          name: link
          properties:
            name:
              type: string
            url:
              type: string

설정 설명 및 로컬라이제이션

en 로케일에서 설정에 설명을 추가하려면, 다음과 같은 objects 유형 테마 설정이 주어졌을 때, 다음 형식의 locales/en.yml 파일을 생성합니다.

sections:
  type: objects
  default:
    - name: section 1
      links:
        - name: link 1
          url: /some/url
        - name: link 2
          url: /some/other/url
  schema:
    name: section
    properties:
      name:
        type: string
        required: true
      links:
        type: objects
        schema:
          name: link
          properties:
            name:
              type: string
            url:
              type: string
en:
  theme_metadata:
    settings:
      sections:
        description: This is a description for the sections theme setting
        schema:
          properties:
            name:
              label: Name
              description: The description for the property
            links:
              name:
                label: Name
                description: The description for the property
              url:
                label: URL
                description: The description for the property

이 문서는 버전 관리됩니다 - github에서 변경 사항을 제안하세요.

16개의 좋아요

JSON 스키마 스타일의 비추천(deprecation)이 좋은 아이디어라는 점에 대해서는 아직 설득이 되지 않습니다.

이러한 스키마는 상당히 복잡해질 수 있고, 개발자에게 가장 친숙한 형식은 아니므로(그 점에서 이 변경은 훌륭한 발전입니다), JSON 스키마를 검증하는 온라인 도구가 존재하며, 이는 스키마 자체와 기본 데이터를 모두 검증하는 데 매우 유용한 방법입니다.

예: https://www.jsonschemavalidator.net/

이 새로운 환경에서는 이 도구가 어떻게 작동하게 될까요?

2개의 좋아요

테마를 업로드할 때 정의된 스키마에 대해 기본 데이터를 검증할 예정입니다. 다만, 현재 스키마 정의 자체의 유효성을 검증하지는 않지만, 이를 구현하는 것은 어렵지 않을 것입니다. 사실 현재 json schema 설정에 대해서도 정의된 스키마에 대해 기본 데이터를 검증하지 않는다고 생각합니다.

현재 json schema 타입 설정의 구현은 관리 인터페이스의 에디터가 가장 두드러지지만 여러 면에서 다소 깨져 있는 상태입니다. 내부적으로 논의한 결과, json schema가 제공하는 모든 가능성을 허용하는 것보다 우리가 정의한 제한된 스키마 형식을 유지하는 것이 훨씬 관리하기 쉽다고 판단했습니다.

2개의 좋아요

여기 몇 가지 멋진 기능이 있습니다:

  • JSON.parse를 제거하고 설정에 직접 접근하여 객체를 가져올 수 있습니다. 정말 좋습니다.

  • URL 검증기!

:chefs_kiss: :chefs_kiss:

5개의 좋아요

편집기에서 여러 줄이 유지되는 방법이 있을까요?

기본 설정은 작동합니다:

- name: markdown
  value: > 
    ## Heading
      * first bullet
      * second bullet

하지만 이것을 편집하면 줄바꿈이 사라집니다.

또한, 더 긴 형식의 데이터를 저장할 수 있고, 더 큰 “텍스트 영역” 편집기를 제공할 수 있는 “텍스트” 타입이 있으면 좋겠습니다.

5개의 좋아요

다음과 같은 피드백이 있습니다:

2개의 좋아요

이 문제를 발견했으며 다음 커밋에서 수정되었습니다:

1개의 좋아요

인터페이스에서 항목을 다시 정렬할 수 있을까요?

예를 들어, 이것은 이지 푸터 테마 구성 요소의 객체 설정 편집기입니다. 현재는 항목을 재배열할 수 없습니다:

4개의 좋아요

저도 이 기능을 요청하고 싶었습니다! :+1:


참고로, 첫 번째 게시글에 identifier 속성에 대한 정보가 포함되어 있으면 도움이 될 것 같습니다.

위 Nolo님의 이미지를 보기 전에, 기본 하위 라벨을 속성 값으로 교체하는 것은 불가능하다고 생각했습니다. 코드를 살펴본 후 identifier 속성을 발견했습니다.

4개의 좋아요

다시 정렬하는 것은 내부에서도 언급되었던 사항입니다. 이번 주에 구현해 보겠습니다.

알겠습니다. identifier 속성에 대해 첫 번째 게시물을 업데이트하겠습니다.

5개의 좋아요

네, 곧 레거시가 될 json 시스템을 대체하려면 기존 인터페이스와 동일하거나 더 나은 수준이어야 합니다:

정렬 순서도 포함해야 합니다.

1개의 좋아요

안녕하세요, 다른 필드 유형을 곧 지원할 계획이 있나요?

예를 들어;

  • 마크다운 형식을 지원하는 long_string (커스터마이징 가능한 툴바 포함),
  • date 필드 (유효성 검사 규칙 포함),
  • color 필드 (유효성 검사 규칙 포함)?
1개의 좋아요

현재 계획은 없지만, 유용할 것에는 동의합니다. 저도 icon 필드가 있으면 좋겠습니다.

8개의 좋아요

제 경험상, 이는 저장된 프리셋처럼 작동하는 것 같습니다. 이 예시에서는 첫 번째 두 항목이 이러한 프리셋의 혜택을 볼 수 있지만, 그 이후의 모든 새 항목은 초기에 빈 상태로 생성됩니다.

이것은 또한 각 필드에 대해 기본값을 설정할 수 없음을 의미합니다. 예를 들어, 체크박스를 처음부터 체크된 상태로 시작하게 하고 싶다면 그렇게 할 수 없습니다.

links:
  type: objects
  default:
    - name: link 1
      title: link 1 title
    - name: link 2
      title: link 2 title
  schema:
    name: link
    properties:
      is_active:
        type: boolean
        default: true 

default: true는 예상대로 작동하지 않습니다.

생성되는 각 항목에 대해 필드별 기본값을 설정할 수 있는 방법이 있을까요?

Sass에서 객체 속성을 변수로 가져오는 방법이 있나요?

문자열을 파싱하는 방법은 항상 사용할 수 있지만, 이 방식으로 권장하는 것은 좋은 아이디어가 아닙니다. :sweat_smile:

1개의 좋아요

예시를 공유해 주셔서 감사합니다! 그렇긴 한데… 그렇게 매력적으로 보이지 않네요 :upside_down_face:

1개의 좋아요

참고로, 이 작업은 현재 어느 정도 진행되었나요? (너무 오래 보지 않고 간단히 여쭤봅니다.)

2개의 좋아요

네, 별로 좋지 않으니 그렇게 하지 마세요. :smile:. 가능할지 확인해 보기 위한 시도가 더 컸고, 합리적인 접근법은 아니었습니다.
동의합니다. 직접적인 방법이 있으면 좋겠어요! :+1:

저도 알고 싶습니다!
또한, 제가 맞다면, json_schema와의 기능 동등성에서 유일한 누락된 기능이 될 것입니다.

2개의 좋아요

업로드 타입이 사용 가능할 것으로 기대했지만, 실제로는 그렇지 않네요.
코어 코드를 간단히 살펴보니, topic, post, upload 타입은 서버 측에는 구현되어 있지만 프론트엔드에는 구현되어 있지 않더라고요. 특정 이유가 있을까요? :thinking: