8.1 유효하고 일관된 데이터의 중요성
LearnNow 교육 관리 앱이 거의 완성되었습니다! 앱에서 모든 관련 데이터를 사용할 수 있도록 도메인 모델을 설정했습니다. Jimmy가 회사를 쉽게 관리할 수 있도록 아름답고 사용자 친화적인 페이지와 기능을 구축했습니다. 또한 Jimmy가 보다 효율적으로 작업할 수 있도록 마이크로플로우를 만들었습니다. 이제 앱의 정보가 유효하고 일관성이 있는지 확인해야 할 때입니다.
사용자가 새 코스를 만들고 세부 정보를 입력하지 않고 저장을 클릭한다고 가정해 보겠습니다. 객체가 빈 레코드로 데이터베이스에 추가되므로 시스템에 새 코스가 생성되지만 제목이나 설명이 없습니다! 지금 가능한 또 다른 방법은 (유효한) 이메일 주소(예: user@.com)가 없어도 교육생을 시스템에 추가할 수 있다는 것입니다. 그러면 지미는 필요한 경우 이들에게 연락할 수 없습니다. 이러한 불편한 상황을 방지하려면 시스템에 추가되는 모든 데이터가 지미가 제공한 규칙을 충족하는지 확인해야 합니다. 즉, 데이터베이스에 추가되는 데이터가 유효한지 확인해야 합니다. 이 사용자 스토리의 설명에서 볼 수 있듯이 Jimmy는 누군가가 코스를 데이터베이스에 추가하기 전에 코스의 모든 필드를 채워야 하며, 각 코스에 고유한 제목이 있어야 한다는 점을 중요하게 생각합니다.
현재는 데이터를 삭제할 수 없으므로 해당 기능도 추가해야 합니다. Jimmy는 최소한 교육 이벤트를 삭제할 수 있어야 합니다. 하지만 앱에서 데이터가 삭제되면 어떤 일이 발생해야 할까요? 이를 삭제 동작이라고 합니다.
삭제 동작을 올바르게 설정하지 않으면 데이터가 삭제되지 않아야 할 때 삭제될 위험이 있으며, 이는 Jimmy에게 큰 문제를 일으킬 수 있습니다. 삭제 동작을 올바르게 설정하지 않을 경우의 또 다른 위험은 데이터가 삭제되면 이 데이터에 연결된 다른 개체가 무의미해진다는 것입니다. 이 경우 데이터베이스를 깨끗하게 유지하기 위해 이러한 개체도 자동으로 삭제되어야 합니다.
다음 질문을 생각해 보세요:
사람들이 이미 등록한 교육 이벤트를 삭제할 수 있어야 하나요?
교육생이 데이터베이스에서 삭제되면 교육생의 등록은 어떻게 되나요?
이 모듈의 마지막 부분에서 삭제 동작을 살펴보겠습니다. 먼저 앱에 추가되는 데이터가 유효한지 확인하겠습니다. Mendix로 데이터의 유효성을 검사하는 방법에는 세 가지가 있습니다:
도메인 모델의 유효성 검사 규칙
도메인 모델에 유효성 검사를 추가하면 해당 객체를 사용하는 프로젝트의 모든 컴포넌트, 페이지 또는 마이크로플로우가 유효성 검사를 통과해야 합니다. 여기에서 유효성 검사를 적용하면 모든 곳에 적용됩니다.
마이크로플로우
마이크로플로우에 유효성 검사를 추가하면 모든 사람이 유효성 검사 규칙에 더 쉽게 액세스하고 볼 수 있습니다. 또한 이러한 규칙은 기본 도메인 모델에 영향을 주지 않고 쉽게 업데이트할 수 있습니다.
페이지
페이지에 유효성 검사를 추가하면 해당 페이지에만 적용되며 다른 곳에는 적용되지 않습니다. 또한 필드당 하나의 유효성 검사 규칙만 가질 수 있습니다. 페이지 유효성 검사를 사용하는 경우 코스 제목은 필수 항목이면서 고유한 항목일 수 없습니다.
8.2 유효성 검사 규칙
지난 강의에서는 교육생의 이메일 주소가 유효하지 않은 상황을 고려했습니다. 주소가 잘못 입력되거나 성이 비어 있는 등의 다른 상황도 발생할 수 있습니다. Mendix를 사용하면 이러한 간단한 실수를 어떻게 방지할 수 있을까요? 바로 유효성 검사 규칙입니다.
유효성 검사 규칙 추가하기
유효성 검사 규칙은 개체가 데이터베이스에 저장되기 전에 충족되어야 하는 조건입니다. 유효성 검사 규칙은 도메인 모델의 속성에 적용됩니다. 유효성 검사 규칙을 추가할 때 유효성 검사 규칙이 일치하지 않을 때 표시되는 사용자 지정 오류 메시지를 입력할 수도 있습니다.
유효성 검사 규칙의 유형
도메인 모델에서 속성에 적용할 수 있는 유효성 검사 규칙에는 여러 가지 유형이 있습니다:
| 유형 | 설 |
| Required | 속성에는 값이 있어야 합니다. 비어 있으면 안 됩니다. 예를 들면 다음과 같습니다: 코스 설명은 비워 둘 수 없습니다. |
| Unique | 속성은 동일한 엔티티의 다른 모든 객체에 있는 이 속성의 값과 비교하여 고유한 값을 가져야 합니다. 예를 들면 다음과 같습니다: 한 코스는 데이터베이스에 이미 있는 다른 코스와 동일한 제목을 가질 수 없습니다. |
| Equals | 속성 값은 지정된 값과 같거나 동일한 객체의 다른 속성 값과 같아야 합니다. 예를 들어 비밀번호를 변경하는 양식이 있는데 새 비밀번호를 두 번 입력해야 하는 경우. |
| Range | 속성 값은 지정된 값 사이 또는 동일한 객체의 다른 속성 값 사이에 있어야 합니다. 예를 들면 다음과 같습니다: 코스 기간은 최소 1일에서 최대 10일이어야 합니다. |
| Regular expression | 속성은 정규식과 일치해야 합니다. 정규식은 패턴 인식을 사용하여 값을 확인합니다. 예를 들어 이메일 주소는 유효한 이메일 주소(something@something.com)여야 합니다. |
| Maximum length | 속성은 지정된 문자 수 이하로만 사용할 수 있습니다. 예를 들어 미국 우편 번호는 항상 5자로 구성되므로 누군가 우편 번호를 입력하면 해당 값의 최대 길이는 5자입니다. |
오브젝트가 유효하지 않으면 어떻게 되나요?
그렇다면 오브젝트가 유효성 검사를 통과하지 못하면 어떻게 될까요? 앱에서 유효성 검사가 트리거된 위치에 따라 세 가지 결과가 발생할 수 있습니다:
속성에 대한 입력 위젯이 있는 페이지에서: 최종 사용자가 속성에 대한 입력 위젯이 있는 페이지를 사용하여 데이터베이스에 개체를 추가하려고 시도했지만 올바르게 입력하지 않았습니다. 이 경우 입력 위젯 아래에 오류 메시지가 표시됩니다.
속성에 대한 입력 위젯이 없는 페이지에서: 최종 사용자가 데이터베이스에 개체를 추가하려고 했지만 검사를 통과하지 못한 속성은 최종 사용자가 현재 보고 있는 페이지에 입력 위젯이 없습니다. 오류 메시지와 함께 팝업 메시지가 나타납니다.
마이크로플로우에서: 마이크로플로우가 개체를 데이터베이스에 커밋하려고 시도하지만 유효성 검사에 의해 중지됩니다. 이 경우 로그에 오류 메시지가 나타납니다.
위의 각 경우에는 개체가 데이터베이스에 커밋되지 않으므로 불완전하거나 잘못된 정보가 데이터베이스에 저장되는 것을 방지할 수 있습니다.
8.2.1 도메인 모델에 유효성 검사 규칙 추가하기
도메인 모델에 유효성 검사 규칙을 추가할 시간입니다! 다음 스토리를 실행 중으로 설정합니다: 관리자로서 저는 데이터베이스가 지저분해지지 않도록 데이터가 유효하고 일관성 있게 유지되기를 원합니다.
Jimmy는 LearnNow 앱에 대해 다음과 같은 유효성 검사 규칙을 생각해 냈습니다:
| ENTITY | ATTRIBUTE | VALIDATION RULE |
| COURSE | Title | Required, Unique |
| Duration | Required, >= 1 and <= 12 | |
| Price | Required, >= 300 | |
| Description | Required | |
| LOCATION | Name | Required, Unique |
| Address | Required | |
| TEACHER | Name | Required |
| EmailAddress | Required, Email format | |
| TRAINEE | Name | Required |
| Address | Required | |
| EmailAddress | Required, Email format | |
| TRAINING EVENT | StartDate | Required |
| Trainer selection | Required | |
| Course selection | Required | |
| Location selection | Required |
코스 엔티티에 첫 번째 유효성 검사 규칙을 추가하는 것으로 시작해 보겠습니다! 유효성 검사 규칙은 제목이 필수입니다. 즉, 제목이 있는 경우에만 코스를 데이터베이스에 저장할 수 있습니다!
도메인 모델을 열고 코스 엔티티를 두 번 클릭하여 해당 속성을 엽니다.
세 번째 탭은 유효성 검사 규칙 탭입니다. 이를 클릭합니다.
첫 번째 유효성 검사 규칙인 제목은 비어 있을 수 없다는 규칙을 추가해 보겠습니다. 새로 만들기를 클릭하여 새 유효성 검사 규칙을 만듭니다.
유효성 검사 규칙을 만들 속성이므로 속성을 제목으로 설정합니다. 규칙이 이미 필수로 설정되어 있으므로 그대로 유지해도 됩니다.
오류 메시지 텍스트 영역에 명확한 오류 메시지를 입력합니다.
완료했으면 확인을 클릭합니다.
두 번째 유효성 검사 규칙에 따르면 제목도 고유해야 합니다. 즉, 동일한 제목이 데이터베이스에 이미 있을 수 없습니다. 이 두 번째 유효성 검사 규칙을 제목 속성에 추가하려면 새 유효성 검사 규칙을 만들어야 합니다.
새로 만들기를 클릭하여 제목 속성에 두 번째 유효성 검사 규칙을 추가합니다.
모든 유효성 검사 규칙을 코스 엔티티에 추가할 때까지 계속 진행합니다. 다음은 이러한 규칙에 대한 개요입니다:
| Course | Title | Required, Unique |
| Duration | Required, >= 1 and <= 10 | |
| Price | Required, >= 300 | |
| Description | Required |
위치 엔티티에도 다음 유효성 검사 규칙을 추가합니다.
| Location | Name | Required, Unique |
| Address | Required |
8.3 정규 표현식
이제 교사와 연수생은 조금 더 까다롭습니다. 시스템에 추가된 이메일 주소가 유효한지 확인해야 하기 때문입니다. 이 작업은 정규 표현식을 사용하여 수행할 수 있습니다. 정규식은 검색 패턴을 정의하는 문자 시퀀스입니다. 은행 계좌 번호나 이메일 주소가 좋은 예입니다. 이메일 주소를 좀 더 자세히 살펴봅시다. 이메일 주소에는 something@something.ext 같은 패턴이 있습니다. 즉, 몇 개의 문자, @ 기호, 몇 개의 문자, 점(.), 확장자 순으로 이어집니다. 정규식은 입력된 이메일 주소가 이 패턴과 일치하는지 여부를 확인할 수 있습니다. 패턴에 맞지 않는 것(예: something$ext)은 유효한 이메일 주소로 전달되지 않습니다.
Tip
정규식을 작성하는 방법을 몰라도 상관없지만, 꽤 어려울 수 있습니다. 자주 사용하는 검색 엔진에서 정규식을 검색한 다음 유효성을 검사하려는 항목을 찾으면 됩니다. Regex 은 Regular Expression의 약자입니다. 예를 들어 Regex Email. 로 씁니다.
더 자세히 알고 싶으시다면 언제든지 문서를 참조하세요.
https://docs.mendix.com/refguide/regular-expressions/#1-introduction
Regular Expressions
1 Introduction A regular expression resource document is used in the validation rules of an entity to describe a set of criteria that a string must match. A regular expression has the properties described below. 2 Common 2.1 Name The name can be used to re
docs.mendix.com
8.3.1 정규식 추가
이제 이메일 주소 유효성 검사 규칙을 추가해 보겠습니다!
교사 엔티티의 속성을 열고 유효성 검사 규칙 탭으로 이동합니다.
EmailAddress 속성에 대한 새 유효성 검사 규칙을 만듭니다.
규칙을 정규식으로 설정합니다.
선택을 클릭하여 정규식을 선택합니다. 아직 앱에 정규식이 없으므로 새로 만들기를 클릭하여 지금 바로 만들 수 있습니다.
이름을 Email로 지정하고 확인을 클릭합니다. 구성 창이 열립니다.
아래 정규식을 복사합니다(https://regexr.com/3e48o 참조). 정규 표현식을 표현식 텍스트 영역에 추가합니다. 자주 사용하는 검색 엔진을 사용하여 정규식을 찾을 수 있습니다!
(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])
다른 개발자가 정규 표현식의 기능을 이해할 수 있도록 문서 텍스트 영역에 메모를 추가하세요. 정규 표현식이 검사하는 항목(또는 검사하지 않는 항목)과 온라인에서 찾은 경우 어디서 찾았는지 설명해야 합니다.
교사와 연수생에 대한 모든 유효성 검사 규칙을 만들 때까지 계속합니다. 다음은 유효성 검사 규칙에 대한 개요입니다:
| TEACHER | Name | Required |
| EmailAddress | Required, Email format | |
| TRAINEE | Name | Required |
| Address | Required | |
| EmailAddress | Required, Email format |
도메인 모델을 살펴보세요. 속성 이름 뒤에 녹색 확인 표시가 표시되어 있나요? 이는 속성에 하나 이상의 유효성 검사 규칙이 적용되었음을 나타냅니다.
왜 아직 TrainingEvent 엔티티에 유효성 검사 규칙을 추가할 필요가 없었는지 궁금하실 것입니다. 다음 강의로 이동하여 그 이유를 알아보세요.
8.4 마이크로플로우에서의 유효성 검사
이전 강의에서 도메인 모델에 유효성 검사 규칙을 추가했습니다. 다음 엔티티에 대해 이 작업을 수행했습니다: 코스, 위치, 교사, 연수생. TrainingEvent에도 유효성 검사 규칙이 필요했지만 도메인 모델에 추가하지 않았습니다. 이러한 유효성 검사 규칙을 다시 살펴보겠습니다:
| ENTITY | ATTRIBUTE | VALIDATION RULE |
| TRAININGEVENT | StartDate | Required |
| Trainer selection | Required | |
| Course selection | Required | |
| Location selection | Required |
여기에서 네 가지 유효성 검사가 필요하다는 것을 알 수 있습니다. 그 중 하나는 속성(StartDate)이고 나머지 세 개는 연결입니다. 속성과 달리 연결은 도메인 모델에서 유효성을 검사할 수 없습니다. 페이지 또는 마이크로플로우에서 이 작업을 수행해야 합니다. 여기서는 마이크로플로우가 선호되는 옵션입니다. 페이지 유효성 검사보다 미래 지향적이며 앱을 더 쉽게 확장할 수 있기 때문입니다. 마이크로플로는 여러 시나리오에서 재사용할 수 있지만 페이지 유효성 검사는 새 페이지가 유효성 검사 중인 데이터에 액세스할 때마다 반복적으로 구성해야 합니다. 또한 교육 이벤트와 관련된 모든 페이지가 동일한 방식으로 또는 전혀 유효성 검사를 수행하도록 보장할 수 있는 방법은 없습니다. 마이크로플로우를 사용하면 이 프로세스를 훨씬 쉽게 제어할 수 있습니다.
왜 도메인 모델에 시작 날짜 유효성 검사를 더 일찍 추가하지 않았는지 궁금할 수도 있습니다. 이는 최종 사용자가 자신의 작업을 한 번만 유효성 검사하기를 기대하기 때문입니다. 예를 들어 특정 엔터티에 대해 도메인 모델에서 일부 정보를 유효성 검사하고 마이크로플로우에서 일부 정보를 유효성 검사한다고 가정하면 최종 사용자는 서로 다른 시점에 유효성 검사 메시지를 받게 됩니다. 이는 최종 사용자에게 매우 혼란스럽고 실망스러운 일입니다. 따라서 마이크로플로우에서 엔티티의 한 멤버(속성 또는 연결)의 유효성을 검사하는 순간 해당 마이크로플로우의 다른 모든 유효성 검사를 동시에 수행하세요.
이제 유효성 검사 프로세스를 위해 마이크로플로우를 구축해야 한다는 것을 알았으니, 이 마이크로플로우를 언제 트리거해야 하는지 알아낼 차례입니다. 두 가지 옵션이 있습니다:
도메인 모델의 TrainingEvent 엔티티에 있는 커밋 전 개체 이벤트 처리기.
TrainingEvent_NewEdit 페이지의 사용자 지정 저장 버튼.
스스로에게 물어봐야 할 질문은 이것입니다: 데이터베이스(객체 이벤트 핸들러)로 이동하기 전에 또는 최종 사용자가 TrainingEvent 내부의 정보와 상호 작용할 때(사용자 지정 저장 버튼) TrainingEvent의 유효성을 검사해야 하는가?
가장 쉬운 해결책은 객체 이벤트 핸들러를 만드는 것입니다. 하지만 이전 모듈에서 TrainingEvent에 총 등록 수를 저장하는 기능을 만들었습니다. 이 마이크로플로우(ACO_ADE_Registration_SetTotalNumberOfRegistrations)는 TrainingEvent 객체의 커밋을 수행합니다. 이 커밋은 객체 이벤트 핸들러로 추가하는 경우 유효성 검사 프로세스를 트리거합니다. 이 경우 총 등록 수를 저장할 때 TrainingEvent의 유효성을 검사할 필요가 없으므로 바람직하지 않습니다. 따라서 데이터베이스에 저장하기 전에 TrainingEvent의 유효성을 검사하는 사용자 지정 저장 버튼을 TrainingEvent_NewEdit 페이지에 생성하는 것이 좋습니다.
작업을 시작하기 전에 원하는 최종 목표인 각 입력 위젯 아래에 특정 유효성 검사 피드백 메시지가 있는 TrainingEvent_NewEdit 페이지를 살펴봅시다. 또한 모든 유효성 검사 피드백 메시지가 최종 사용자에게 한 번에 표시됩니다.
자세히 살펴보겠습니다:
시작 날짜, 코스, 위치 및 교사는 필수 필드가 되어야 합니다. 비워두면 안 됩니다. 종료 날짜는 자동으로 채워지므로 걱정할 필요가 없습니다.
각 입력 위젯(필드)은 입력 위젯 아래에 표시되는 자체 유효성 검사 피드백 메시지를 받아야 합니다. 이렇게 하면 사용자는 어떤 필드에 어떤 정보를 입력해야 하는지 알 수 있습니다.
이러한 모든 유효성 검사 피드백 메시지는 최종 사용자에게 한 번에 표시되어야 여러 차례의 피드백 메시지로 인해 좌절하지 않습니다.
TrainingEvent가 모든 유효성 검사를 통과한 경우에만 데이터베이스에 커밋할 수 있습니다(사용자는 교육 이벤트를 저장할 수 있음).
트레이닝 이벤트가 커밋(저장)된 후에는 페이지를 닫아야 합니다. 그러면 앱이 TrainingEvent_Overview 페이지로 돌아갑니다. 그렇지 않으면 최종 사용자는 교육 이벤트가 저장되지 않았다고 생각하여 혼란스러워할 것입니다! 또한 개요 페이지를 새로 고쳐야 새 TrainingEvent 정보를 표시할 수 있습니다.
이 모든 작업을 완료하려면 저장 버튼에서 트리거될 마이크로플로우를 만들고, 유효성 검사를 추가하고, 피드백 메시지가 표시되는지 확인해야 합니다! 다음 과제에서 이 모든 작업을 수행하는 방법을 확인할 수 있습니다!
8.4.1 유효성 검사 마이크로플로우 만들기
먼저 저장 버튼에서 트리거될 마이크로플로우를 만들어야 합니다:
TrainingEvent_NewEdit 페이지를 엽니다. 이 페이지는 TrainingEvent 엔티티에 연결된 데이터 보기가 있는 페이지입니다. 데이터 뷰의 바닥글에는 기본 저장 및 취소 버튼이 있습니다. 아래에 표시된 저장 버튼을 마우스 오른쪽 버튼으로 클릭하고 클릭 동작에서 편집을 클릭합니다.
클릭 시 변경 사항 저장을 마이크로플로우 호출로 변경합니다.
필요한 마이크로플로우가 아직 존재하지 않으므로 다음 화면에서 새로 만들기를 클릭합니다. 이 마이크로플로우의 좋은 이름은 ACT_TrainingEvent_SaveValidate입니다. 마이크로 플로우 생성을 완료하고 엽니다.
마이크로플로우에는 TrainingEvent라는 입력 매개변수가 있습니다. 이것은 데이터베이스에 저장될 TrainingEvent입니다. 하지만 데이터베이스에 커밋되기 전에 먼저 유효성 검사를 통과해야 합니다!
항상 그렇듯이 최종 결과부터 시작하세요. 즉, TrainingEvent를 커밋하고 페이지를 닫는 것입니다. 이 두 가지 활동을 마이크로플로우에 추가하세요. 마이크로플로우에서 수행된 검사가 완료되면 관련 메시지가 표시되도록 하려면 클라이언트에서 새로 고침을 예로 설정하는 것을 잊지 마세요.
마이크로 플로우의 모습은 다음과 같습니다:
지금까지 저장 버튼이 간단한 마이크로플로우를 트리거하도록 만들었습니다. 생성한 마이크로플로우에는 아직 유효성 검사 검사가 포함되어 있지 않습니다. 다음 과제에서 이러한 검사를 구축하는 방법을 알아보세요!
8.4.2 유효성 검사 빌드
의사 결정을 사용하여 검사를 빌드하는 방법을 이미 알고 계실 것입니다. 다음 마이크로플로우 표현식을 사용하여 하나의 의사 결정에서 모든 필드를 확인할 수 있습니다:
$TrainingEvent/StartDate != empty AND
$TrainingEvent/MyFirstModule.TrainingEvent_Course != empty AND
$TrainingEvent/MyFirstModule.TrainingEvent_Location != empty AND
$TrainingEvent/MyFirstModule.TrainingEvent_Teacher != empty
하지만 이 접근 방식에는 두 가지 문제가 있습니다:
마이크로플로우의 가독성에는 아무런 도움이 되지 않습니다. 마이크로플로우가 정확히 무엇을 하는지 확인하기 위해 결정을 열어야 하기 때문에 실제로 해석하기가 더 어려워집니다. 또한 몇 줄의 마이크로 플로우 표현을 읽고 해석해야 합니다. 이것은 피해야 할 일입니다.
하나의 의사 결정에서 모든 검사를 수행하면 특정 입력 위젯 아래에 유효성 검사 피드백 메시지를 추가하는 것이 불가능해집니다. 어떤 필드가 유효성 검사를 통과했는지, 통과하지 않았는지 구분할 수 없기 때문입니다. 이를 위해서는 입력 위젯당 하나의 의사 결정을 작성해야 합니다.
따라서 대신 할 수 있는 일은 다음과 같습니다:
시작 날짜, 코스, 위치 및 교사에 대한 모든 필수 확인 사항을 별도의 의사 결정 활동에서 작성합니다.
명확한 캡션을 추가하고 '행복한 경로'를 따르도록 하세요. 즉, 나가는 진정한 흐름은 커밋 활동으로 이어지는 흐름이고 거짓 흐름은 종료 이벤트로 이어지는 흐름인지 확인하세요.
이제 마이크로플로우의 모습은 다음과 같습니다:
다음 강의에서는 이러한 종료 이벤트를 피드백 메시지로 변경하는 방법을 살펴보겠습니다.
8.4.3 유효성 검사 피드백 메시지 추가
다음 단계는 유효성 검사 피드백 메시지를 추가하는 것입니다. 이 메시지는 마이크로플로우가 잘못된 경로로 이동하는 경우 사용자에게 유효성 검사를 통과하지 못했음을 알려줍니다. 마이크로플로우에 유효성 검사 피드백 메시지를 추가하려면 다음과 같이 하세요:
첫 번째 잘못된 흐름(시작 날짜를 확인하는 결정에서 나오는 흐름)에 유효성 검사 피드백 활동을 추가합니다.
해당 활동을 두 번 클릭하면 다음 팝업이 나타납니다:
변수는 유효성을 검사하려는 객체(이 경우 TrainingEvent)입니다.
Member는 유효성 검사 메시지를 아래에 표시하려는 입력 위젯입니다. 이 경우 StartDate.
템플릿은 사용자에게 표시될 메시지입니다. 사용자가 수행해야 하는 작업을 이해하는 데 도움이 되는 메시지를 입력합니다. 이 경우 "시작 날짜를 선택하세요"입니다.
확인을 클릭합니다.
이전 단계를 반복하여 나가는 각 잘못된 흐름에 유효성 검사 피드백 활동을 추가하고 올바르게 설정합니다.
이 과제가 끝나면 마이크로플로우가 다음과 같이 보일 것입니다:
이 시점에서 사용자는 여러 차례의 피드백을 받게 됩니다. 검사가 통과하지 못할 때마다 마이크로플로우가 잘못된 경로로 이동하고 앱이 종료 이벤트를 통해 마이크로플로우를 종료하기 때문입니다. 다음 검사에 도달하지 못합니다! 이 동작은 사용자에게 매우 불쾌감을 줍니다. 모든 확인이 한 번에 실행되고 사용자가 교육 이벤트를 저장하기 위해 수행해야 할 작업을 즉시 확인할 수 있도록 해야 합니다. 마이크로플로우가 잘못된 경로로 진행되더라도 모든 확인을 통과할 수 있는 방법이 필요합니다. 다음 과제에서 이를 수행하는 방법에 대해 자세히 알아보세요!
8.4.4 여러 흐름 병합
의사 결정에는 하나의 수신 흐름만 있을 수 있습니다. 즉, 잘못된 흐름을 바로 다음 의사 결정으로 이어지게 할 수는 없습니다. 하지만 이를 위해 사용할 수 있는 구성 요소인 병합이 있습니다.
병합은 마이크로플로우에서 빨간색 다이아몬드 모양의 구성 요소입니다. 병합은 여러 가지 분기에서 하나의 단일 흐름으로 돌아가는 데 사용됩니다.
마이크로 플로우에 수행해야 할 작업은 다음과 같습니다:
각 잘못된 경로의 하단에 있는 종료 이벤트를 삭제합니다.
각 결정 후에 병합을 추가합니다.
다음 이미지에서와 같이 유효성 검사 피드백 활동에서 병합으로 흐름을 드래그합니다.
현재 상태에서 마이크로플로우에 어떤 문제가 있는지 예측할 수 있나요? 확실하지 않은 경우 앱을 실행하여 기능을 테스트해 보세요.
현재 솔루션의 문제점은 마이크로플로우가 모든 검사를 거쳤음에도 불구하고 유효하지 않은 TrainingEvent를 여전히 커밋한다는 것입니다! 오브젝트가 유효하지 않은 경우 마지막에 커밋하지 않고 모든 피드백 메시지를 한 번에 다시 표시하는 하나의 흐름을 계속 유지하려면 어떻게 해야 할까요? 마이크로플로우가 프로세스 어딘가에서 잘못된 경로로 이동했는지 기록할 수 있는 방법이 필요합니다. 플래그를 사용하면 이 작업을 수행할 수 있습니다. 플래그는 참/거짓 조건을 나타내는 용어입니다. 플래그는 기차가 진행해도 안전한지 여부를 알려주는 철도 기관사와 같이 진행/중지 상태를 나타냅니다.
이 참/거짓 플래그는 여러분이 이미 알고 있는 속성 유형과 매우 비슷하게 들리지 않나요? 맞습니다, 부울 값입니다! 그리고 플래그는 이 부울 값을 저장하는 데 사용할 수 있는 변수와 같습니다.
과제를 계속 진행하여 마이크로플로우에 플래그를 추가해 보겠습니다! 이 플래그의 시작 값은 참입니다. 이는 최종 사용자가 양식의 모든 필드를 채우는 것으로 예상되는 작업을 수행했다고 가정하기 때문입니다. 최종 사용자가 그렇게 하지 않아 마이크로플로우가 잘못된 경로로 이동하는 경우 부울 변수 값은 거짓으로 설정됩니다.
시작 이벤트 바로 뒤에 마이크로플로우의 시작 부분에 활동을 배치합니다.
작업 유형을 만들기 변수로 설정하고 값을 true로 설정한 다음 변수 이름을 ValidTrainingEvent와 같은 의미 있는 이름으로 변경합니다.
네 가지 결정 모두에 대한 거짓 경로에 활동을 배치합니다.
새로 만든 네 가지 활동 모두에 대해 위의 세 단계를 반복합니다.
활동 유형을 변수 변경으로 설정합니다.
ValidTrainingEvent 변수를 선택합니다.
값을 false로 설정합니다.
변수 변경 활동을 플로우에 끌어다 놓는 대신 MxAssist 로직 봇을 사용할 수 있다는 사실을 알고 계셨나요? 유효성 검사 피드백 활동 뒤에 파란색 점이 보이시나요? 지금 바로 사용해 보세요!
이 파란색 점을 누르면 몇 가지 제안이 표시됩니다. Change ValidTrainingEvent 을 선택합니다. 쉽죠?
유효성 검사가 끝나면 마이크로플로우가 커밋을 수행하기 직전에 최종 결정을 내립니다. 이 결정은 부울 변수 값이 여전히 참인지 여부를 확인합니다.
그렇다면 TrainingEvent 개체가 모든 유효성 검사를 통과하고 커밋할 수 있습니다.
그렇지 않은 경우 하나 이상의 검사가 통과하지 못했음을 의미하며, 개체를 커밋하지 않고 마이크로플로우를 종료해야 합니다. 이 시점에서 최종 사용자에게 유효성 검사 피드백 메시지가 표시됩니다.
이 과제가 끝나면 마이크로플로우의 모습은 다음과 같습니다:
앱을 실행하고 기능을 테스트합니다. 예상대로 작동하나요? 그렇지 않은 경우 이 모듈을 다시 살펴보고 지침을 단계별로 따랐는지 확인하세요. 그렇다면 작업을 팀 서버에 커밋하고 스토리를 완료로 설정합니다.
8.5 객체 삭제하기
지금까지 이 모듈에서는 데이터베이스에 입력되는 데이터가 일관되고 유효한지 확인하는 방법을 배웠습니다. 마찬가지로 데이터베이스에서 삭제되는 데이터를 제어할 수 있는지 확인해야 합니다!
개발자 포털에서 다음 사용자 스토리를 실행으로 설정합니다: 관리자로서 등록이 없는 교육 이벤트를 삭제하여 사람들이 이미 참가비를 지불한 교육 이벤트를 실수로 삭제하지 않도록 하고 싶습니다.
이 사용자 스토리에 따르면 Jimmy는 교육 이벤트를 삭제할 수 있기를 원하지만, 아직 해당 이벤트에 등록한 사람이 없는 경우에만 삭제할 수 있기를 원합니다. 그렇지 않으면 교육생들이 이미 비용을 지불하고 특정 교육 이벤트에 참석했는데 갑자기 이벤트가 취소되는 경우 불쾌한 표정을 지을 수 있습니다. 또는 교육생이 이벤트에 참석했지만 이벤트가 취소되었기 때문에 당연히 교육이 없을 수도 있습니다.
따라서 사용자가 개체를 삭제하려고 할 때 연결된 개체가 있는 경우 앱에서 이를 방지해야 합니다. 다음 이미지는 결정해야 할 사항을 보여주는 예시입니다:
첫 번째 섹션인 다중성에서는 연결이 어떤 유형인지 보여줍니다.
다음 두 옵션은 삭제 동작 설정을 보여줍니다. 즉, 연결된 개체 중 하나를 삭제할 때 어떤 일이 발생해야 하는지를 보여줍니다. 이 예제에서는 'TrainingEvent' 개체를 삭제하려는 경우 세 가지 옵션이 있습니다:
'등록' 개체를 유지합니다. 즉, 교육 이벤트를 삭제할 수 있으며 해당 이벤트에 속한 모든 등록은 시스템에 유지됩니다. 이를 사전 정의 없음이라고도 하며 삭제 동작의 기본 설정입니다.
'등록' 개체도 삭제합니다. 즉, 교육 이벤트와 해당 이벤트에 속한 모든 등록이 시스템에서 삭제됩니다. 이러한 유형의 삭제 동작을 계단식 삭제라고 합니다.
'등록' 객체와 연결되어 있지 않은 경우에만 'TrainingEvent' 객체를 삭제합니다. 즉, 교육 이벤트는 아직 연결된 등록이 없는 경우에만 삭제할 수 있습니다. 이러한 유형의 삭제 동작을 삭제 방지라고 합니다. 이 옵션을 선택하면 최종 사용자에게 오류 메시지를 표시하여 특정 객체를 삭제할 수 없는 이유를 알려주는 옵션도 제공됩니다.
팁
앱에서 개체를 삭제하려고 할 때 시스템 오류 메시지가 표시되는 경우 도메인 모델을 살펴보세요. 아마도 어딘가에서 삭제 방지가 트리거되어 사용자 지정 오류 메시지를 작성하는 것을 잊어버렸을 수 있습니다.
다음 과제에서는 지미에게 교육 이벤트를 삭제할 수 있는 기능을 제공하겠습니다. 시작해 보겠습니다!
8.5.1 삭제 버튼 추가
먼저 삭제 버튼이 있는지 확인하겠습니다. Jimmy는 교육 이벤트를 삭제할 수 있기를 원하므로 TrainingEvent_Overview 페이지에 삭제 버튼을 추가하는 것이 좋습니다.
그렇게 하려면
멘딕스 스튜디오 프로에서 TrainingEvent_Overview 페이지를 엽니다.
도구 상자에서 삭제 버튼을 찾습니다.
목록 보기 항목의 Glyphicon '메뉴 오른쪽' 아이콘 오른쪽에 배치합니다. 다음 이미지에서 강조 표시된 영역의 Glyphicon 아이콘 아래로 끌어다 놓으면 됩니다.
이제 버튼이 기존 버튼 옆에 배치됩니다. 버튼을 두 번 클릭하여 속성을 엽니다. 캡션을 비우고 휴지통 아이콘을 선택합니다. 버튼 스타일을 위험으로 설정하여 버튼이 빨간색으로 표시되도록 합니다.
페이지 닫기를 아니요로 설정하면 교육 이벤트를 삭제할 때 TrainingEvent 개요 페이지가 계속 열려 있습니다.
확인을 클릭합니다.
잘 완료되었습니다! 교육 이벤트를 삭제하는 삭제 버튼을 설정했습니다. 다음 과제를 계속 진행하여 삭제 동작을 구성합니다. 일부 참가자가 이미 해당 이벤트에 등록한 경우 교육 이벤트가 삭제되지 않도록 할 수 있습니다!
8.5.2 삭제 동작을 추가합니다: 삭제 방지
멋지네요, 버튼이 완성되었습니다! 이제 삭제 동작을 설정할 차례입니다. Jimmy는 아직 연결된 등록이 없는 경우에만 교육 이벤트가 삭제되기를 원합니다.
삭제 동작은 도메인 모델에서 관리하므로 도메인 모델을 엽니다.
Registration_TrainingEvent 연결을 두 번 클릭하여 해당 속성을 엽니다. 다음과 같은 창이 열립니다:
'교육 이벤트 삭제 시'에서 '등록' 객체와 연결되지 않은 경우에만 '교육 이벤트' 객체 삭제를 선택합니다. 다른 옵션은 기본적으로 설정된 대로 둡니다.
'등록' 객체와 연결되지 않은 경우에만 'TrainingEvent' 객체 삭제 아래에 표시되는 텍스트 영역에 오류 메시지를 추가합니다. 이 오류 메시지는 삭제가 방지될 때 최종 사용자에게 표시됩니다. 아마도 다음과 같을 것입니다: 죄송합니다. 이 교육 이벤트는 삭제할 수 없습니다. 사람들이 이미 등록했습니다!
확인을 클릭합니다.
모임 주위에 파란색 테두리가 표시되어 있나요? 이 연결에 삭제 방지 기능이 적용되었음을 알려줍니다.
축하합니다! 지미는 이제 예정된 트레이닝 이벤트를 취소할 수 있습니다. 지미가 정말 기뻐할 것입니다! 새로 만든 기능을 팀 서버에 커밋하고 스토리를 완료로 설정합니다. 커밋하는 동안 스토리를 관련 사용자 스토리로 선택하는 것을 잊지 마세요!
8.6 계단식 삭제
지미가 시스템에서 삭제할 수 있기를 원하는 또 다른 항목은 트레이너와 해당 트레이너의 정보입니다. 교육생이 삭제되면 해당 교육생이 속한 모든 등록도 삭제되어야 합니다. 이러한 유형의 삭제 동작을 계단식 삭제라고 합니다. 즉, 하나의 개체가 삭제되면 연결된 모든 개체도 자동으로 삭제됩니다. 아래 이미지와 같이 연결 주위에 표시되는 빨간색 테두리로 연결에 계단식 삭제가 적용되었는지 확인할 수 있습니다.
8.6.1 계단식 삭제를 사용하여 개체 삭제
이전 과제에서와 동일한 접근 방식을 사용하여 이 기능을 혼자서 완전히 구축할 수 있을까요? 수행해야 할 단계는 다음과 같습니다:
다음 사용자 스토리를 실행 중으로 설정합니다: 관리자로서 저는 교육생 및 해당 교육생의 모든 등록을 삭제하여 더 이상 LearnNow 학생이 되고 싶지 않은 경우 시스템에서 제거할 수 있기를 원합니다.
Trainee_Overview 페이지에 삭제 버튼을 추가합니다. 버튼에 멋진 아이콘과 색상을 지정하여 눈에 잘 띄도록 합니다. 이 단계에 대한 도움이 필요한 경우 '8.5.1 삭제 버튼 추가하기' 강의를 참조할 수 있습니다. 버튼의 최종 모습은 다음과 같습니다:
도메인 모델에서 등록_트레이너 연결에 삭제 동작을 추가합니다. 이 단계에 대한 도움이 필요한 경우 '8.5.2 삭제 동작 추가하기' 강의를 참조하세요: 삭제 방지' 강의를 참조하세요. 이번에는 '등록' 개체 삭제도 선택해야 한다는 점에 유의하세요!
솔루션을 실행하고 테스트해 보세요! 만족스러우면 팀 서버에 작업을 커밋하고 스토리를 완료로 설정하세요!
축하합니다! 데이터베이스의 데이터가 항상 일관되고 유효한지 확인하는 데 성공했습니다! 다음 강의에서는 앱의 보안을 설정하는 방법을 배우게 됩니다. 이렇게 하면 데이터가 정확할 뿐만 아니라 안전할 것입니다!
요약
축하합니다! 이제 사용자 친화적이고 효과적일 뿐만 아니라 데이터베이스에 들어오고 나가는 데이터가 일관되고 유효한지 확인할 수 있는 앱을 갖게 되었습니다!
이번 강의에서는 다음과 같은 내용을 배웠습니다:
유효성 검사 규칙이란 무엇이며 도메인 모델에 추가하는 방법
정규 표현식이란 무엇이며 어떻게 사용하는가?
유효성 검사 마이크로플로우를 만드는 방법
마이크로플로우를 모델링할 때 MxAssist 로직 봇을 사용하는 방법
사용자에게 유용한 피드백 메시지를 제공하는 방법
사용자가 삭제해서는 안 되는 데이터를 삭제하지 못하도록 방지하는 방법
더 이상 필요하지 않은 데이터의 삭제를 자동화하는 방법
다음 강의에서는 앱의 보안을 설정하는 방법을 배우게 됩니다. 이렇게 하면 데이터가 정확할 뿐만 아니라 안전해질 것입니다!
리소스 탭에서 모듈 8의 솔루션이 포함된 mpk를 찾을 수 있습니다.
https://academy.mendix.com/link/modules/95/lectures/815/8.7-Summary
Mendix
academy.mendix.com
