안녕! 오늘 저는 콘텐츠 관리 경험을 개선하고 새로운 종류의 CMS인 Flutter 애플리케이션 개발 세계에 추가 기능을 제공하기 위해 디자인된 야간 및 주말 작업의 결실을 여러분께 소개하고 싶습니다.

우리는 Nanc에 대해 이야기하고 있습니다. - 일반적인 C MS 가 아닙니다 . 이것이 "정상이 아닌" 이유와 이를 통해 무엇을 할 수 있는지는 이 기사를 읽고 나면 알게 될 것입니다.

이 기사에는 이론뿐만 아니라 "연습"도 포함되어 있습니다. Nanc 샌드박스에서 플레이할 수 있습니다. Nanc의 기능을 대중에게 보여주기 위해 두 개의 데모 애플리케이션이 만들어졌습니다. 하나는 Flutter 애플리케이션을 모방한 클라이언트 애플리케이션이고 다른 하나는 Flutter 기반 Nanc 애플리케이션이 무엇을 할 수 있는지에 대한 아이디어를 제공하는 사전 구축된 Nanc CMS입니다. 그리고 Nanc CMS 애플리케이션은 클라이언트 애플리케이션을 CMS와 동기화하기 위해 추가 로직 레이어가 구현된 사전 구성된 CMS입니다.

텍스트에 있는 대부분의 논리 블록 끝에는 Nanc의 일부 측면을 사용/시연하는 방법에 대한 예가 포함된 YouTube 비디오가 있습니다.

목차

1. 소개

2. CMS 소개

   1. 모델 유형

      1. 수집
      2. 독주

   2. 편집자

      1. 일반적인 설명
      2. 코드 우선
      3. 인터페이스 우선
      4. 하이브리드 모드

   3. 필드

      1. 부울
      2. 색상
      3. 날짜
      4. 동적
      5. 열거형
      6. 머리글
      7. 상
      8. ID
      9. 다중 선택기
      10. 숫자
      11. 선택자
      12. 끈
      13. 구조
      14. 화면

3. 동적 Flutter 앱

   1. 대화형 문서
   2. 확장성
   3. 간단
   4. 전원
   5. 편의
   6. 성능

4. Nanc 데모 앱

   1. 일반적인
   2. 고객
   3. 관리자
   4. 연결 관리자

5. 다음은 무엇입니까 / 이후

Nanc CMS 소개

그래서. Nanc는 자체 백엔드를 가져오지 않는 백엔드에 구애받지 않는 CMS입니다. 어떻게 작동하나요? Nanc는 네트워크 서비스 인터페이스 구현을 제안합니다. 현재는 6개의 메소드가 있지만 출시 시점에는 약 10개가 될 것입니다. 이건 많나요, 적나요? 예를 들어 데모 애플리케이션용 API를 구현하는 데 170줄의 코드가 필요했습니다. 이러한 방법은 기존 백엔드에 대한 Nanc의 모든 작업을 담당합니다. 구현은 Dart(Flutter의 개발 언어이기도 함)로 작성되어야 합니다. 앞으로 Nanc는 특정 백엔드 옵션(Firebase, Supabase, 로컬/네트워크 SQLite 및 REST 및 GraphQL의 일반 구현(아마도 다른 것일 수도 있음))을 위해 이러한 인터페이스를 즉시 구현할 예정이며, 이 구현에 대해 생각할 필요가 없습니다. 모두 또는 그래야 할 것입니다. 그러나 약간만.

모델 유형

Nanc의 모델은 Nanc로 제어하려는 엔터티에 대한 구조적 설명입니다. 모델에는 엔터티 이름, 다양한 시각적 매개변수 및 필드 설명이 포함됩니다.

수집

컬렉션은 많은 인스턴스를 가질 수 있는 엔터티입니다. 사용자 목록, 도서 목록, 리뷰 목록은 Nanc의 컬렉션형 모델의 좋은 예입니다.

관계형 데이터베이스에 익숙하다면 Nanc 컬렉션의 예는 데이터베이스의 거의 모든 테이블일 것입니다.

독주

