대우증권에 파견나가서 하고 있는 일은 대우증권의 차세대 시스템을 구축하는 것인데, 이때 사용되는 우리회사의 솔루션은 티맥스와 프로프레임이다. 티맥스는 미들웨어로서 프로프레임은 프레임워크로서의 위상을 가지며 이 둘은 물론 서로 긴밀히 연동되어 동작한다.
기존의 신한은행 프로젝트와 SK Telecom 프로젝트에서는 프로프레임 3.0이 사용되었는데, 이번 대우증권 프로젝트는 프로프레임 4.0이 처음 사용되고 있다. 그만큼 새로운 도전이기에 다소 파일럿 프로젝트의 성격을 가지게 되고 개발과정에서 변동사항이 있어 어려움을 겪기도 한다.
“프로프레임 4.0 사상”이라고 부를 만큼 프로프레임 4.0의 개발방법론은 기존의 날코딩과 확연히 다르다. 회사 보안상, 대우증권 업무 프로세스 보안상 스크린 샷을 보여드릴 수는 없지만 대략적으로 소개하자면, 가장 눈에 띄는 것은 EMB Desiner라고 할 수 있다. 프로그램을 작성하는데 있어 코드부터 작성하는 것이 아니라 업무의 플로우를 순서도 그리듯이 사각형과 화살표를 사용하여 나타낸다. 이는 DB접근에 해당하는 DBIO 모듈이나 비지니스 모듈 등을 끌어와 붙이는 작업을 포함한다. 모듈을 끌어다 쓰는 경우에는 Pro Mapper를 통해 입, 출력 데이터를 매핑한다.
프로젝트를 진행할 때 일주일에 한번씩 회의를 갖는다. 이 시간에는 프로프레임 4.0을 사용하여 시스템을 개발하면서 생각해볼만한 개선사항, 표준안등을 토론한다. 그리고 토론결과의 일부는 연구소로 피드백되어 프로프레임 4.0의 개선을 도모하고 있다.
우리회사가 만든 미들웨어 위에, 우리회사가 만든 프레임워크와 개발툴을 사용하여 시스템을 구축하면서 회사에 대한 자부심이 커가는 요즘이다.
org.eclipse.ui.views 확장점을 사용합니다. 해당 View를 포함할 카테고리를 지정하고 View를 표현하는 아이콘을 정의합니다. 이제 LogView.java 코드를 보겠습니다. 그렇게 길지 않으니 전체 코드를 늘어놓고 글을 이어나가도록 하지요.
public class LogView extends ViewPart { private Table table; private TableColumn[] columns; private final String[] TABLE_COLUMN_NAMES = { “Message”, “Location”, “Time” }; private final int[] TABLE_COLUMN_WIDTH = { 400, 400, 150 }; public LogView() { super(); } public void createPartControl(Composite parent) { table = new Table(parent, SWT.BORDER | SWT.V_SCROLL); columns = new TableColumn[TABLE_COLUMN_NAMES.length]; for(int i=0, n=TABLE_COLUMN_NAMES.length; i < n; i++) { columns[i] = new TableColumn(table, SWT.NONE); columns[i].setText(TABLE_COLUMN_NAMES[i]); columns[i].setWidth(TABLE_COLUMN_WIDTH[i]); } table.setHeaderVisible(true); table.setLinesVisible(true); } public void setLog(String message, String location) { Date date = new Date(); SimpleDateFormat dateFormat = new SimpleDateFormat(“hh:mm:ss”); String dateString = dateFormat.format(date); TableItem ti = new TableItem(table, SWT.NONE); ti.setText(0, message); ti.setText(1, location); ti.setText(2, dateString); for (int i = 0; i < columns.length; i++) { columns[i].pack(); } } public void clearLog() { table.clearAll(); } public void setFocus() { table.setFocus(); } }
View를 구현한 클래스는 ViewPart 클래스를 상속합니다. 예제의 Log View 처럼 단순히 정보를 보여주는 View를 구현하는 경우에는 createPartControl() 메서드에서 보여주고 싶은 위짓을 정의하는 것으로 간단히 View를 구성할 수 있습니다. View에 Action을 추가한다던가 워크벤치의 다른 View 혹은 Editor와 상호작용하도록 하려면 조금 더 복잡해지겠지요.
여기서 한가지 명확히 해야할 것은 JFace viewer의 위상입니다. JFace viewer는 모델-뷰 구조를 기반으로 사용자가 쉽게 유려한 viewer를 만들 수 있도록 돕기 위해 제작된 일종의 UI 프레임워크입니다. 따라서 JFace viewer를 제작할 때 모델의 데이터를 뷰에 전달하는 Contents Provider, Label Provider 등을 구현해야 하는 것이죠. 중요한 것은(!) JFace viewer는 이클립스에서 UI를 표현할 수 있는 어떤 곳에도 붙일 수 있다는 것 입니다. 마법사의 한 페이지에 붙일 수도 있고 Editor에 붙일 수도 있죠. 이 글에서 말하는 Viewer가 아닌 View는 이클립스 워크벤치의 일부로서 화면에 정보를 나타내기 위한 부분이라고 생각할 수 있습니다. 구현하기에 따라서는 ViewPart를 상속하여 Editor의 역할을 수행하도록 만들 수도 있습니다.
본론으로 돌아와서 createPartControl() 메서드에서 SWT의 table 컨트롤을 추가하고 초기화 합니다. View에 정보를 제공하고자 하는 다른 클래스에서는 clearLog(), setLog() 메서드를 이용해서 View에 포함된 table 위짓에 값을 추가 및 삭제하게 됩니다. LogView의 인스턴스는 id를 이용해서 다음과 같이 얻을 수 있습니다.
public void init(IWorkbenchWindowwindow) { this.window = window; }
Multi-page Editor는 여러페이지를 가진 에디터로, VICODE에서 spec.xml을 편집하는 Specifiaction Editor를 다음과 같이 총 4페이지로 구성된 형태의 에디터로 작성하였습니다. 이 글에서는 에디터 자체에 대한 내용보다는 여러페이지로 구성된 에디터를 작성하는 경우에 구현방법과 고려해야할 사항들에 대해서 소개하겠습니다.
Specification Editor에서 편집할 spec.xml 파일은 총 3가지 section으로 구성되어 있습니다. 에디터의 처음 3페이지는 각 section의 편집과정을 돕기 위해 컨트롤로 구성된 폼 에디터를 제공하며 마지막 페이지는 spec.xml을 직접 편집할 수 있도록 XML 에디터를 포함하고 있습니다.
구현 디테일로 들어가기 이전에 Multi-page Editor를 구현할 때 고려해야 할 사항에 대해서 설명하겠습니다. Multi-page Editor는 하나의 EditorInput을 여러 페이지에서 편집하게 되므로 편집하는 내용이 겹치는 경우에는 서로 다른 페이지 간의 값을 동기화 처리를 해주어야 합니다. 이 글에서 설명하는 페이지간의 동기화 방법은 직접 고안한 것이므로 효율적이지 않을 수 있습니다. ^^;
VICODE의 Specification Editor의 경우에 EditorInput은 spec.xml 입니다. 처음 3페이지의 폼 에디터와 마지막 페이지의 spec.xml 페이지는 편집의 범위가 겹치게 됩니다. 게다가 spec.xml을 구성하는 3가지 section 사이에서도 서로 값이 의존적으로 사용되기 때문에 각 페이지에서 변경된 값은 항상 다른 페이지에도 적용되어야 합니다. VICODE의 경우 다음과 같이 3가지 객체의 값이 동기화된 상태로 유지되어야 합니다.
spec.xml – AST – 각 페이지의 컨트롤이 가지는 값
AST는 spec.xml을 파싱해서 얻게 되는 Abstract Syntax Tree를 의미합니다. 에디터가 실행되면 spec.xml을 파싱해서 AST에 저장하게 되고 각 페이지의 컨트롤의 값은 AST의 값을 바탕으로 채워지게 됩니다. 이 것은 제가 말한 동기화의 아주 일부분이죠. 상세내용은 뒤에서 다루기로 하고 일단 코드를 보도록 하겠습니다.
우선 Editor의 확장점은 org.eclipse.ui.editors 입니다. Multi-page editor의 확장은 다른 editor의 확장방법과 다르지 않습니다. 다음은 확장을 정의한 plugin.xml의 일부입니다.
filenames 속성을 통해 spec.xml 파일에만 적용되도록 정의하였습니다. 이제 에디터를 구현한 SpecEditor 클래스를 살펴보겠습니다.
public class SpecEditor extends MultiPageEditorPart implements IResourceChangeListener { private final String endl = “\n”; private TextEditor editor; private String specFilePath; private int currentPageIndex = 0; private int editorPageIndex; private CommunicationPage communicationPage; private ApiPage apiPage; private RulePage rulePage; private Spec spec;
MultiPageEditorPart를 상속하여 구현합니다. 멤버변수로 눈여겨 보아야 할 것은 각 페이지를 참조할 수 있는 인스턴스와 AST를 저장하는 spec 입니다. ApiPage 등은 Composite을 상속한 클래스로 페이지를 구성하는 컨트롤을 정의하고 있습니다. editor는 마지막 페이지를 구성하는 XML 에디터의 레퍼런스 입니다. 이제 각 페이지를 어떻게 에디터에 추가하는지 살펴보겠습니다.
createPages() 메서드에 페이지를 추가하는 코드를 작성해 주어야 합니다. 여기서 불리는 createRulePage()를 살펴보면 addPage() 메서드를 이용해서 에디터에 페이지를 추가하는 것을 확인할 수 있습니다. XML 에디터를 추가하는 createXmlEditorPage() 메서드에서는 addPage() 메서드의 두번째 인자에 Multi-page Editor의 EditorInput(spec.xml)을 넘겨줍니다.
Multi-page Editor에서 save가 발생한 경우 호출되는 doSave() 메서드를 작성해야 합니다.
public void doSave(IProgressMonitor monitor) { if (currentPageIndex == editorPageIndex) { getEditor(editorPageIndex).doSave(monitor); // save Xml2Spec parser = new Xml2Spec(specFilePath); spec = parser.parseSpec(); // parsing to get AST communicationPage.setSpec(spec); // set AST to each page apiPage.setSpec(spec); rulePage.setSpec(spec); } }
Specification Editor에서 첫 3페이지는 저장 명령이 유효하지 않고 Apply 버튼을 클릭함으로써 수정내용을 AST와 파일에 적용하도록 구성되어 있습니다. Reply 버튼을 클릭하면 AST의 내용으로 컨트롤의 값을 복구 합니다. 반면에 4번째 페이지인 XML 에디터 페이지를 선택한 경우에 저장하게 되면 XML 에디터의 doSave() 메서드를 호출하여 spec.xml에 저장하게 됩니다. 저장이 완료되면 spec.xml의 내용이 갱신되었기 때문에 이를 다시 파싱하여 새로운 AST를 얻고 각 페이지에 setSpec() 메서드를 이용해 AST를 갱신해줍니다. 각 페이지는 이 AST를 이용해 컨트롤에 값을 설정하겠죠.
다음으로는 페이지가 변경되었을 때 호출되는 pageChange() 메서드를 볼까요?
protected void pageChange(int newPageIndex) { switch (newPageIndex) { case 0: communicationPage.updatePage(); // AST to control break; case 1: apiPage.updatePage(); break; case 2: rulePage.updatePage(); break; case 3: updateSpecFile(); // AST to spec.xml break; default: } currentPageIndex = newPageIndex; // save current page index }
처음 3페이지가 선택된 경우에는 AST의 내용을 바탕으로 컨트롤의 값을 채워주는 함수인 updatePage() 메서드를 호출합니다. 4페이지가 선택된 경우에는 AST의 내용을 spec.xml에 저장합니다. 따라서 XML 에디터는 최근 변경된 spec.xml의 코드를 출력하게 됩니다.
흐름을 다시 정리해보면, 에디터가 열리면서 spec.xml을 파싱하여 AST를 저장합니다. 처음 3페이지가 선택된 경우에는 AST의 내용을 가지고 페이지를 구성하는 컨트롤의 값을 채웁니다. 이 컨트롤의 값을 수정한 후 Apply 버튼을 누르게 되면 AST를 갱신함과 동시에 spec.xml 파일을 AST를 가지고 저장합니다. 반대로 XML 에디터에서 수정하고 저장한 경우에는 저장된 spec.xml 파일을 다시 파싱하여 AST를 구하고 이 것을 각 페이지에 넘겨줍니다.
이해를 돕기 위해 아래에 SpecEditor.java, RulePage.java 파일을 예제로 남깁니다.
이 글에서는 SWT와 JFace가 대략 무엇인지, 그리고 이클립스에서 차지하는 위상은 어떤 것인지에 대해서 개괄적으로 이야기하겠습니다. JFace는 일종의 프레임워크이다 보니 공부를 상당히해야 코딩이 가능하지만, SWT를 이용한 코딩은 AWT/Swing으로 UI를 작성해 보신 분이라면 쉽게 적응하실 수 있으리라 생각됩니다. 구조에 큰 차이가 없습니다.
SWT는 Standard Widget Toolkit의 약자로 이클립스에서 UI를 표현하는데 사용되는 API 입니다. SWT가 나오기전에는 AWT와 Swing을 사용했습니만, 써보신 분은 아시겠지만 UI가 어설프고 예쁘지가 않습니다. SWT의 특징은 현재 사용중인 OS에 어울리는 미려한 UI를 제공한다는 것입니다. JNI를 이용해 호스트 운영체제가 제공하는 사용자 인터페이스를 불러서 사용하기 때문이죠. 이클립스를 윈도우, 리눅스에서 각각 실행해보면 SWT와 Swing의 차이를 확인할 수 있습니다. Swing을 사용한 어플리케이션은 윈도우에서나 리눅스에서나 적당히 비슷하면서도 적당히 어설픈 UI를 보여줍니다.
이클립스 플러그인을 제작할 때, SWT는 빈번히 사용됩니다. 마법사의 각 페이지나 Preference 페이지를 작성할 때 등등 세부 사용자 인터페이스를 정의할 때 SWT 코딩을 해야 합니다. 이클립스에서 UI를 제공하는 클래스는 다음과 같이 createContents() 메서드를 오버라이딩 함으로써 유저 인터페이스를 정의합니다. 이때 사용되는 것이 SWT 입니다.
protected Control createContents(Composite parent) { // TODO Auto-generated method stub initializeDialogUnits(parent); // Get composite and set layout manager Composite composite = new Composite(parent, SWT.NONE); GridLayout layout = new GridLayout(); layout.marginHeight = convertVerticalDLUsToPixels (IDialogConstants.VERTICAL_MARGIN); layout.marginWidth = 0; layout.verticalSpacing = convertVerticalDLUsToPixels(10); layout.horizontalSpacing = convertHorizontalDLUsToPixels (IDialogConstants.HORIZONTAL_SPACING); composite.setLayout(layout);
AWT/Swing과 다른 몇가지 SWT의 특징을 언급하고 JFace로 넘어가겠습니다. 우선 Widget간의 부모/자식 관계를 맺는 방법에서 차이가 있습니다. AWT/Swing에서는 다음과 같은 방법으로 부모 인스턴스에 자식 인스턴스를 추가합니다. 패널에 버튼을 추가하는 것을 예로 들 수 있겠습니다.
부모_인스턴스.add(자식_인스턴스);
반면에 SWT에서는 자식 인스턴스를 생성할 때 부모의 인스턴스를 첫번째 인자로 넘겨줍니다. 예제코드에서 Composite을 추가하는 부분을 참조하세요. 그리고 두번째 인자로 스타일 비츠(style bits)라는 것을 정의합니다. SWT.NONE, SWT.PUSH, SWT.CHECK 등이 스타일 비츠에 해당합니다. 이 상수들을 |로 묶어 Widget의 속성을 결정합니다. 물론 각 Widget마다 유효한 스타일 비츠가 정해져 있습니다. 마지막으로 언급할 것은 SWT가 실제 운영체제의 리소스를 사용하기 때문에 더 이상 쓰지 않을 때 해제해야 한다는 점 입니다. 대부분의 SWT Widget은 앞서 살펴본 것 처럼 생성자에서 부모를 지정하기 때문에, 부모를 폐기하면 자식도 폐기된다는 규칙에 의해서 문제가 되지 않습니다. 하지만 부모의 Widget 없이 생성된 SWT 오브젝트인 Font, Image, Color 등등은 사용하지 않을 때 직접 폐기해야 합니다.
JFace는 SWT를 보완하기 위해, 모델 기반 접근 방법(model-based approach)을 기반으로 더 적은 시간에, 더 이해하기 쉬운, 재사용 가능한 코드를 작성할 수 있도록 설계되었습니다. JFace는 UI를 효과적으로 작성하기 위한 일종의 프레임워크라고 할 수 있습니다. JFace 뷰어를 예로 들자면, JFace 뷰어가 제공하는 클래스를 상속해 정해진 절차를 따라서(!) ‘뚝딱뚝딱’ UI를 코딩하면 ‘짠!’ 하고 그럴듯한 하이퀄리티(?)의 UI를 화면에서 확인할 수 있는 것 입니다. JFace는 모델-뷰 구조로 구성되어있기 때문에, 이미 어플리케이션에서 사용하던 모델을 자연스럽게 사용할 수 있습니다. 물론 모델과 뷰사이의 연결을 담당하는 코드를 작성해야 하겠지만요. (e.g. ContentProvider , LabelProvider) JFace는 UI의 얼개에 해당하므로 SWT 역시 함께 사용해야 합니다.
아주 오랜만에 이클립스 플러그인에 관한 글을 다시 적게 되었습니다. 연구실에 남아있을 마지막 2주일 동안 그 동안 못다뤘던 부분들을 정리하려 합니다. 오늘은 마법사에 대해서 다루겠습니다. 마법사(Wizard)가 무엇인지는 각종 개발툴을 써보셨다면 이미 잘 알고계실 것 같습니다. VICODE 사용자 메뉴얼을 존대말로 쓰다보니 탄력받아(?) 존대말로 쓰게 되었네요.
마법사는 여러 페이지로 구성되어 있습니다. 각 페이지는 프로젝트를 생성하는 등의 작업을 위한 일련의 단계를 표현합니다. 그리고 각 페이지는 자신에게 필요한 정보가 입력되었는지를 판단하여 마법사에게 알립니다. 마법사는 페이지의 상태에 따라 다음 페이지로의 이동가능 여부를 판단하여 UI에 반영하는 것이죠. 모든 페이지가 완료 상태에 도달하면 Finish 버튼이 활성화 되어 마법사를 종료할 수 있습니다. Finish 버튼이 클릭되면 마법사는 각 페이지에서 받은 정보를 바탕으로 원하는 작업을 수행하게 됩니다.
코드레벨에서 살펴보면 마법사는 마법사 클래스와 각 페이지에 해당하는 클래스의 집합으로 구성됩니다. 마법사 클래스는 페이지 클래스를 참조하고 있고 addpages() 함수에서 페이지 클래스를 마법사에 등록합니다.
지금부터는 코드를 가지고 상세구현 과정을 살펴보도록 하겠습니다. 이클립스 플러그인의 시작은 확장점입니다. 마법사를 추가할 수 있는 확장점은 총 3가지가 있는데, 이 글에서는 프로젝트 생성 마법사를 추가하는데 사용되는 org.eclipse.ui.newWizards를 사용하겠습니다. 다음코드는 확장을 정의한 plugin.xml 코드의 일부분입니다.
마법사 확장점에는 여러가지 속성이 있습니다. Perspective 관련 속성에는 VICODE perspective의 id를 정의하였습니다. canFinishEarly는 모든 페이지를 다 거치지 않아도 완료할 수 있는 마법사인지를 정의합니다. hasPages는 여러 페이지를 가진 마법사인지를 정의합니다. 예제로 보여드릴 VICODE 프로젝트 생성 마법사는 2페이지로 구성되어 있고 모든 페이지를 거쳐야 하므로 위의 코드와 같이 정의하였습니다.
먼저 마법사 클래스(NewProjectWizard)를 살펴보도록 하겠습니다.
public class NewProjectWizard extends Wizard implements INewWizard { private WizardNewProjectCreationPage mainPage; private WizardInitialPage initialPage; private IProject newProject;
public boolean performFinish() { createNewProject(); initialPage.finish(newProject); return true; }
public void addPages() { mainPage = new WizardNewProjectCreationPage(“New VICODE Project (1/2)”); mainPage.setDescription(“Create a new VICODE project in the workspace”); mainPage.setTitle(“Create VICODE Project”); initialPage = new WizardInitialPage(“New VICODE Project (2/2)”); initialPage.setDescription(“You can specify top module name and communication event.”); initialPage.setTitle(“Module declaration for hardware and Communication Event”); addPage(mainPage); addPage(initialPage); }
프로젝트 마법사 클래스는 Wizard 클래스와 INewWizard 인터페이스를 상속합니다. 예제 마법사의 목표는 두 페이지에 걸쳐 정보를 받아 들인 후 프로젝트를 생성하는 것 입니다. 총 2페이지로 구성되어 있는데, 첫번째 페이지는 구현하지 않고 이미 작성된 프로젝트 생성 페이지를 가져다가 사용하였습니다. 이 페이지는 단순히 프로젝트 이름과 저장위치를 지정할 수 있도록 구성되어 있습니다. 두 번째 페이지는 VICODE 프로젝트를 생성하는데 있어 필요한 정보를 입력받기 위해 직접 구현한 페이지입니다.
addPages() 메서드에서는 각 페이지의 인스턴스를 생성하고 초기화한 후에 addPage() 메서드를 호출하여 마법사에 각 페이지를 등록합니다. Finish 버튼이 클릭되면 호출되는 performFinish() 메서드에서 마법사 완료시에 필요한 일들을 기술합니다. 실제 프로젝트가 생성되는 코드는 첨부파일을 참조하시기 바랍니다.
지금부터는 두번째 페이지에 해당하는 코드를 살펴 보겠습니다.
public class WizardInitialPage extends WizardPage { public void createControl(Composite parent) { Composite composite = new Composite(parent, SWT.NONE); GridLayout gridLayout = new GridLayout(); gridLayout.numColumns = 1; composite.setLayout(gridLayout); createModuleNameGroup(composite); createCommunicationGroup(composite); setControl(composite);
updatePageComplete(); setMessage(null); setErrorMessage(null); } private void updatePageComplete() { setPageComplete(false); // 페이지의 완결성 체크 if (moduleNameText.getText().equals(“”)) return; // 페이지의 완결성 체크를 건너 뛰었다면 페이지를 완료상태로 변경 setPageComplete(true); setMessage(null); setErrorMessage(null); }
마법사의 모든 페이지 클래스는 WizardPage 클래스를 상속합니다. UI를 정의하는 다른 클래스와 마찬가지로 createControll() 메서드에서 SWT로 사용자 인터페이스를 작성합니다. 마지막에 호출되는 메서드인 updatePageComplete()는 페이지에 필요한 정보가 입력되어 있는지를 판단하기 위해 제가 작성한 메서드 입니다. 이 메서드는 각 컨트롤에서 값이 변경될때마다 호출되어 페이지가 완료상태인지를 setPageComplete() 메서드를 호출하여 마법사에 알립니다.
이상으로 이클립스 플랫폼에서 마법사를 구현하는 방법에 대해서 말씀드렸습니다. 아래 첨부한 소스코드를 참조하시면 이해하시는데 도움이 될 것 같습니다.
