본문 바로가기

Blog/WYSIWYG Tool 개발

MVC 패턴을 적용한 WYSIWYG 방식의 편집 Tool 개발[4/5]

5.      UI 구성 요소에 의한 작업단계

목적 : 사용자가 컨트롤 할 수 있는 UI적 요소를 제공하여 데이터를 변경할 수 있는 명령을 간접적으로 호출한다.

WYSIWYG 방식의 편집 Tool의 개발을 위해선 여러 가지 기능이 필요할 것이다. 간단하게 요약해 보면 다음과 같다.

  • 선택된 객체 표시하는 기능
  • 크기 조절할 수 있는 Resizer (보통 드래그 방식의 유틸)
  • 드래그 위치 이동 기능
  • 개별 속성 관리 창 또는 속성 리스트에서 수정할 수 있는 창
  • 편집에 사용될 수 있는 각종 아이템 선택 창(이미지, 텍스트, 각종 컴포넌트 등…)

제공된 UI 요소로 사용자는 간접적인 방식으로 우리가 미리 준비한 여러 가지 Command 를 호출할 수 있다. 기본적으로 다음과 같은 기능의 Command 가 필요할 것이다.

  • Add Command
  • Remove Command
  • Modify Command
  • Select (UnSelect) Command

Move, Resize 등의 Command 를 따로 사용할 수도 있겠지만 경험상 별 이득은 없는 것 같았다. 어차피 속성값이 변경되는 것이므로 Modify Command 에서 다른 속성 변경 작업과 똑같이 처리 하는 것이 더 낳은 것 같다.

6.      데이터 생성 및 수정 단계

목적 : 데이터를 수정하고 화면 업데이트를 할 수 있도록 알린다.

사용자가 제공된 UI 요소들로 발생시킨 Command 를 통해 데이터를 수정한다. Command 내용에 따라 다음 기능이 필요할 것이다.

  • 데이터 추가 작업
  • 데이터 삭제 작업
  • 데이터 내용 수정 작업

우리는 데이터를 XML로 구성하여 사용하기 때문에 XML 편집 방법으로 위의 기능들을 구현하기만 하면 될 것 같다. 시각적으로 생성될 객체는 (이 단계에서는 아직 시각적으로 표현될 객체가 화면에 추가되진 않았다.) XML 데이터의 노드와 완벽히 1:1 대응하도록 하고 부수적으로 필요한(Tool 에서만 필요하고 저장할 필요는 없는) 정보들은 별도의 네임스페이스로 정의한 Attribute으로 추가하도록 한다. 왜냐하면 Child 노드로 이런 정보를 달기 시작하면 XML 구조만으로 시각 객체의 Depth 또는 Parent를 구별하기가 매우 모호해 지기 때문이다. 또한 별도의 네임스페이스로 지정해 놓아 저장할 XML 파일을 생성할 때 일괄적으로 구분해서 삭제할 수 있다는 장점도 생긴다.

데이터 수정단계에서 가장 중요한 점은 화면상에서 사용자가 다루기 원하는 시각객체에 대하여 정확히 XML 데이터의 해당 노드를 신속 정확하게 찾을 수 있느냐 하는 것이다. 이를 위해 위에서 말한 별도의 네임스페이스로 유일한 uid값을 부여해 주어 노드가 이를 꼬리표처럼 달고 다니도록 하면 된다. 아마 Parent 노드가 바뀌는(시각화 객체의 컨테이너가 바뀌는) 대 이동이 있어도 매칭된 데이터를 찾기 쉬울 것이다.

7.      화면 업데이트 단계,

목적 : 변경된 데이터의 내용을 화면에 적용시킨다.

데이터가 변경되면 변경내용을 사용자가 볼 수 있도록 화면에 시각적으로 표현해 주어야 한다. 이미지가 추가되는 내용의XML 데이터가 변경되었다면 이 단계에서 loader를 추가하고 이미지를 로드하여 보여준다.

단, 이 경우 두 가지 방법을 택할 수 있는데,
첫째, 로드를 먼저 실행한 후 로드가 실패하면 사용자에게 에러 발생시키고, 성공하면 데이터 변경 하는 방식.
둘째, 위에서 말한 것처럼 데이터 변경을 먼저 한 후 화면 업데이트 시 로드 하는 방식이다.

순서의 차이이고 어떤 방식이든 상관은 없지만 두 방식 모두 MVC 패턴 구조상 데이터 변경을 알리고 여러 개의 UI요소들이 이를 청취하고 있기 때문에 변경에 대하여 무한루프에 빠지는 상황을 항상 염두에 두어야 한다. 예를 들면 List 구성요소에서 클릭에 의해 선택 항목이 바뀐다면 List로부터 change 이벤트를 받아서 command를 호출하여 데이터가 변경되고 화면이 업데이트 될것이다. 이때 변경된 선택항목에 대한 정보에 대하여 이를 적용하는 과정에서 List가 다시한번 선택 항목 표시를(이미 선택값을 표시하고 있겠지만) 업데이트 할 수도 있는데 이때 다시 change 이벤트가 발생하게 된다면 무한루프에 빠질 가능성이 있다는 것이다. 따라서 전달된 데이터에 대하여 표시형태가 현재와 같다면 change 이벤트를 발생시키지 않도록 체크해야 한다.