mondegreen

멘딕스 스튜디오 프로에서는 소스의 변경사항을 어떻게 알 수 있을까?내가 개발을 진행하며 확인하는 부분은 주로 아래 두 곳이다.1. 아래 사진 첫번째 탭 제목인 changes 이다. - pull을 받거나 merge changes here을 통해 상위 브랜치의 소스를 머지받았을 때 그리고 내가 작업을 해서 변경사항이 발생했을 때 page, microflow, nanoflow, contants 등 각 파일 기준으로 변경된 카운트를 확인할 수 있다.2. 두번째로는 오른쪽 하단의 아래화살표 옆 숫자이다.- 동일한 브랜치를 여러명이 쓰고 있을 때, 또는 상위 브랜치일 때 최신화하는 경우이다.그런데 과연 이 두 가지 항목에서 변경된 사항이 없을 때, 정말 변경사항이 없는 걸까그렇지 않다.왼쪽 상단의 주 메뉴 중 ve..

[2024.07.21] 아래 내용은 내가 테스트해본 결과 알게 된 것이고 실제 개발환경에서 혹시 다른 이슈를 경험하게 된다면 글을 업데이트 하고자 한다.Mendix로 개발하는 신입 개발자로서, 본격적으로 협업을 하게 되었고 멘붕을 겪게 된 것은 바로 버전 컨트롤이었다. 인텔리제이와 같은 IDE를 활용하면 터미널을 이용해 commit이나 pull이 가능했고, git이나 git lab에서 해당 레포지토리의 브랜치들을 merge할 수 있었다.그런데 Mendix는 진짜 정말 모르겠는 것이다...  미치고 팔짝 뛸 노릇.. 아래 화면에서 보는 것처럼 하나의 개발 브랜치 내에서 commit, push, pull은 아주 간편하고 좋았다. commit의 경우에도 별도의 창이 뜨면서 커밋 메세지를 작성할 수 있도록 잘 ..

1. 멘딕스 클라이언트- 브라우저에서 실행되며 애플리케이션의 프론트엔드를 렌더링한다. - HTML, CSS, JavaScript의 조합으로 구축된다.- Mendix 런타임과 통신하여 페이지 정의 및 데이터를 검색하거나 로직 실행을 트리거한다.2. 멘딕스 런타임- 애플리케이션에 대한 런타임 환경을 제공하고 애플리케이션 모델에 정의된 로직을 실행하는 애플리케이션 서버이다.- 클라이언트와 데이터베이스 서버 사이에 위치한다.- 사용자가 정의하는 마이크로플로우 외에도 표준 로직을 보유하고 있다. - 자바 가상 머신 내에서 자바 앱으로서 실행된다.3. 데이터베이스 서버- 관계형 데이터베이스 관리 시스템이다.- 데이터베이스의 구조는 애플리케이션 모델의 도메인 모델에 의해 결정된다. (동기화)- 따라서 특정 DBMS에..

Association엔티티간 연관관계는 일대일, 일대다, 다대다로 설정될 수 있다. 이 관계에 따라 Type과 Ownership이 달라질 수 있다. 비영속성 엔티티와 영속성 엔티티가 존재할 경우 연관관계는 비영속성에서 영속성 엔티티로 연결되어야 한다.연관관계에서 Type엔티티가 일대다, 일대일의 연관관계를 갖는 경우, Type은 Reference로 설정된다. 그외의 다대다의 연관관계를 갖는 경우Type은 Reference set으로 설정된다. 반대로 이 Type을 변경할 경우 연관관계 설정도 변경된다.연관관계에서 Owner란,연관관계에서 Owner가 존재하는 이유는, 엔티티 간의 설정된 연관관계가 초기 설정과 다르게 변경될 경우 데이터베이스를 다시 빌드하지 않고 연관관계를 동적으로 쉽게 변경하기 위해 존..

엔티티란엔티티를 생성할 때 개발자가 정의하는 속성이 있다. 일반적으로 직접 모델을 설계하고 DB 스키마를 작업하며 key값이 되는 id field를 생성하기 마련인데, 멘딕스에는 별도로 생성하지 않고 있다. 이는 멘딕스가 개발자가 정의한 속성에서 System 속성(생성, 변경, owner, 변경주체)과 개체 식별자 속성을 자동으로 부여하기 때문이다. 따라서 우리가 단 한 개의 속성만 생성했다 할지라도 아래와 같이 다양한 필드를 가질 수 있는 것이다. 단, System 속성의 경우, 선택 여부에 따라 부여된다.엔티티의 종류영속성 엔티티(파란색), 비영속성 엔티티(주황색), 외부 엔티티(보라색) 이 존재한다. 비영속성 엔티티는 런타임 메모리에 저장되며 데이터베이스에 커밋되지 않는다. 다른 애플리케이션의 데이..