솔로(모델)는 단일 인스턴스에 존재하는 개체입니다. 예를 들어 기능 토글이나 구성, 또는... "모바일 애플리케이션의 기본 화면"입니다. 일반적으로 솔로 모델은 데이터베이스를 투영하는 용도로 유용성을 높이도록 설계되었습니다. 그리고 솔로 모델은 레코드가 하나만 있는 데이터베이스의 모든 테이블이 될 수 있습니다. 그러나 현재 이 모델 클래스를 구현하려면 이 모델의 레코드 (데이터베이스의 행)에 모델 자체의 id 와 동일한 id 가 있어야 합니다.

 final Model landingPage = Model( name: 'Landing page', /// ? id in format [toSnakeCase(name)] will be set automatically, if omitted // id: 'landing_page', isCollection: false, icon: IconPackNames.flu_document_page_break_regular, fields: [ ...

편집자

일반적인 설명

Nanc는 코드, Nanc 인터페이스 자체, 이러한 옵션의 조합 등 여러 가지 방법으로 구성할 수 있습니다.

코드 우선 구성

내가 "구성"이라고 말할 때, 우선 모델의 구조를 설명하는 것을 의미합니다. 제품의 기능을 설명하는 엔터티인 기능 모델이라는 간단한 예를 들어 보겠습니다. 이 엔터티에는 다음 필드가 포함되어 있습니다.

• ID
• 제목
• 영상
• 설명

코드 우선 구성으로의 구현은 다음과 같습니다.

 import 'package:fields/fields.dart'; import 'package:icons/icons.dart'; import 'package:model/model.dart'; final Model feature = Model( name: 'Feature', icon: IconPackNames.flu_ribbon_star_filled, fields: [ [ IdField(width: 200), StringField(name: 'Title', maxLines: 1, isRequired: true, width: 400), ], [ IconField(name: 'Image', isRequired: true), ], [ StringField(name: 'Description', isRequired: true, showInList: true), ], ], );

이러한 모델을 설명하고 이를 Nanc CMS에서 사용하면 해당 모델의 모든 CRUD 작업을 사용할 수 있습니다.

인터페이스 우선 구성

Nanc 인터페이스를 통해 완전히 동일한 기능 모델(기능 변형이라고 부르자)을 생성할 수 있습니다. 그리고 (Nanc를 사용하기 위한 모든 준비 작업이 완료되었다는 점을 고려하면) - Nanc에서 모델을 생성하면 즉시 데이터베이스에 테이블이 생성되고 전체 CRUD도 즉시 사용할 수 있습니다.

또한 Nanc 인터페이스를 통해 모델을 생성할 때 데이터베이스에 아무것도 생성하지 않는 보다 안전한 방법을 사용할 수 있습니다. 그리고 데이터베이스에 테이블을 독립적으로 생성한 다음 그 아래에 Nanc에서 모델을 생성합니다. 그건 그렇고, 코드에서 구성을 설명하는 경우 수행해야 하는 작업입니다. 새 테이블은 데이터베이스에 나타나지 않습니다.

하이브리드 구성

이 옵션은 코드 우선 구성이 있고 Nanc 인터페이스를 통해 변경하기로 결정한 경우 사용할 수 있습니다. 이 경우 이 모델에 대한 모든 추가 변경은 인터페이스를 통해서만 가능하며 원래 코드 모델에 대한 변경 사항은 무시됩니다. Code-first로 돌아가는 유일한 방법은 모델을 "재설정"하는 것입니다. 이 경우 인터페이스를 통해 이루어진 모델 구조에 대한 모든 변경 사항이 지워지고 Code-first 구성이 다시 사용됩니다. 이 재설정으로 인해 데이터는 영향을 받지 않습니다. 모델 구조에만 영향을 미칩니다.

필드

이제 Nanc가 현재 어떤 유형의 필드를 지원하는지 살펴보겠습니다.

부울

BoolField를 사용하면 bool 데이터 유형을 제어하고 기본값을 사용자 정의할 수 있습니다.

색상

ColorField는 Nanc에서 즉시 색상을 선택할 수 있는 편리한 색상 선택기를 제공합니다. 또한 AHEX 코드를 편집하여 수동으로 변경할 수 있는 기능도 제공합니다. AHEX는 고전적인 HEX 색상(예: #10A0CF )이지만 추가 투명도 값이 먼저 지정됩니다. 이 경우 이 색상은 #FF10A0CF 색상과 유사합니다( FF 는 100% 불투명도입니다. 색상은 완전히 불투명합니다). 불투명도가 50%인 동일한 색상은 다음과 같습니다: #7F10A0CF .

날짜

DateField는 날짜와 시간을 제어합니다(두 값을 동시에 사용하고 날짜와 시간에 대한 별도의 값은 나중에 구현됩니다). DateField에는 엔터티 생성 시간 타임스탬프와 변경 시간 타임스탬프를 만들어 이 필드의 동작을 수정할 수 있는 두 개의 부울 매개변수가 포함되어 있습니다.

동적

DynamicField는 한편으로는 매우 단순한 필드이지만 다른 한편으로는 다른 필드의 전체 복잡성을 포함합니다. 처음에는 이 필드의 모양(Nanc 인터페이스에서 표시되는 방식, 색상 및 해당 아이콘)만 구성할 수 있습니다. 그 이후에는 이 필드에 자신을 포함하여 Nanc에서 사용할 수 있는 모든 값이 포함될 수 있습니다. 이것은 무엇을 의미 하는가? 기본적으로 DynamicField는 필드를 자체적으로 순서대로 배치할 수 있는 기능을 갖춘 형식화된 JSON입니다.

열거형

EnumField는 여러 값 중에서 하나의 값을 선택하기 위한 필드입니다. EnumField를 선택할 때 따라야 할 규칙은 별도의 데이터베이스 테이블에 저장되지 않은 선택할 최종 값 목록이 있는 경우 Enum을 선택하는 것입니다. 그렇지 않으면 아래에서 자세히 설명하는 SelectorField를 선택합니다. TODO: 현재 이 필드는 CodeConfig를 통해서만 구성할 수 있으며 인터페이스를 통한 구성은 작동하지 않습니다.

머리글

HeaderField는 실제로 필드가 아니지만 Nanc의 모델을 시각적으로 강화하는 도구입니다. 이 비 필드를 사용하여 관련 필드 그룹에 대한 공통 헤더를 설정하거나 HeaderField를 구분 기호로 사용하여 모델 필드를 서로 구별할 수 있습니다.

상

IconField를 사용하면 미리 정의된 아이콘 세트에서 아이콘( IconData 클래스)을 선택할 수 있습니다. 현재 약 25,000개가 있으며 이 세트에는 다음 아이콘이 포함됩니다.

• 머티리얼 디자인 아이콘
• 유창한 UI 시스템 아이콘
• 리믹스 아이콘

필요한 경우 기본 제공 세트에 다른 아이콘을 추가할 수 있으며 머지않아 자신만의 아이콘을 사용할 수도 있는 옵션이 제공될 것입니다.

"아이콘도 있고 색상도 있는데 글꼴은 없나요?"라고 궁금해하실 수도 있습니다. 그렇다면 텍스트 위젯 문서에서 답을 찾을 수 있습니다. 간단히 대답하자면 Google Fonts 의 모든 글꼴을 사용할 수 있다는 것입니다.

ID

IdField는 매우 간단하지만 매우 중요한 필드입니다. Nanc에서 관리하는 모든 모델에는 ID 유형의 필드가 하나 이상 있어야 합니다. 현재는 문자열 ID 유형만 지원됩니다(한 엔터티 내의 고유한 문자열일 수 있음). 숫자 유형에 대한 지원도 추가할 계획이 있지만, 지금도 API 구현에서 필드 데이터를 숫자 유형으로 캐스팅하기만 하면 구현할 수 있습니다.

다중 선택기

MultiSelectorField는 관계형 다대다 또는 다대일 관계 구현을 담당하는 다소 복잡한 필드입니다. 이 필드를 사용하는 데는 세 가지 모드가 있습니다. 각각에 대해 좀 더 자세히 살펴보겠습니다. TODO: 현재 이 필드는 CodeConfig를 통해서만 구성할 수 있으며 인터페이스를 통한 구성은 수행되지 않습니다.

ID 배열

이 모드를 사용하면 관련 엔터티의 id 상위 엔터티에 직접 저장할 수 있습니다. 예를 들어, Reader와 Book이라는 두 가지 모델이 있습니다. 이 모드에서 독자가 가져온 책은 독자 모델 필드에 저장된 ID로 간주됩니다. 예를 들면 다음과 같습니다.

 /// user table { id: 'UUID', name: 'String', books: [ 'UUID', 'UUID' // ... ] }

위는 JSON5 구문을 사용하여 표현된 테이블 구조의 예입니다.

이 모드의 단점은 데이터 무결성이 제한되어 있다는 것입니다. books 독자 필드에서 사용되지 않는(삭제된) 도서 ID의 자동 제거를 구현하지 않으면 오류가 발생합니다.

세 번째 테이블

SQL 세계에서 관계를 제공하는 고전적인 모드입니다. 이 모드를 사용하면 엔터티 관계를 별도의 테이블에 저장하고 100% 데이터 무결성을 보장합니다. 다음 구조는 이 모드의 예입니다.

 [ /// user table { id: 'UUID', name: 'String' }, /// book table { id: 'UUID', title: 'String' }, /// user_books_relations table { user_id: 'UUID', book_id: 'UUID' } ]

7초에 약간의 경련을 볼 수 있고 자세히 살펴보면 페이지 URL이 변경된 것을 알 수 있습니다. 이것이 제가 버그를 숨기려고 시도한 방법입니다. 세 번째 테이블 모드에서는 데이터가 상위 페이지에 저장되는 경우에만 상위 페이지에 저장됩니다. 이미 저장되었습니다 🤷🏼

객체 배열

상위 레코드가 식별자를 저장하지 않고 전체 개체(중첩 레코드의 가능한 관련 엔터티가 없는 플랫 구조)를 저장한다는 점을 제외하면 일반적으로 ID 배열과 유사합니다. ID 배열과 동일한 단점이 있지만 추가로 저장소 사용이 증가합니다. 그러나 (적어도 현재로서는) 이 모드를 적용할 수 있는 영역이 있으며 이는 매우 중요합니다. 하지만 이에 대해서는 잠시 후에 이야기하겠습니다.

저는 ScreenField를 보여주는 비디오에서 제 자신보다 앞서 나가고 있습니다. 우리는 이것으로 다시 돌아올 것입니다

일반적으로 "비정규" 모드를 가상으로 만들어 세 번째 테이블을 통해 작동하고 페이지를 편집할 때 필요한 데이터가 로드되도록 하는 아이디어가 있습니다(필요한 경우).

숫자

NumberField는 숫자를 저장합니다. 그렇게 간단합니다.

선택자

SelectorField는 MultiSelectorField와 유사하지만(이름에서 짐작할 수 있듯이) 조금 더 간단합니다. 여기서 관계는 일대일 또는 일대다이며 두 가지 모드가 있습니다. TODO: 현재 이 필드는 CodeConfig를 통해서만 구성할 수 있으며 인터페이스를 통한 구성은 작동하지 않습니다.

ID

상위 레코드 필드가 연결된 레코드의 ID를 저장하는 일반적인 형태의 SQL 링크 제공입니다. 리더를 예로 들어보겠습니다. 누구입니까? 우선 사람이고, 사람은 무엇을 가지고 있는가? 좋아요! 출생 도시(어떤 이유로 우리 도서관도 알고 싶었습니다).

 /// user table { id: 'UUID', name: 'String', birth_place_id: 'UUID' }

물체

MultiSelectorField의 객체 배열과 매우 유사하지만 상위 레코드의 필드에 단일 관련 값을 저장합니다. 단점은 동일하며, 장점에 대해서도 아래에서 조금 설명하겠습니다.

끈

StringField는 문자열을 저장합니다. 이 필드에는 Nanc에서의 편집 편의성을 담당하는 하나의 개인 설정(편집 가능한 필드의 최대 높이를 제한하는 매개변수)이 있습니다. 텍스트가 큰 경우(전혀 지정하지 않는 것이 합리적임) 필드가 텍스트 높이에 맞게 조정됩니다. 크게 제한되는 경우 명시적인 필드 높이(라인 단위)를 지정할 수 있으며 그러면 항상 그렇게 됩니다. 마지막으로, 짧은 문자열의 경우 한 줄로 설정할 수 있으며, 그러면 나중에 아무리 많이 써도 필드가 확장되지 않습니다.

구조

StructureField를 사용하면 모델 레코드에 형식화된 구조의 배열을 저장할 수 있습니다. 저장할 데이터의 종류를 지정하고 쉽고 간단하게 관리할 수 있습니다. 구조 필드에 사용 가능한 유형은 절대적으로 모든 것입니다. 따라서 "동적 구조 필드 반복"을 쉽게 만들 수 있습니다. TODO: 데모 내에서는 "플랫" 필드만 StructureField에 추가할 수 있습니다.

화면

ScreenField는 Nanc에서 바로 Flutter로 전체 애플리케이션을 작성할 수 있는 필드입니다! ScreenField를 사용하면 단일 화면의 인터페이스를 설명하고, 원하는 대로 업데이트하고, Apple과 Google의 리뷰를 기다리는 지루하고 신경 쓰이는 일 없이 언제든지 몇 분 안에 작업을 수행할 수 있습니다.

이러한 유형의 분야(실제로는 Nanc의 완전히 별개의 기능적 파생물)를 좀 더 자세히 분석해 보겠습니다.

동적 Flutter 앱

ScreenField를 사용하면 브라우저(및 IDE)에서 바로 거의 모든 복잡한 인터페이스를 생성한 다음 스톡 게시를 만들지 않고도 애플리케이션에서 해당 화면을 업데이트할 수 있습니다. 가설을 빠르게 확인해야 할 경우, 이는 훌륭한 기능입니다. 이 기능은 앱의 비교적 간단한(로직 측면에서) 페이지에 적합하지만 자주 변경해야 합니다. 앞으로는 이 기능이 실제로 어떠한 제한도 없이 원하는 것을 무엇이든 만들 수 있는 상태로 확장될 것입니다.

이제 Nanc를 사용하여 동적 화면을 만드는 모든 측면을 살펴보겠습니다.

대화형 문서

Flutter에는 많은 위젯이 있습니다. 그들 중 다수. 위젯이란 무엇입니까? 이는 애플리케이션을 조립하는 데 사용되는 기능의 벽돌입니다. 시각적일 수도 있고 내부에 일부 동작이 포함된 논리적일 수도 있습니다. Nanc는 UI를 구축하는 데 사용할 수 있는 구현된 위젯의 광범위한 목록을 제공합니다. 그러나 가능성이 많을수록 이에 대해 배우는 것이 더 어렵습니다... 따라서 Nanc의 화면 편집기를 사용하면 현재 구현된 위젯, 위젯에 포함된 매개변수 및 구성 가능한 속성을 확인할 수 있는 대화형 문서에 액세스할 수 있습니다. 문서에서 직접 만든 인터페이스의 모양에 어떤 영향을 미치는지 확인하세요.

간단

Nanc를 사용하면 실시간으로 인터페이스를 생성할 수 있지만 가장 중요한 것은 이 작업을 매우 쉽고 빠르게 수행할 수 있다는 것입니다(데모 애플리케이션을 인터페이스하는 데 2시간 조금 넘게 걸렸습니다). 그러나 질문이 생깁니다. UI 자체를 만드는 방법은 무엇입니까? Nanc에는 UI를 설명하는 이국적인 구문도 없고 긴 JSON과 같이 "너무" 간단한 솔루션도 없습니다. 따라서 Nanc에서 인터페이스를 만드는 것을 싫어하게 됩니다.

최상의 솔루션을 찾은 결과는 간단하고 간단한 XML 구문입니다. 모든 표준 Flutter 위젯은 이름이 완전히 동일하지만 XML 형식입니다. 예를 들어 Nanc의 SizedBox 위젯은 <sizedBox>...</sizedBox> 이며 이 규칙은 예외 없이 모든 위젯에 적용됩니다. 위젯에 복잡한 속성이 있는 경우 접두사 prop 사용하여 XML과 동일한(또는 더 간단한) 이름을 갖게 됩니다. 예를 들어 위젯 Container 자체 내부 속성이 있는 복잡한 속성 boxDecoration 있습니다. 따라서 Nanc의 이 속성은 다음과 같은 모양을 갖습니다: <prop:decoration>...</prop:decoration> . 이 규칙은 모든 복합 속성에 적용됩니다. 마지막 측면은 상대적으로 간단한 인수가 XML 태그 매개변수라는 것입니다. 동일한 SizedBox 예로 들어보겠습니다.

 <sizedBox width="50" height="50"> ... </sizedBox>

일부 위젯의 경우 코드 작성을 단순화하기 위해 추가 인수가 구현되며 SizedBox 의 경우 width 및 height 모두 설정하는 ize 인수입니다.

여기에 작성된 모든 내용은 온라인 설명서에 있으므로 잊어버린 내용이 있거나 알고 싶은 내용이 있으면 해당 내용을 참조하여 모든 질문에 대한 답변을 찾으세요.

확장성

새 위젯에 대한 지원을 구현합니다. 10분에서 몇 시간 정도 걸립니다. 이 시점에서 거의 모든 기본 위젯이 구현되었으며, 그 중 로직을 사용하여 복잡한 인터페이스를 만들 수 있습니다. 시간이 지나면 Flutter에서 사용할 수 있는 모든 위젯이 Nanc에서 구현될 것이며 실제로 모든 것을 할 수 있습니다. 하지만 그게 전부는 아닙니다. 쉽고 간단하게 자신만의 위젯을 구현하고 XML 코드 한두 줄로 Nanc에서 사용할 수 있습니다. 예를 들어, 표준 Flutter 라이브러리에는 사진과 함께 회전판 슬라이더를 쉽게 표시할 수 있는 위젯이 없습니다. 구현을 직접 작성하거나 이와 같은 오픈 소스 솔루션을 사용해야 합니다. 그리고 필요한 것을 구현하면 위젯을 Nanc에 매우 쉽게 통합하여 사용할 수 있습니다.

전원

Nanc는 XML 코드를 Flutter의 인터페이스로 변환하는 기능 이상의 기능을 제공합니다. Nanc는 템플릿 작성 및 논리 작성 기능을 제공합니다. 조건부 요소 렌더링, 루프 그리기, 탭 처리 - 이는 이미 Nanc의 현재 0.0.1 버전에 있습니다.

지금까지 로직 부분은 매우 간단합니다. 미리 작성된 `.dart' 코드에서 탭과 이벤트 처리를 통한 상호 작용을 지원합니다. 그러나 결국 Nanc의 이 부분은 상당히 확장되어 브라우저에서 바로 Dart에 로직을 작성할 수 있게 됩니다. 귀하의 애플리케이션에서도 작동하도록 하세요.

사용자 클릭을 처리하는 접근 방식은 다음과 같습니다. 사용자가 앱에서 수행할 수 있는 "작업" 목록을 정의할 수 있습니다. 예를 들어 내부 애플리케이션 화면을 열고, 외부 링크를 클릭하고, SnackBar를 표시하고, 모달 창 등을 팝업하고, 이러한 작업에 대한 핸들러를 미리 만듭니다. 그런 다음 Nanc에서 원하는 방식으로 해당 작업을 사용하세요. 이벤트 처리에 대한 자세한 내용은 Nanc의 InkWell 위젯에 대한 설명서를 참조하세요.

편의

Nanc에는 XML 편집기가 내장되어 있지만 그다지 편리하지는 않습니다. (아직) 검색이 불가능하고, 코드가 많아 속도가 그리 빠르지 않으며, 자동 완성 기능도 없습니다. 그것으로 사는 방법? 예를 들어 사용자가 자신이 가장 좋아하는 IDE를 사용하고 실시간으로 Nanc의 변경 사항을 볼 수 있습니다. 방법을 보여드리겠습니다.

그리고 이것이 웹입니다(당신이 가지고 놀아야 할 것입니다):

미래에 자동 완성 지원이 추가될 것입니다. 아마도 먼 미래에...XML 스키마에 대해 자세히 알아보려고 며칠이 걸렸지만 지금까지는 할 수 없었습니다 🤷🏼

성능

이와 별도로 성능(모바일 장치에서 XML로 인터페이스 그리기)에 대해 언급하고 싶습니다. 간단히 말해서 Flutter 자체의 성능과 동일하며 오버헤드가 없습니다. 현재 "화면"은 비동기적으로 생성된 지연 렌더링된 위젯 목록(SliverList)입니다. 나중에 이 구현은 비동기식으로 위젯 렌더링을 시작하도록 개선될 예정이지만 결과적으로 콘텐츠를 표시하는 데 필요한 시간은 XML에 설명된 첫 번째 위젯을 렌더링하는 데 걸리는 시간과 동일하게 됩니다.

Nanc 데모 앱

일반적인

기능을 시연하기 위해 현재 Nanc로 무엇을 달성할 수 있는지 보여주는 공개 데모 앱 세트가 만들어졌습니다. 이는 Android 및 웹의 클라이언트 애플리케이션입니다(후자는 일시적으로 iOS 애플리케이션 역할도 수행함). Nanc CMS 앱도 있습니다. 아래에서 이에 대해 자세히 알아보세요.

연결

• 웹 클라이언트
• 안드로이드 클라이언트
• 낸크 CMS

고객

클라이언트는 nanc 생태계의 단일 라이브러리를 사용하는 클라이언트 데모 애플리케이션입니다. 이 라이브러리를 사용하면 XML을 Flutter의 애플리케이션 인터페이스로 변환할 수 있습니다. 이 애플리케이션에는 전적으로 Nanc에서 생성된 단 하나의 화면만 있으며, 저장 공간 없이 언제든지 원하는 대로 업데이트할 수 있습니다. 오른쪽 하단에는 연결 아이콘이 있는 버튼이 있습니다. 데모-CMS 에 연결하는 역할을 합니다. 이 "연결"에 대한 자세한 내용은 아래를 참조하세요.

관리자

Admin은 클라이언트와 동기화하는 기능을 제공하는 논리 레이어가 추가로 구현된 Nanc-CMS 데모 애플리케이션입니다(연결에 대한 자세한 내용은 아래 참조). Nanc-CMS 데모 애플리케이션에서는 사용자의 브라우저 자체와 해당 localStorage가 "백엔드" 역할을 합니다. 추가하거나 변경하는 모든 내용은 브라우저에만 저장됩니다. Nanc-CMS에서는 기존 모델과 관련된 데이터를 수정/생성/삭제할 수 있으며(표시됨) 인터페이스를 통해 자신만의 모델을 만들고 동일한 작업을 수행할 수 있습니다.

이 데모를 생성하는 데 사용된 데이터 모델의 SQL 표현으로 다음 스크린샷을 참조할 수 있습니다.

연결 관리자 / "연결"

이 섹션은 클라이언트 및 CMS 애플리케이션의 "데모" 논리에만 관련됩니다. 그리고 Nanc와의 상호작용 경험과 클라이언트 업데이트 과정을 시뮬레이션하기 위해 구현되었습니다. 하지만 가장 먼저 해야 할 일이 있습니다.

실제 프로덕션 프로젝트에서는 다음과 같은 방식으로 Nanc를 사용할 수 있습니다. API 서비스가 구현된 정적 Nanc CMS 애플리케이션을 어딘가에 배포합니다. 이는 백엔드와 통신하며 원하는 대로 Nanc를 사용할 수 있습니다. 귀하의 애플리케이션에는 인터페이스를 렌더링할 수 있는 nanc 생태계의 라이브러리가 하나 포함되어 있습니다. 업데이트를 하셨습니다. 앱이 백엔드에서 새 코드를 로드하고 업데이트되었습니다. 모두가 만족하고 만족합니다.

이 모델이 실제로 작동하는 것을 보여주기 위해 동일한 것이 구현되지만 단순화된 방식으로:

Nanc CMS는 github 페이지에 정적으로 존재하며 "실생활에서"처럼 사용할 수 있지만 브라우저는 백엔드 역할을 합니다. 즉, API는 브라우저 localStorage에서 "네트워크로 이동"하는 방식으로 구현되었습니다. 이 부분은 끝났지만 "업데이트" 프로세스를 어떻게든 보여줘야 하는 모바일 애플리케이션이 여전히 있습니다.

글쎄, 그것이 "연결"이 들어오는 곳입니다. 간단히 말해서, Nanc 클라이언트 데모 앱과 Nanc CMS 데모 앱 간에 직접 연결을 설정할 수 있습니다. 이렇게 하려면 CMS에서 QR 코드 아이콘이 있는 오른쪽 하단 버튼을 클릭해야 합니다. 나타나는 모달 창에 QR 코드가 표시됩니다. 다음으로 두 개의 의자가 있습니다. 오른쪽 하단에 있는 유사한 버튼을 눌러 모바일(또는 브라우저) 클라이언트 애플리케이션으로 이 코드를 스캔하면 연결이 자동으로 설정됩니다. 또는 QR 코드를 클릭하면 연결에 필요한 데이터가 클립보드에 복사됩니다. 그런 다음 이 데이터를 모바일 애플리케이션의 입력 필드에 붙여넣고 버튼을 눌러 연결해야 합니다. 연결이 설정되면 자신을 이해할 것입니다. 그 후에는 기존 랜딩 페이지 에서 원하는 작업을 수행할 수 있으며 모바일 앱에서 변경 사항을 실시간으로(저장 후) 확인할 수 있습니다.

하지만 랜딩 페이지 에만 국한되지는 않습니다. 브라우저에서 직접 새 모델을 생성하고 콘텐츠로 채울 수 있으며, 모델에 인터페이스 설명을 위한 필드(Screen 유형)가 있는 경우 해당 엔터티를 저장할 때 애플리케이션에서도 결과를 볼 수 있습니다. 새 모델의 화면은 기존 애플리케이션 화면을 대체합니다. 유일한 요점은 클라이언트 애플리케이션이 새로 생성된 레코드가 어떤 유형의 필드인지 모르기 때문에 ScreenFields가 될 것으로 예상되는 식별자가 규정되어 있다는 것입니다.

따라서 화면을 처음부터 완전히 만들고 이를 애플리케이션에 표시하려면 다음 목록의 항목을 IdField 값으로 사용하세요.

• 화면
• UI
• 페이지
• 상호 작용
• 마크업
• 보다

문제가 발생한 경우 admin.nanc.io 데이터를 재설정하면 됩니다(Chrome: F12 -> 애플리케이션 -> 애플리케이션 -> 저장소 -> 사이트 데이터 지우기). 클라이언트 애플리케이션을 다시 열면 항상 생성된 실제 화면 코드가 로드됩니다. 이 데모를 위해. (연결한 경우에만 브라우저의 코드가 로드됩니다.)

마지막으로 ScreenField가 포함된 새 모델의 새 페이지를 만들고 이를 애플리케이션에서 렌더링하는 작은 예입니다.

무엇 향후 계획?

공개 데모가 준비되었습니다. 소개 글이 작성되었습니다. Nanc의 향후 계획 - 모델 생성에 대한 인터페이스 접근 방식의 기능적 무결성을 완성하여 Enum, Selector 및 MultiSelector와 같은 모든 필드를 구성할 수 있도록 하는 것입니다. StructureField의 요소 위치 변경과 같은 알려진 버그를 수정합니다. 그런 다음 "어쩌고 저쩌고", 그리고 "아무개". 백로그는 적어도 다음 반년 동안은 충분할 것이지만, 기능 확장의 추가 모델은 고객 요구를 기반으로 할 것이므로 아이디어/비평/버그 발견 (그리고 많은 것들이 있음) /기타 - 클라이언트 데모 애플리케이션에서 사용할 수 있는 링크인 양식을 작성하십시오.

Nanc의 기능에 관심이 있고 협력에 관심이 있다면 양식도 작성해 주시면 확실히 상담해 드리겠습니다.