기존의 마이크로플로우는 특정 버튼을 클릭했을 때 작동하도록 구현함으로써 원하는 로직을 수행하도록 했었다. 하지만 사용자의 특정한 행동이 없이 데이터가 변했을 때 이러한 방식은 적용될 수 없다.이 때 사용하는 것이 객체 이벤트 핸들러이다. 이것은 이벤트가 발생할 때까지 기다렸다가 의도했던 상황 또는 상태가 되었을 때 특정 마이크로플로우를 실행하도록 할 수 있는 것이다. 마치 자바나 코틀린에서 사용했던 옵저버와 유사한 것 같다. 계속 상태를 관찰하다가 변경이 발생하면 이를 감지하고 다른 로직을 수행할 수 있게 하는 것처럼 말이다.객체에 발생할 수 있는 이벤트는 Create, Commit, Delete, Rollback 이렇게 4가지인데 이 각 이벤트의 전 또는 후에 마이크로플로우를 트리거할 수 있도록 한 것..

이 로직의 목적은 사용자가 특정 훈련과정에서 등록 버튼을 클릭할 경우, 등록 기능은 물론 해당 훈련 과정을 수강하는 등록생 수를 업데이트해서 훈련 과정 당 등록 교육생 수를 보여주고자 하는 것이다. 위와 같이 훈련 과정 당 등록 교육생 수를 보여주기 위해 엔티티에 속성을 추가해준다.훈련 과정 리스트에서 각 행의 등록 버튼을 클릭하면 위의 화면인 등록 팝업이 뜬다. 그리고 여기서 save 버튼을 기본 로직인 등록이 아닌 마이크로플로우를 트리거하도록 변경한다.위 마이크로플로우는 해당 기능을 수행하기 위한 로직인데 지금까지 로직 중 가장 복잡하다. 일단 "등록"이라는 기능은 특정 "훈련 과정"의 등록이라는 제약이 있다. 이 등록 버튼으로 넘어 온 화면에서는 어떠한 TrainingEvent인지 마이크로플로우가 ..

도메인 모델에서 엔티티를 작성하는 과정 중 속성에서 value를 선택하는 부분이 있다. calculated 또는 stored 중에 선택해야 하는데 보통은 stored로 선택해서 저장하곤 했다.둘의 차이가 무엇일까?먼저 쉽게 직관적으로 이해되는 stored부터 생각해보자. 이 설정은 데이터베이스에 저장되는 것이다. 반대로 calculated는 클라리언트나 마이크로플로우에 의해 보여질 때마다 계산되는 값이다. 상대적으로 발생 빈도가 높은 경우이다.이렇게 말해도 사실 바로 와닿지는 않는데, 멘딕스에서는 둘 중 선택할 때 기준을 "보는 횟수 VS 변경되는 횟수"를 고려하라고 말한다. 예를 들어 환율을 생각해보면 시시각각 변경되지만 매초마다 사용자나 마이크로플로우에 의해 노출되지 않는다. 따라서 환율의 경우에는 ..

멘딕스에서 데이터는 어디에, 어떻게 존재할까위의 이미지처럼 클라이언트에서 넘어오는 데이터를 일단 애플리케이션의 서버 메모리에 객체로 저장하고 있다가 ㄱ) 사용자가 이를 취소하면 삭제되고 ㄴ) 저장하면 데이터베이스에 새로운 기록으로 저장되며 메모리에 보관된 객체를 삭제한다. 참고.데이터베이스에는 존재하지 않고 메모리에만 존재하는 객체를 임시 객체라고 한다.  사용자가 선택한 StartDate부터 Course의 Duration을 더해 EndDate를 계산하려고 하는데 위와 같이 Duration을 찾을 수 없다는 메세지가 뜬다. 즉, 마이크로플로우의 범위에 없다고 말할 수 있는데 이러한 이유가 무엇일까?마이크로플로우를 작성하는데 Course는 마이크로플로우 범위에 있지 않기 때문에 참조할 수 없는 것이다. 이..

멘딕스에서 마이크로플로우를 작성하며 객체를 생성, 변경할 때 객체를 선택하고 Action부분을 설정하는 부분이 있다. 여기서 Commit은 이 객체의 변경 사항을 데이터베이스에 저장(커밋)할 것인지를 설정하는 것이다. Refresh in client는 지금 변경된 객체 내용이 클라이언트 화면에서 업데이트할 것인지를 설정하는 것이다. 위의 경우 사용자가 교육의 Course와 StartDate를 선택했을 때, 자동으로 EndDate과 화면에 업데이트 되도록 마이크로플로우를 작성하는 과정이므로 '클라이언트가 기간을 저장하지 않은' 현 상황에서는 DB에 반영되지 않아야 하며, 종료 기간을 클라이어트가 확인할 수 있게 Refresh in client는 활성화되어야 한다.