RAD Studio 라이브바인딩 이해하기

RAD Studio 라이브바인딩(LiveBindings) 이해하기

작성자 : 캐리 젠슨 (Cary Jensen)

2012 년 2 월

Americas Headquarters

100 California Street, 12th

Floor

San Francisco, California

94111

EMEA Headquarters

York House

18 York Road

Maidenhead, Berkshire

SL6 1SF, United Kingdom

Devgear

서울특별시 반포 1 동 743-14

4 층 ㈜데브기어

(T) 02.595. 4288

Embarcadero Technologies Tech Notes

RAD Studio 라이브바인딩 이해하기

데브기어 기술정보 tech.devgear.co.kr 데브기어 홈페이지 www.devgear.co.kr 문의 [email protected]

개략

라이브바인딩은 Rad Studio XE2에서 최초로 도입되었으며, 익스프레션(expression)을 기반으로 하여

객체의 속성을 변경할 수 있는 매커니즘을 제공합니다. 라이브바인딩은 이전의 RAD Studio에서 볼

수 없었던 새로운 기능을 추가하여, 객체 사이의 연관 관계를 구성하기 위한 중요한 새 메커니즘을

제공합니다.

라이브바인딩은 RAD Studio XE2에서 제공되는 모든 유형의 어플리케이션에서 사용 가능합니다.

델파이와 C++ 빌더, VCL과 파이어몽키 컴포넌트 라이브러리, 윈도우즈에서 Mac OS와 iOS 까지의

모든 배포 가능한 플랫폼에서 말이죠.

이 기술 백서는 여러분이 라이브바인딩에 익숙해 지는 것을 목적으로 작성되었습니다. 여러분은 이

문서를 통해 VCL (visual component library)과 파이어몽키 (FireMonkey) 어플리케이션에서

라이브바인딩을 이용하여 컨트롤들을 연결하는 방법에 대해 배울 수 있을 것입니다.

또한 익스프레션(expression), 스코프(scope)를 포함한 익스프레션 엔진(expression engine)의 역할에

대해 설명할 것입니다.

Embarcadero Technologies Tech Notes - 3 -


데브기어 기술정보 tech.devgear .co.kr 데브기어 홈페이지 www.devgear.co.kr 문의 [email protected]

1 M

DM

라이브바인딩 (LIVEBINDINGS)

라이브바인딩은 RAD Studio에서 객체의 프로퍼티를 익스프레션과 연결시키기 위해 사용되는

매커니즘입니다. 익스프레션은 동일한 객체의 다른 프로퍼티, 두 번째 객체의 프로퍼티가 될 수

있으며, 객체의 프로퍼티, 리터럴, 연산자 및 메서드를 포함하는 복잡한 익스프레션이 될 수도

있습니다.

라이브바인딩이 하는 일이 새로운 것은 아닙니다. RAD Studio는 이전에도 객체의 프로퍼티에 값을

할당할 수 있는 기능을 가지고 있었습니다. 그러나 라이브 바인딩이 작동하는 방법과, 라이브

바인딩이 적용되는 방법은 전통적인 VCL 연관 (association)과는 상당히 다릅니다.

이제 전통적인 VCL 상호작용의 예인 VCL 컨트롤의 데이터 인식(data awareness)에 대해 알아봅시다.

DBEdit부터 보도록 합시다. 이 컨트롤은 DataSource와 연결될 수 있습니다. 그리고 DataSource는

ClientDataSet과 같은 DataSet과 연결될 수 있습니다.

프로퍼티들을 사용하여, 이 세 개의 컨트롤 (DBEdit, DataSource, ClientDataSet)을 연결할 수 있으며,

DataSet 안의 데이터의 변화는 DBEdit 내의 텍스트에 표시됩니다. 게다가 DBEdit의 내용이 변경되면,

ClientDataSet의 현재 레코드에 연결된 필드의 값이 자동으로 변경됩니다. (먼저 ClientDataSet이

활성화되어 있고 (Active), 연결된 필드가 쓰기 가능해야 하며, DataSource가 기본 프로퍼티 설정값을

사용하고 있어야 합니다.)

VCL이 동적 컴포넌트 상호작용을 지원하는 동안, 데이터 인식 예제 또는 VCL 프레임워크의 특정

부분에서는 항상 특정 컴포넌트의 조합에 제한되어 왔습니다. (위의 예처럼 DBEdit, DataSource,

ClientDataSet 식으로 조합되어 사용되어야만 합니다.)

프레임워크 레벨의 상호작용의 예는 TComponent 클래스에 도입된 가비지 컬렉션 방식에서 찾아볼

수 있습니다. 모든 TComponent는 오너(owner)를 갖습니다. 소유된 컴포넌트는 자신이 생성될 때,

오너 컴포넌트에게 그 사실을 알립니다. 또한 파괴될 때 파괴됨을 오너에게 알립니다. 오너는 소유된

컴포넌트의 생명 주기 동안에 그 컴포넌트의 참조를 유지합니다. 이 참조는 오너 자신이 소멸되는

시점에 소유된 컴포넌트들을 소멸시키는데 사용됩니다. 이 매커니즘에 의해, 디자인 타임에 폼에

위치된 어떤 컴포넌트도 폼이 해제되는 시점에 함께 해제되는 것이 보장됩니다.

데이터 인식 (data awareness)과 가비지 컬렉션 (garbage collection)은 모두 특정 클래스의 기능에

의존하고, 특정 프로퍼티에 영향을 미칩니다. 이 매커니즘을 사용하여 상호작용하는 컴포넌트의

디자인의 일부로서 말이죠. 그에 비해 라이브바인딩은 다른 매커니즘으로 동작하고, 좀더 다양한

클래스 집합과 대부분의 프로퍼티에 적용될 수 있습니다.

예를 들어, 라이브바인딩은 ProgressBar의 Position 프로퍼티와 spinner 컨트롤의 Text 프로퍼티를

연관되어 동작하도록 할 수 있습니다. (spinner 컨트롤이란 VCL 툴 팔레트의 샘플 페이지에 있는

SpinEdit 같은 컴포넌트를 말합니다.) ProgressBar와 SpinEdit 컴포넌트는 서로를 인식하여

동작하도록 디자인되어 있지 않습니다. 대신에 라이브바인딩은 이 두 객체가 호환 가능한 프로퍼티




(TProgressBar.Position와 TSpinEdit.Value)를 갖는다는 사실을 이용하여 이 연관을 수행합니다.

사실 이 예제는 지나치게 단순합니다. 언급된 두 프로퍼티가 Integer 타입의 프로퍼티이기

때문입니다. 라이브바인딩은 Edit의 Text 프로퍼티와 ProgressBar의 Position 프로퍼티를 동기화된

상태로 유지시킬 수 있습니다. 하나는 String 타입이고 하나는 Integer 타입일지라도 말이죠. (다만

Edit에 입력된 값이 Integer로 변환될 수 없으면 문제가 발생하긴 합니다만)

지금까지 VCL에서의 라이브바인딩에 대해서만 언급하였습니다. RAD Studio XE2 전체로 보았을 때,

라이브바인딩의 최대 수혜자는 파이어몽키 컴포넌트 라이브러리입니다. VCL과 다르게, 파이어몽키

컴포넌트는 데이터인식 프레임워크가 결여되어 있기 때문입니다.

파이어몽키가 DBEdit, DBGrid, DBImage와 같은 클래스를 지원하지 않는 것이 파이어몽키의 문제는

아닙니다. 라이브바인딩은 고유의 유연성과 함께 여러분이 대부분의 파이어몽키 컴포넌트를

데이터셋 (DataSets)과 양방향으로 연결할 수 있도록 해 줍니다. 뿐만 아니라, 파이어몽키 컴포넌트를

다른 파이어몽키 컨트롤과 연결할 수도 있습니다.

이 문서를 통해 라이브바인딩의 기능에 대해 빠짐없이 알 수 있을 것입니다. 또한 VCL과 파이어몽키

모두에서 라이브바인딩을 이용하여 컨트롤 사이의 연결(associations)을 만드는 방법에 대해

차근차근 알아가게 될 것입니다.

다음에는 라이브바인딩이 동작하게 하는 다양한 개념에 대해 알아볼 것입니다. 여기에서

익스프레션(expressions), 스코프(scope), 관리(managed) 라이브바인딩, 비관리(unmanaged)

라이브바인딩에 대해 다루게 됩니다.

계속해서 라이브바인딩 프레임워크가 제공하는 다양한 디자인 타임 컴포넌트들 (BindingsList,

BindScope, BindExpression, List, Link)에 대해 알아볼 것입니다. 그리고 다수의 디자인타임

컴포넌트와 라이브바인딩 설정을 도와주는 프로퍼티 에디터들에 대해 알아볼 것입니다.

이 문서는 RAD Studio XE2에 있는 라이브바인딩의 현재 상태에 대한 논의로 마무리될 것입니다.

그리고 향후 RAD Studio의 차기 버전에서 향상될 것으로 예상되는 개선점들에 대해 생각해 볼

것입니다.

라이브바인딩 시작하기

저는 다양한 라이브바인딩의 데모를 보았습니다. 이 데모들은 라이브바인딩의 깊은 부분을 알 수

있게 해주고, 익스프레션 엔진의 내부 동작에 대한 자세한 부분에 대해 다루고 있습니다. 그 데모들의

접근법과 다르게, 저는 이 문서를 간단한 라이브바인딩을 설정하는 방법을 알아보고 그것의 동작을

살펴보면서 시작하려고 합니다. 그런 다음에 그것의 바탕이 되는 원리에 대해 설명할 것입니다.

저자의 노트: 저는 델파이 개발자이고, 이 문서의 모든 샘플 프로젝트는 델파이 프로젝트로 되어

있습니다만, C++Builder 또한 라이브바인딩을 지원합니다.




1 M

DM

자, 간단한 라이브바인딩 VCL 어플리케이션을 생성하는 것으로 시작해 봅시다.

코드: 이 프로젝트의 소스 코드는 이 문서와 함께 다운로드 할 수 있는

SimpleVCLLiveBindingsExample 프로젝트에 있습니다.

간단한 VCL 라이브바인딩 예제

VCL 어플리케이션을 위한 라이브바인딩 프로젝트를 생성하기 위해서는 다음과 같은 단계를 따라야

합니다.

1. RAD Studio XE2 의 메인 메뉴에서 File | New | VCL Forms Application – Delphi 를 선택합니다.

2. 메인 폼에 StatusBar 컨트롤을 추가합니다. (툴 팔레트의 Win32 페이지에 있습니다.)

3. 오브젝트 인스펙터를 사용하여, StatusBar 의 SimplePanel 프로퍼티를 True 로 설정합니다. 이것은

StatusBar 의 SimpleText 프로퍼티를 사용할 수 있게 합니다.

4. 이제 여러분은 라이브바인딩을 추가할 준비가 되었습니다. StatusBar 에서 마우스 우측 버튼을

클릭하고, New LiveBinding…을 선택합니다. RAD Studio 는 그림 1 에 나온 것과 같은 New

LiveBinding 대화상자를 표시합니다.

New LiveBinding 대화상자는 적은 수의 LiveBinding 타입의 목록을 가지고 있습니다. 각각이 무슨

일을 하며, 언제 그것을 사용해야 하는지에 대해 알아보겠습니다. 그러나 이를 이해하기 위해서는 좀

더 바탕에 깔려있는 개념들에 대해 알아야 합니다.

이제 TBindExpression 라이브바인딩을 선택하고, OK 버튼을 클릭합니다.




그림 1. New LiveBinding 대화상자

이 대화상자를 사용하고 나면 몇 가지 일들이 일어납니다. 우선, 폼 위에 BindingsList1 이라는 새로운

컴포넌트가 추가됩니다. 이 컴포넌트는 BindingsList 이고, 기본적으로 각각의 폼에는 이 컴포넌트가

하나씩 존재하게 됩니다. 그리고 이 컴포넌트는 해당 폼에 정의된 라이브바인딩들을 관리하는데

사용됩니다.

두 번째로 BindExpressionStatusBar11 이라는 새로운 라이브바인딩이 생성됩니다. 이 새로운

라이브바인딩은 오브젝트 인스펙터에 그림 2 와 같이 표시됩니다.




1 M

DM

그림 2. 새로 생성된 라이브바인딩은 오브젝트 인스펙터에 표시됩니다.

5. 이 라이브바인딩의 중요한 프로퍼티 중 하나인 ControlComponent 가 설정되었습니다. 이제

ControlExpression 프로퍼티를 SimpleText 로 설정해야 합니다.

(SimpleText 는 StatusBar 의 SimpleText 프로퍼티를 나타냅니다.) 그리고 SourceComponent

프로퍼티를 Form1 으로 설정하고, SourceExpression 프로퍼티를 아래와 같은 문자열로 설정합니다.

ClassName() + ‘, Width:’ + ToStr(Width) + ‘, Height: ‘ + ToStr(Height)

위와 같이 설정하였다면, 오브젝트 인스펙터는 그림 3 과 같이 표시될 것입니다.




그림 3. 새로운 라이브바인딩은 오브젝트 인스펙터에서 이와 같이 설정되었습니다.

이 라이브바인딩은 익스프레션 엔진에게 지정된 문자열을 StatusBar 의 SimpleText 프로퍼티에

대입하라는 것을 의미합니다. 게다가 이 문자열은 폼의 ClassName 메서드를 호출하고, 폼의

Width 와 Height 프로퍼티를 읽어서 이 읽어온 정수 (Integer) 값을 문자열로 변환합니다. 그리고 이

Width 와 Height 를 나타내는 문자열과 폼의 클래스 이름, SourceExpression 프로퍼티에 적은 문자열

리터럴을 모두 이어 줍니다.

이제 해야 할 일은 익스프레션 엔진에게 이 라이브바인딩을 적용하라고 알리는 것입니다.

SourceExpression 에는 폼의 Width, Height 에 대한 정보가 포함되어 있으므로, 이 알림은 폼의

크기가 변경될 때마다 수행되어야 할 것입니다. 다행히도, 폼의 크기 변경을 위한 이벤트 핸들러인

OnResize 가 존재합니다. 이 알림을 수행하기 위해서는 다음과 같은 단계를 따라야 합니다.

6. 오브젝트 인스펙터에서 폼을 선택하고, Events 탭에서 OnResize 이벤트 핸들러 부분을 더블클릭

합니다. 그러면 이벤트 핸들러 작성을 위한 코드가 생성될 것입니다.

7. 이 이벤트 핸들러 안에 아래와 같은 코드를 입력합니다.

BindingsList1.Notify(Sender, '');

위에 설명한 단계를 수행하였다면, 이벤트 핸들러는 다음과 같을 것입니다.

procedure TForm1.FormResize(Sender: TObject);

begin

BindingsList1.Notify(Sender,'');




1 M

DM

end;

8. 이제 라이브바인딩의 동작을 볼 준비가 되었습니다. 실행을 위해서 F9 를 누르거나, RAD Studio 의

툴바에서 Run 버튼을 클릭합니다. 다음으로, 폼의 크기를 변경하기 위해서 마우스로 폼의 우측 하단

모서리 부분을 드래그합니다. 폼의 크기가 변경되면서 StatusBar 에 표시되는 문자열이 갱신됩니다.

그림 4 와 비슷한 화면을 확인할 수 있습니다.

그림 4. 라이브바인딩은 폼의 모양이 변경될 때마다 StatusBar 에 표시되는 문자열을 갱신합니다.

여러분은 아마도“그래서 뭐? 나는 이미 라이브바인딩을 사용하지 않고도 같은 동작을 하는 이벤트

핸들러를 작성할 수 있어” 라는 생각이 들 것 입니다.

맞습니다. 그리고 여기 같은 동작을 하는 이벤트 핸들러의 예제가 있습니다.

procedure TForm1.FormResize(Sender: TObject);

begin

StatusBar1.SimpleText := Self.ClassName + ', Width: ' + IntToStr(Self.Width) +

', Height: ' + IntToStr(Self.Height);

end;

이러한 지적(기존 방식대로 단순한 이벤트 핸들러를 작성하면 될 것을 왜 라이브바인딩을

사용하는가)에 대해 다음과 같은 세가지로 답할 수 있을 것입니다.

첫 째, 명시적으로 StatusBar 의 SimpleText 프로퍼티에 값을 할당하는 두 번째 이벤트 핸들러의 경우,

어떤 오퍼레이션이 수행되어야 하는지에 대해 비교적 잘 알고 있어야 합니다. 이에 비해, 첫 번째

이벤트 핸들러는 Sender 와 관련된 무언가에 변화가 있다는 사실을 익스프레션 엔진에게 단순히

알립니다. 첫 번째 이벤트 핸들러는 변화에 대한 세부 사항을 다루고 있지 않고, 또한 그에 대한

반응으로 어떤 일을 해야 하는지에 대해서도 지정하지 않습니다. 익스프레션 엔진이 라이브바인딩에




기반하여 실제적인 할당을 수행합니다. 그리고 코드가 아닌 라이브바인딩에 무슨 일이 일어나야

하는지를 정의합니다.

둘 째, 모든 라이브바인딩에서 직접 익스프레션 엔진에 통지하는 작업을 할 필요는 없습니다. 리스트

(Lists)와 링크 (Links)를 포함한 많은 수의 라이브바인딩은 이벤트 핸들러가 필요하지 않습니다.

그러한 라이브바인딩을 사용한다면, 라이브바인딩을 사용하는 폼은 코드가 적어질 것입니다. 그

동작을 수행하는 전통적인 이벤트 핸들러를 사용하는 것에 비해서 말이죠.

셋 째, 이벤트 핸들러를 필요로 하는 라이브바인딩들을 위해 라이브바인딩들은 동일한 하나의 이벤트

핸들러를 참조할 수 있습니다. 그리고 그 이벤트 핸들러에서 BindingsList 의 Notify 메서드를

호출하도록 작성할 수 있습니다. 결과적으로 다양한 작업을 수행하기 위해 라이브 바인딩을 사용하는

폼은 전혀 이벤트 핸들러를 가지지 않거나, 단지 하나 정도의 이벤트 핸들러 만을 가질 것입니다.

그와 대조적으로, 그러한 작업을 OnResize 이벤트 핸들러에서 한 것처럼 코드를 사용하여

수행한다면, 많은 이벤트 핸들러들이 존재하게 될 것입니다. 서로 다른 특정 작업을 호출하기 위한

이벤트 핸들러들 말이죠.

이제 파이어몽키 어플리케이션에서 라이브바인딩을 사용하는 법에 대해 알아보도록 합시다.

코드: 이 프로젝트의 소스 코드는 이 기술 백서와 함께 다운로드 할 수 있는

SimpleFireMonkeyLiveBindingsExample 프로젝트 안에 있습니다.

간단한 파이어몽키 라이브바인딩 예제

라이브바인딩을 사용하는 파이어몽키 어플리케이션을 생성하기 위해서는 아래의 절차를 따라야

합니다. 시작하기 전에, RAD Studio 에 열려 있는 어플리케이션이 있다면 닫습니다.

1. File | New | FireMonkey HD Application – Delphi 를 선택합니다.

2. 폼에 Label, TrackBar 컴포넌트를 추가합니다. 두 컴포넌트 모두 툴 팔레트의 Standard 페이지에

있습니다. 이 두 컴포넌트를 폼에 놓을 때, 모두 직접적으로 폼 위에 위치하도록 주의해야 합니다.

많은 파이어몽키 컴포넌트들이 부모가 될 수 있으며, Label 안에 TrackBar 를 놓을 수도 있습니다. (그

반대도 가능합니다.) 그러므로 주의해야 합니다. Label 과 TrackBar 가 다른 부모를 거치지 않고 바로

폼 위에 위치하였는지를 확인하기 위해 RAD Studio IDE 상에 있는 Structure 패널을 사용할 수

있습니다.

3. Label 컴포넌트를 선택합니다. 오브젝트 인스펙터를 사용하여 Text 프로퍼티를 FireMonkey 로

설정하고, TextAlign 프로퍼티를 taCenter 로 설정합니다.

4. Label 이 선택된 상태로, 폰트 대화상자를 표시하기 위해 Font 프로퍼티를 더블 클릭합니다.

5. 폰트 대화상자를 이용하여, 폰트를 Comic Sans MS 로, 크기를 48 로 설정한 뒤, 폰트 대화상자를

닫습니다. (Comic Sans MS 폰트가 없을 시 다른 폰트를 선택해도 무방합니다.)




1 M

DM

6. 컴포넌트 선택 시 주변에 표시되는 크기 조절 점(grab handle)을 사용하여, Label 의 글자가 제대로

보이도록 Label 의 크기를 적절히 조절합니다. 그리고 Label 을 폼의 중앙 쯤에 위치시키도록 합니다.

7. 이제 TrackBar 를 선택합니다. 오브젝트 인스펙터를 사용하여, Max 프로퍼티를 180 으로, Min

프로퍼티를 -180 으로 설정합니다.

8. 이제 TrackBar 를 Label 의 아래 쪽 가운데로 위치시킵니다. 그리고 TrackBar 의 너비를 원하는 대로

넓힙니다. 이러한 작업들을 완료하였다면, 폼은 그림 5 처럼 보여질 것입니다.

그림 5. 새 파이어몽키 어플리케이션의 메인 폼

이제 우리는 라이브바인딩을 생성할 준비가 되었습니다. 아래의 단계를 따라 진행하시기 바랍니다.

9. Label 에서 오른쪽 클릭을 하고, New LiveBinding…을 선택합니다. RAD Studio 는 그림 6 에서처럼

New LiveBinding 대화상자를 표시할 것입니다.




그림 6. 파이어몽키 컴포넌트에 대한 New LiveBinding 대화상자

그림 1 에 나온 것과 이 New LiveBinding 대화상자를 비교해 보면, 이 대화상자는 DB Links 노드

아래에 보이는 한 개의 추가적인 라이브바인딩이 표시된 것을 알 수 있습니다. RAD Studio 의 이번

릴리즈에서 파이어몽키는 VCL 라이브러리에서는 지원하지 않는 소수의 (7 가지) 라이브바인딩

클래스를 지원합니다. 그러나 이 클래스들은 VCL 에서 사용 가능한 클래스들과 매우 가깝게 연관되어

있습니다. 이 파이어몽키 클래스들에 대해서는 이 문서의 끝부분에서 좀더 자세히 알아보도록

하겠습니다.

10. 다시 한번 TBindExpression 라이브바인딩을 선택하고, OK 버튼을 클릭합니다.

앞에서 그랬던 것처럼, RAD Studio 는 BindingsList 와 TBindExpression 를 생성합니다. 그리고

BindExpressionLabel11 이라는 이름을 가진 TBindExpression 이 오브젝트 인스펙터에 선택되어 있을

것입니다.




1 M

DM

11. 오브젝트 인스펙터에 BindExpressionLabel11 이 선택된 상태에서, ControlExpression 프로퍼티를

RotationAngle 로, SourceComponent 프로퍼티를 TrackBar1 으로, SourceExpression 프로퍼티를

Value 로 설정합니다.

이제 모든 라이브바인딩 설정이 끝났습니다. 그러나 이 타입의 라이브바인딩에서 우리는 직접

익스프레션 엔진에게 무언가가 변했다는 것을 알릴 필요가 있습니다. 이를 위한 한가지 방법은

TrackBar 의 OnChange 이벤트 핸들러를 작성하는 것입니다. 이를 위해, TrackBar 를 더블 클릭하고,

생성된 OnChange 이벤트 핸들러 안에 BindingsList1 에 대한 Notify 메서드 호출을 추가합니다.

여러분이 이 절차를 완료하였다면, 이벤트 핸들러는 아래와 같을 것입니다.

procedure TForm1.TrackBar1Change(Sender: TObject);

begin


end;

12. 이제 모든 것을 마쳤습니다. F9 를 눌러 폼을 실행시키고, TrackBar 의 값을 이리저리 바꿔봅시다.

그러면 그림 7 과 같이 Label 이 회전하는 것을 볼 수 있습니다.

그림 7. TrackBar 의 position 을 변경하면 Label 이 회전한다.




라이브바인딩은 어떻게 동작하는가?

지금까지는 라이브바인딩의 동작을 살펴보았고, 이제부터 라이브바인딩이 어떻게 동작하는지에 대해

자세히 알아볼 차례입니다. 라이브바인딩의 핵심은 객체와 익스프레션 사이의 연관을 만들기 위한

매커니즘이라는 것입니다. 익스프레션은 익스프레션 엔진에 의해 값으로 평가되는(evaluated)

문자열들입니다. 라이브바인딩은 평가(evaluation)의 결과를 객체의 프로퍼티에 할당하기 위해서

익스프레션 엔진의 출력(output)를 사용합니다.

자 이제 익스프레션을 살펴보면서 이에 대해 논의해 보도록 합시다. 이 논의의 일부로서

스코프(scope)에 대해 이야기해 보도록 하겠습니다. 그러고 난 후, 각각의 라이브바인딩 컴포넌트에

대해 자세히 알아볼 것입니다.

익스프레션 (EXPRESSIONS)

익스프레션은 문자열들입니다. 이 문자열들은 리터럴(literals), 연산자(operators), 객체의 프로퍼티,

메서드로 구성될 수 있습니다.

우리가 VCL 라이브바인딩 예제에서 사용했던 SourceExpression 를 살펴 봅시다.

ClassName() + ', Width: ' + ToStr(Width) + ', Height: ' + ToStr(Height)

이 문자열은 모두 4 개의 요소로 구성되어 있습니다.

리터럴 (LITERALS)

이 경우에 사용된 리터럴은 문자열 리터럴입니다.

', Width: '

그리고

', Height: '

위와 같은 문자열은 여러분이 델파이 코드에서 작성하는 문자열과 같아 보이지만, 다른 점이

있습니다. 첫째로, 이 문자열들은 익스프레션 엔진에 의해 평가됩니다. 델파이 컴파일러와 달리

익스프레션 엔진은 큰 따옴표(“”) 뿐 아니라 작은 따옴표(‘’)로 둘러 쌓인 문자열도 문자열 리터럴로

인식합니다. 동일한 익스프레션 안에서 사용된 다른 인용 표시(큰 따옴표 혹은 작은 따옴표)는

적절하게 인식될 수 있습니다. 예를 들어, 아래의 익스프레션은 위의 VCL 예제에서 사용된 것과

동일한 결과로 평가됩니다.

ClassName() + ", Width: " + ToStr(Width) + ', Height: ' + ToStr(Height)

그러나 여기에 제한은 있습니다. 작은 따옴표로 문자열 리터럴을 시작하였으면, 작은 따옴표로

끝내야 하며, 큰 따옴표의 경우에도 마찬가지입니다. 자바스크립트에 친숙하다면, 문자열에 대한

이러한 접근법 또한 친숙할 것이고, 이 접근법의 가치가 훌륭하다는 점 또한 알 것입니다. 예를 들어,

여러분이 작성한 익스프레션 안에서 큰 따옴표를 사용해야 한다면, 문자열 리터럴을 정의할 때 작은

따옴표를 사용하면 됩니다. 아래와 같이 말이죠.




1 M

DM

'He said "Yahoo!"'

그리고 여러분이 영어의 축약형이나 소유격을 사용하기 위해 문자열 리터럴을 아래와 같이 큰

따옴표로 감쌀 수 있습니다.

"I'd say it's the cat's meow"

연산자 (OPERATORS)

VCL 예제의 익스프레션에서 사용된 연산자는 결합 연산자(concatenation operator)인 + 기호입니다.

그리고 다른 연산자들도 있으며, 각각은 적절한 곳에 사용될 수 있습니다. 앞에서 보았던

익스프레션의 경우 문자열 리터럴에서 연산자가 사용된 경우입니다. 수 리터럴(numeric literals)에서

연산자를 사용할 수 있으며, 이런 경우 수 연산자(numeric operators)는 유용합니다. 예를 들어,

아래의 경우는 둘 다 익스프레션 엔진에서 처리될 수 있는 적합한 익스프레션입니다.

2 + 5

1.2 > 4.23

익스프레션 엔진은 첫 번째 익스프레션을 7 로 평가하며, 두 번째 익스프레션은 불린(Boolean)형

false 로 평가합니다. 또한 복잡한 익스프레션에서 평가 우선순위를 지정하기 위하여 괄호를 사용할

수 있습니다. 예를 들어, 아래의 익스프레션은 첫 번째는 4, 두 번째는 2 로 평가됩니다.

2 * 3 - 2

2 * (3 - 2)

프로퍼티 (PROPERTIES)

VCL 예제의 익스프레션으로 돌아가 보면, Width 와 Height 는 둘 다 객체의 프로퍼티입니다. 이

익스프레션은 SourceExpression 이기 때문에 이 프로퍼티들은 SourceComponent 로 지정된

Form1 의 프로퍼티입니다.

이는 스코프의 문제이며, 이 스코프는 익스프레션 평가에 있어서 대단히 중요한 개념입니다. 잠시

스코프에 대해 다룰 수 있겠지만, 지금은 이러한 사실만 알면 충분합니다. SourceComponent 의

프로퍼티는 SourceExpression 에서만 사용될 수 있으며, ControlComponent 의 프로퍼티는

ControlExpression 에서만 사용될 수 있다는 사실 말입니다.

메서드 (METHODS)

익스프레션 구성의 마지막 요소는 메서드입니다. 여러분이 호출할 수 있는 메서드의 종류에는 두

가지가 있습니다. 이 것은 커스텀 메서드(custom methods)와 익스프레션의 스코프 안에 있는 객체의

메서드입니다. 이 메서드 종류에 대해서 하나씩 알아보도록 합시다.




커스텀 메서드는 익스프레션 안에서 사용하기 위해 특별히 고안되었습니다. 그리고 커스텀 메서드는

익스프레션 엔진에 위해 평가됩니다. VCL 익스프레션 예제에서 ToStr 메서드는 두 번 사용되었고,

각각은 정수형 값을 문자열로 변환하는데 사용되었습니다. 그리고 이 변환된 값은 StatusBar 의

SimpleText 프로퍼티에 할당되는 문자열 익스프레션을 만들어 내기 위해 사용되었습니다.

라이브바인딩은 라이브바인딩에서 사용할 수 있는 유틸리티 커스텀 메서드들의 집합을 제공합니다.

BindingsList 컴포넌트에 대해 설명하는 곳에서 사용 가능한 커스텀 메서드의 목록을 보게 될

것입니다. 여러분이 새로운 커스텀 메서드를 작성할 수도 있습니다. 그리고 이 새 커스텀 메서드는

디자인타임 패키지에 의해 등록됨으로써 설치됩니다. 그러나 커스텀 메서드를 작성하여 등록하는

일은 어려운 작업이며, 스코프 안의 메서드를 사용하는 것이 훨씬 쉽기 때문에 보통 필요하지 않은

작업입니다.

스코프 안에 있는 객체의 메서드란 익스프레션 엔진이 인식할 수 있는 해당 객체의 public, published

메서드를 말합니다. 앞에서 본 VCL 예제를 생각해 봅시다. SourceControl 에는 폼이 지정되었고, 폼은

익스프레션 엔진의 스코프 안에 있습니다. 그래서 SourceExpression 에서 평가될 수 있습니다.

ClassName 은 호출될 때 클래스의 이름을 반환하는 클래스 함수입니다. ClassName 은 TObject 에

있는 메서드이며, TForm 과 같이 TObject 를 상속받은 클래스에도 존재합니다.

VCL 익스프레션 예제에서 우리는 ClassName 메서드를 객체를 지정하지 않고 호출하였습니다.

(Width, Height 프로퍼티에서 했던 것과 마찬가지로 말입니다.) 또한 Form 이 Self 변수를 사용하여

SourceControl 로 지정되었기 때문에, ClassName 함수를 호출할 수도 있습니다. (Self. ClassName())

메서드 뿐 아니라 프로퍼티도 Self 변수와 함께 사용할 수 있습니다.

스코프 안의 메서드를 사용하는데 있어서 두 가지 제약이 있습니다.

첫째로, 스코프 안의 메서드를 호출할 때, 항상 괄호를 포함시켜야 합니다. 메서드가 파라미터를

필요로 하지 않는 경우에도 말입니다. (델파이 코드에서처럼 ClassName 과 같이 괄호 없이 사용할 수

없습니다.)

둘째로, 앞에서 언급한 대로 메서드가 반드시 public 이나 published 여야 합니다.

메서드는 함수(functions)나 프로시저(procedures) 둘 다 될 수 있습니다. 메서드가 함수일 때,

메서드는 익스프레션과 일치하는 타입의 값을 반환하거나, 익스프레션 엔진의 출력 컨버터(output

converters)에 의해 변환된 값을 반환합니다. 이 것에 대해서는 다음에 논의할 것입니다. 메서드가

프로시저일 때, 그것은 nil 을 반환합니다.

익스프레션에서 호출할 수 있는 메서드를 작성하기 원한다면, ControlComponent 또는

SourceComponent 로 지정될 수 있는 클래스 안에 메서드를 추가하면 됩니다. 어떤 익스프레션

(ControlExpression 또는 SourceExpression)에서 사용하길 원하느냐에 따라서 말입니다.

어떤 경우에는 컨트롤이 직접 작성한 것이 아니라서 메서드를 추가하는 것이 불가능할 수도

있습니다. 그럴 때는 Form 클래스에 메서드를 추가할 수 있습니다. 이는 디자인 타임에 폼에 놓여진

컴포넌트에 있어서 유용한 테크닉입니다. 이 경우에 컴포넌트의 Owner 프로퍼티를 통해서




1 M

DM

폼(Form)의 메서드에 접근할 수 있습니다. 예를 들어, 여러분이 폼에 현재 시각을 문자열로 반환하는

메서드를 추가하였고, SourceComponent 가 디자인 타임에 폼에 추가한 Button 컴포넌트일 때,

익스프레션은 다음과 같을 수 있습니다.

"The time is " + Owner.GetCurrentTimeAsString()

직접 작성한 메서드를 라이브바인딩 익스프레션에서 호출할 수 있다는 것은 엄청난 일입니다. 그리고

이 문서에서 이러한 점을 반복해서 언급할 것입니다. 요약하면, 메서드 호출은 라이브바인딩이 부가

작용(side effects)을 수행할 수 있게 해줍니다. 이 부가 작용은 엄청난 능력의 원천이 될 수 있습니다.

이러한 능력은 프로퍼티 접근 메서드를 통해 구현될 수 있는 부가 작용과 흡사합니다. 이 부가

작용이 어떻게 게임의 판도를 바꿀 수 있는지, 어플리케이션에서 어떻게 이 기능을 구현할 수

있는지에 대해서는 이 문서의 ‘라이브바인딩의 미래’ 부분에서 다룰 것입니다.

저자의 노트: 라이브바인딩이 부가 작용을 만들어 낼 수 있다는 점은 저에게 있어서 돌파구였습니다.

라이브바인딩은 데이터의 변화에 반응하여 객체를 갱신할 수 있다는 것을 의미할 뿐 아니라, 변화의

강력한 원천이 될 수 있다는 것 또한 의미합니다. 아이러니하게, 저의 이 깨달음은 새벽 3 시에

일어났고, 제가 잠을 잘 수 없게 만들었습니다.

출력 컨버터 (OUTPUT CONVERTERS)

추가적인 주제로 넘어가기 전에, 커스텀 메서드와 관련된 개념인 출력 컨버터(output converters)에

대해 설명하고자 합니다. 커스텀 메서드처럼, 출력 컨버터는 평가된 익스프레션의 타입을 변환할 수

있는 특별한 루틴입니다. 반면에 커스텀 메서드와는 다르게, 출력 컨버터는 익스프레션 문자열 안에

포함되지는 않습니다. 대신에 출력 컨버터는 익스프레션 결과의 타입을 변환하기 위해

라이브바인딩에 의해 사용됩니다. 익스프레션의 대상(target) 프로퍼티가 평가된 익스프레션과 다른

데이터 타입일 때 말입니다.

스코프 (SCOPE)

스코프(Scope)는 익스프레션 엔진이 참조 가능한 객체를 정의합니다. 객체에 이름을 지정하거나,

이름이 없는 객체의 경우에는 객체를 Self 변수에 지정함으로써 말이죠. (이 Self 는 인스턴스 메서드

에서 사용되는 Self 변수와는 다릅니다.) 익스프레션 엔진은 적어도 하나의 스코프가 필요하지만,

라이브바인딩을 사용할 경우, 보통 입력 스코프(input scope)와 출력 스코프(output scope)를 둘 다

지정합니다. 예를 들어 객체의 한 프로퍼티를 동일한 객체의 또 다른 프로퍼티에 지정할 때와 같이

입출력을 하나의 스코프로 지정하는 것도 불가능한 것은 아닙니다. 또한 평가될 익스프레션이 상수인

경우처럼 입력 스코프 하나만 필요한 경우도 있습니다.

익스프레션 엔진은 자동으로 그 익스프레션의 입력 스코프에 사용 가능한 연산자를 추가합니다.

등록된 커스텀 메서드와 출력 컨버터를 입력 스코프에 추가하는 일은 라이브바인딩 컴포넌트들이

해야 합니다.




스코프는 추상화된 개념이라서 실전에서는 그렇게 걱정할 필요는 없습니다. 라이브바인딩

컴포넌트들은 보통 ControlComponent 와 SourceComponent 프로퍼티를 사용합니다. 대부분의 경우,

라이브바인딩은 ControlComponent 를 입력 스코프에, SourceComponent 를 출력 스코프에

추가합니다. (익스프레션의 평가 방향에 따라 다른 경우도 있습니다. 여기에 대해서는 나중에

알아보도록 합시다.) 대부분의 경우 이것이 여러분이 해야 할 일의 전부입니다. 같은 컴포넌트가

ControlComponent 와 SourceComponent 프로퍼티로 지정되었다면, 여러분은 입력과 출력을 위해서

동일한 스코프를 사용하고 있는 것입니다. 그 정도로 간단하게 생각하시면 됩니다.

하지만 많은 개발자들처럼 여러분이 RAD Studio 소스 코드를 들여다 본다면, 가장 일반적인 타입 중

하나인 IScope 인터페이스와 함께 스코프에 대한 참조를 반복적으로 보게 될 것입니다. 스코프는

익스프레션 엔진 영향권 안에 있는 모든 참조가능성을 의미합니다. 결과적으로, 이러한 스코프가

라이브바인딩 동작의 핵심입니다.

라이브바인딩의 개념

라이브바인딩은 컴포넌트와 익스프레션 엔진 간의 인터페이스를 제공합니다. DataSource 가

DataSet 과 데이터 인식 컨트롤 간의 교섭자 역할을 하듯이 말입니다. 이 절에서는 라이브바인딩

컴포넌트를 설정하는데 있어 일반적으로 사용하게 될 중요 프로퍼티들에 대해 설명하려고 합니다.

또한 익스프레션, 바인딩 방향 (binding direction), 관리(managed) 대 비관리(unmanaged)

라이브바인딩에 대해 알아볼 것입니다. 이러한 설명은 추후에 라이브바인딩 프레임워크의 개별

컴포넌트들에 대해 설명할 때, 그것을 이해하기 위한 기반이 될 것입니다.

컨트롤 컴포넌트와 소스 컴포넌트

대부분의 라이브바인딩은 컨트롤 컴포넌트가 필요하고, 소스 컴포넌트도 필요한 경우가 많습니다.

여기서 컨트롤 컴포넌트란 익스프레션이 적용될 객체를 말합니다. 이러한 라이브바인딩 컴포넌트의

경우, 컨트롤 컴포넌트와 소스 컴포넌트가 하나의 스코프 안에 있고, 이 스코프는 그들 각각을 래핑한

객체의 프로퍼티가 익스프레션 엔진에 사용 가능하도록 합니다.

각각의 라이브바인딩은 설정을 위한 4 개의 주요 프로퍼티를 가지며, 5 개의 프로퍼티를 갖는 경우도

있습니다. 4 개의 주요 프로퍼티는 ControlComponent, ControlExpression, SourceComponent,

SourceExpression 입니다. 5 번째 프로퍼티는 SourceMemberName 이고, BindScopeDB 컴포넌트일

경우에 사용 가능합니다.

라이브바인딩의 가장 간단한 컴포넌트인 TBindExpression 에 대해 알아보도록 하겠습니다.

ControlComponent 는 라이브바인딩과 연관된 컴포넌트이며, 이 컴포넌트는 보통 평가된

익스프레션의 결과가 할당될 프로퍼티를 갖습니다. 라이브바인딩은 하나의 ControlExpression 을

가지며, ControlExpression 은 평가된 익스프레션의 결과를 받기 위한 프로퍼티입니다.




1 M

DM

SimpleFireMonkeyLiveBindingsExample 프로젝트에서, ControlComponent 는 Label 이며,

ControlExpression 는 RotationAngle 입니다. 따라서, 이 설정은 “익스프레션이 평가되면, 결과 값을

Label 의 RotationAngle 에 할당하여라”라는 뜻입니다.

SourceControl 은 익스프레션의 평가를 위해 익스프레션 엔진에서 사용 가능한 프로퍼티를 갖는

컴포넌트입니다. BindExpression 라이브바인딩의 경우는 SourceExpression 이라는 이름의 단일 소스

익스프레션이 있습니다.

다시 SimpleFireMonkeyLiveBindingExample 프로젝트로 돌아가 보면, SourceComponent 는

TrackBar 이고, SourceExpression 은 TrackBar 의 위치를 나타내는 프로퍼티인 Value 입니다. 이

프로젝트에서 작성된 라이브바인딩은 “알림를 받았을 때, TrackBar 의 Value 프로퍼티를 평가하고, 그

값을 Label 의 RotationAngle 프로퍼티에 할당합니다.” 라는 뜻입니다.

SourceMemberName 는 SourceComponent 의 프로퍼티입니다. 그리고 SourceComponent 에

BindScopeDB 가 지정되었을 때에만 사용 가능한 프로퍼티입니다. SourceMemberName 은

BindScopeDB 가 DataSet 의 개별 필드를 노출시키는 것을 가능하게 합니다. BindScopeDB 와

SourceMemberName 프로퍼티에 대해서는 이 문서의 뒤에서 살펴볼 것입니다.

라이브바인딩 대 익스프레션

라이브바인딩의 세계에서 라이브바인딩과 익스프레션은 잘 구분해야 합니다. 라이브바인딩은 하나

이상의 익스프레션을 제공하는 컴포넌트입니다. 익스프레션은 익스프레션 엔진에 의해 평가되고,

라이브바인딩은 작업을 수행하기 위해 익스프레션의 평가 결과를 사용합니다.

이 문서의 앞에서 보았던 두 가지 간단한 예제의 경우 BindExpression 라이브바인딩이

사용되었습니다. BindExpressions 은 하나의 익스프레션을 제공하며, 그 결과로 하나의 값을 하나의

프로퍼티에 할당합니다. 그러나 대부분의 라이브바인딩은 다수의 익스프레션을 제공합니다. 그로

인해 하나의 라이브바인딩은 다수의 다른 프로퍼티에 영향을 미칠 수 있으며, 그 프로퍼티들은

하나가 아닌 다수의 다른 객체에 속해 있을 수도 있습니다.

추가적으로, 하나 혹은 그 이상의 익스프레션이 부가 작용(side effects)을 하는 메서드를 호출하거나

부가 작용을 하는 프로퍼티 접근 메서드로부터 값을 읽거나 쓸 경우에, 그 결과는 주목할 만한 것일

수 있습니다. 저는 여러분이 그것이 신나는 일임을 알게 되길 바랍니다.

컨트롤에서 소스로 그리고 반대로

지금까지 이 논의에서는 익스프레션 엔진은 항상 SourceComponent 의 SourceExpression 의 값을

ControlComponent 의 ControlExpression 에 할당해야만 하는 것처럼 여겨졌을 것입니다. 대부분의

익스프레션에서 그것이 기본 동작이지만, 반드시 그래야만 하는 것은 아닙니다. 라이브바인딩

컴포넌트에 따라서 소스에서 컨트롤로 값을 할당할 때도 있고, 컨트롤에서 소스로 할당할 때도 있고,

둘 다일 때도 있습니다.




우리가 다룬 첫 번째 라이브바인딩 타입인 바인드 익스프레션 컴포넌트(BindExpression 과

BindExprItems )에 지정된 익스프레션에 있어서는 이 말이 맞습니다. 리스트(List) 라이브바인딩처럼

좀더 고급의 라이브바인딩 타입은 단방향만 가능한 경우도 있습니다. 다시 특정 컴포넌트의 자세한

부분에 대해 다루도록 하겠습니다.

관리(MANAGED) 대 비관리(UNMANAGED) 라이브바인딩

SimpleVCLLiveBindingExample 프로젝트에 대한 절 마지막 부분에서, 이벤트 핸들러를 사용하기 위해

사용되던 전통적인 이벤트 핸들러와 라이브바인딩이 어떻게 다른지에 대해 설명했었습니다. 그

논의에서 몇몇 라이브바인딩은 이벤트 핸들러를 필요로 하지 않는다고 설명했었습니다. 이러한

이벤트 핸들러의 필요 여부는 관리와 비 관리 라이브바인딩의 차이에 따릅니다.

관리 라이브바인딩은 변화가 발생하였을 때 익스프레션 엔진에게 알릴 필요가 있으며, 알림이

자동으로 일어나지 않습니다. 관리 라이브바인딩을 사용할 때, 익스프레션 엔진에게 라이브바인딩을

다시 평가하고, 연관된 할당을 수행해야 한다는 것을 알리는 코드를 추가해야 합니다. 대부분의 경우,

이 알림을 위한 코드를 이벤트 핸들러에 추가하게 되며, 직접 작성한 클래스 안에서 실행하게 하는

것도 가능합니다.

익스프레션 엔진에게 알림을 보내는 데에는 몇 가지 옵션이 있습니다. uses 절에

System.Bindings.Helper 유닛을 추가한다면, Notify 클래스 함수를 호출하기 위해 TBindings 클래스를

사용할 수 있습니다. 이 함수에는 소스 컴포넌트의 참조와 영향 받을 프로퍼티의 이름을 포함하는

문자열과 (선택적으로) BindingsManager 참조를 인자로 넘겨줄 수 있습니다. 그러한 함수 호출의

예는 다음과 같습니다.

TBindings.Notify(TrackBar1, 'Position');

이 코드는 익스프레션 엔진에게 SourceExpression 에 Position 프로퍼티를 포함하는 TrackBar1 소스

컴포넌트와 연관된 익스프레션들을 평가하도록 지시합니다. 위와 비교하여, 아래의 함수 호출을

보도록 합시다.

TBindings.Notify(TrackBar1, '');

이 코드는 익스프레션 엔진에게 소스 컴포넌트인 TrackBar1 과 연관된 모든 익스프레션을 평가하라고

요청합니다. 구체적으로 두 번째 파라미터에 빈 문자열을 넘기게 되면, 지정된 SourceComponent 와

연관된 모든 익스프레션이 평가됩니다.

Notify 메서드는 세 번째 파라미터로 디폴트 값을 받습니다. 이 세 번째 파라미터를 생략하면,

AppManager 라는 이름을 가진 기본 BindingsManager 가 사용됩니다. 커스텀 BindingsManager 를

사용하려면, 이 세 번째 파라미터로 넘겨주면 됩니다. 대부분의 경우, 소수의 개발자만이 커스텀

BindingsManager 를 사용하기 때문에 Notify 메서드 호출에서 세 번째 파라미터를 보는 것이 매우

드뭅니다.




1 M

DM

직접 관리를 해야하는 관리 바인딩과는 다르게, 비관리 바인딩은 비관리 바인딩이 익스프레션

엔진에게 알림을 보내는 일을 하게 됩니다. 이로 인해, 비관리 바인딩은 VCL 데이터 인식 컨트롤들과

연관된 컴포넌트처럼 RAD Studio 의 전통적인 컴포넌트 바인딩과 유사점을 갖습니다.

비관리 바인딩은 옵저버(Observer) 디자인 패턴을 사용하여 동작하며, 비관리 라이브바인딩에 사용

가능한 컴포넌트에는 몇 가지 제약이 따릅니다. 그러나 RAD Studio 의 데이터 인식 컨트롤과는

다르게 라이브바인딩은 좀더 일반화된 프레임워크이며, 넓은 범위의 컴포넌트나 클래스에 바인딩

하는데 사용 가능합니다. RAD Studio 의 전통적인 바인딩 매커니즘은 훨씬 제한적이고, 특정한

컴포넌트 하위집합에만 적용할 수 있습니다.

라이브바인딩 컴포넌트를 보자면, Bind Expression 컴포넌트는 관리와 비관리 라이브바인딩을 둘 다

지원하지만, List 와 Link 라이브바인딩은 비관리 라이브바인딩만을 지원합니다.

라이브바인딩에서 사용할 수 있는 추가적인 클래스들도 있지만, 옵저버(observer)나 에디터(editor)

클래스를 포함한 대부분은 내부적으로 사용되는 클래스들입니다. 이들은 직접적으로 사용하는

컴포넌트는 아니지만, 라이브바인딩 소스 코드를 보다 보면 접하게 됩니다.

클래스

지금까지 라이브바인딩의 핵심 개념에 대해 알아보았습니다. 이제는 RAD Studio 의 툴 팔레트에서

볼 수 있으며 디자인 타임에 사용 가능한 다양한 컴포넌트들, 프로퍼티 에디터에서 볼 수 있는

클래스들에 대해 자세히 살펴봅시다. 시작으로 BindingsList 과 BindScope 에 대해서 알아보겠습니다.

그러고 나서 Bind Expression, List, Link 와 같은 라이브바인딩 컴포넌트에 대해 구체적으로

알아보겠습니다.

바인딩리스트 (BINDINGSLIST)

BindingsList 는 디자인 타임에 라이브바인딩과 함께 사용 가능한 유틸리티 컴포넌트입니다.

BindingsList 는 유용한 기능을 상당수 제공합니다. 상호작용적인 측면에서 보면, BindingsList

컴포넌트는 폼 위에 생성한 다양한 라이브바인딩에 접근하기 위한 편리한 인터페이스를 제공합니다.

그래서 BindingsList 는 폼 위의 라이브바인딩과 연관된 각각의 익스프레션에 접근하는데 사용할 수

있습니다.

코드: 이 프로젝트의 소스 코드는 이 문서와 함께 다운로드 할 수 있는 VCLLiveBindings 프로젝트

안에 존재합니다.

여러분이 툴 팔레트에 있는 BindingsList 컴포넌트를 직접 폼 위에 올려놓을 수도 있지만, 그것은

좀처럼 드문 일입니다. 폼 위에 라이브바인딩을 처음으로 생성할 때, RAD Studio 가 자동으로 폼에

BindingsList 을 추가하기 때문입니다. 이 문서의 시작 부분에서 제공한 예제를 따라 해 보았다면,

이에 대해 분명히 알 수 있을 것입니다.




폼 위에 BindingsList 가 있다면, 여러분은 모든 라이브바인딩과 그 라이브바인딩의 익스프레션의

목록에 접근할 수 있습니다. 이 목록에 접근하기 위해서는 BindingsList 컴포넌트를 더블 클릭하거나

BindingsList 컴포넌트에서 오른쪽 클릭을 하고 Binding Components 를 선택하면 됩니다. 그러면

BindingsList 는 그림 8 에서와 같은 BindingsList 컴포넌트 에디터를 표시합니다.

그림 8. BindingsList 컴포넌트 에디터

위 화면은 VCLLiveBindings 프로젝트의 BindingsList 에 대한 컴포넌트 에디터입니다. 보다시피 왼쪽

패널에서 디자인 타임에 설정되는 모든 라이브바인딩을 선택할 수 있습니다. 또한 라이브바인딩의

특정 클래스를 선택할 수도 있습니다. 선택한 카테고리에 따라 (또는 All LiveBindings), BindingsList

컴포넌트 에디터는 오른쪽 패널에 표시되는 라이브바인딩을 필터링 할 수 있습니다.

또한 BindingsList 컴포넌트 에디터를 폼에 있는 라이브바인딩을 추가하거나 삭제하는데 사용할 수도

있습니다. BindingsList 컴포넌트 에디터에서 라이브바인딩을 추가하려면, 마우스 오른쪽 클릭 후

New LiveBinding 선택하거나, Ins 키를 누르거나, 에디터 상단의 툴바에서 Add New Binding 버튼을

클릭하면 됩니다. 라이브바인딩을 삭제하려면, 삭제하려는 라이브바인딩을 선택한 후 Del 키를

누르거나, 오른쪽 클릭 후 Delete 를 선택하거나, 에디터 상단의 툴바에서 Delete 버튼을 클릭하면

됩니다. 그러나 대부분의 개발자는 이 문서의 앞에서 본 것처럼 컨트롤에 직접적으로 라이브바인딩을

추가합니다.

그림 8 에는 개별 익스프레션들이 보이지는 않지만, BindingsList 컴포넌트 에디터의 왼쪽 패널의

라이브바인딩 중 하나를 더블 클릭하게 되면 개별 익스프레션들을 볼 수 있습니다. 그림 9 는 그림

8 의 BindingsList 컴포넌트 에디터에서 BindGridListStringGrid21 를 더블 클릭했을 경우의 모습을

보여줍니다. 이 라이브바인딩은 BindGridList 라이브바인딩이며, 현재 버전의 RAD Studio 에서 가장

복잡한 라이브바인딩 중의 하나입니다.




1 M

DM

그림 9. 익스프레션 에디터

익스프레션 에디터는 여러분이 자주 사용하게 될 대화상자이며, BindingsList 컴포넌트 에디터를

사용하는 것 외에 익스프레션 에디터를 표시하기 위한 다른 방법들도 있습니다. 또한 라이브바인딩의

ControlComponent 로 지정된 컴포넌트를 선택하고, LiveBindings 프로퍼티 부분을 펼쳐서, 그림

10 에 보이는 것과 같은 드랍다운 프로퍼티 에디터로부터 Expressions...을 선택할 수도 있습니다.




그림 10. Expressions...를 선택함으로써 익스프레션 엔진에 접근할 수 있습니다.

라이브바인딩과 익스프레션을 보기 위한 다른 방법들도 있으며, 라이브바인딩 컴포넌트들을

살펴보면서 계속해서 설명할 것입니다. 그렇더라도 BindingsList 는 확실히 가장 편리한 컴포넌트

중의 하나이며, 현재 폼에 설정한 모든 라이브바인딩을 쉽게 보기 위한 유일한 방법입니다.

직접 설정한 라이브바인딩에 접근할 수 있게 하는데 더해서, BindingsList 은 대부분의 라이브바인딩

어플리케이션에서 또 다른 중심적인 역할을 수행합니다. BindingsList 는 관리 라이브바인딩과 작업할

때, 익스프레션 엔진에게 알림을 보내기 위해 호출하는 Notify 메서드를 가지고 있습니다.

BindingsList 의 Notify 메서드는 TBindings 와 동일한 함수 인자를 가지고 있으며, TBindings 보다

사용하기 쉽습니다.

TBindings 의 Notify 메서드를 사용하기 위해서, uses 절에 System.Bindings.Helper 유닛을 추가해야

한다는 것을 기억해야 합니다. 이와는 대조적으로, BindingsList 클래스는 라이브바인딩이 폼에

추가될 때 해당 폼에 자동으로 추가되며, 폼을 저장하거나 컴파일할 때, Data.Bind.Components

유닛이 uses 절에 자동으로 추가됩니다.




1 M

DM

BindingsList 가 제공하는 또 다른 기능이 있습니다. 각각의 커스텀 메서드와 출력 컨버터를 보고,

비활성화시킬 수 있는 기능입니다. 익스프레션 엔진에서 사용 가능한 커스텀 메서드를 보기 위해서는,

오브젝트 인스펙터의 BindingsList 의 Methods 프로퍼티에 있는 생략 부호(…)를 선택하면 됩니다.

RAD Studio 는 그림 11 에 보이는 것과 같은 프로퍼티 에디터를 표시합니다.

그림 11. 메서드 프로퍼티 에디터는 등록된 커스텀 메서드들을 표시합니다.

Methods 프로퍼티 에디터에 표시되는 각각의 메서드는 체크박스를 가지고 있습니다. 메서드가

체크되어 있다면, 그 메서드는 익스프레션 엔진에 의해 호출될 수 있습니다. 등록된 커스텀 메서드들

중 입력이나 출력 스코프에서 사용할 객체의 프로퍼티와 이름이 겹치는 것이 있다면, 체크박스를

체크 해제하여 메서드를 비활성화시킬 수 있습니다.

등록된 출력 컨버터를 보기 위해서는, BindingsList 의 OutputConverters 프로퍼티의 생략 부호(…)를

선택하면 됩니다. 출력 컨버터(Output Converters) 프로퍼티 에디터는 그림 12 에서 보이는 것과

같습니다.




그림 12. 출력 컨버터(Output Converters) 프로퍼티 에디터는 등록된 출력 컨버터를 표시합니다.

바인드스코프 (BINDSCOPE)

앞서 설명했듯이, 익스프레션 엔진은 제대로 동작하기 위해서 하나 이상의 스코프가 필요합니다.

예를 들어, 입력 스코프가 없다면, 익스프레션 엔진은 익스프레션에 제공된 리터럴과 자동으로

추가된 연산자만 가지고 동작해야 합니다. 여러분이 스코프를 추가할 때, 익스프레션에서 사용될 수

있는 프로퍼티와 메서드를 가진 객체를 넘겨줄 수 있습니다.




1 M

DM

툴 팔레트에 있는 두 개의 컴포넌트는 특별히 익스프레션 엔진에 풍부한 스코프를 제공하기 위해

디자인되었습니다. 그 중 하나인 BindScope 컴포넌트는 스코프 안의 객체를 래핑하는데 사용됩니다.

래핑된 객체는 여러분이 스코프에 래핑된 객체를 직접 추가했는지 와는 관계없이 확장 기능을

제공합니다. 예를 들어, BindScope 는 IScopeEnumerator 에 대한 지원을 추가합니다.

IScopeEnumerator 인터페이스는 익스프레션이 래핑된 컴포넌트의 IEnumerable 멤버를 받을 수

있도록 합니다.

BindScope 컴포넌트들(BindScope, BindScopeDB)의 다른 기능은 라이브바인딩 활성화(activation)

기능을 제공하는 것입니다. 이 라이브바인딩 활성화는 BindScope 컴포넌트에 연결된 라이브바인딩

컴포넌트의 AutoActive 와 Active 프로퍼티를 사용합니다. BindScope 가 활성화될 때, BindScope 를

SourceComponent 로 지정하고, AutoActivate 프로퍼티를 True 로 설정한 모든 라이브바인딩이

활성화되며, BindScope 가 비활성화될 때는 마찬가지로 연관된 컴포넌트 또한 비활성화됩니다.

BindScope 컴포넌트가 기능적으로 제한적인데 비해, BindScopeDB 컴포넌트는 그렇지 않습니다.

BindScopeDB 는 BindScope 의 특화된 타입이며, RAD Studio 의 DataSet 인터페이스를 사용할 수

있습니다. 구체적으로 말하면, BindScopeDB 는 DataSource 에 연결하는 법을 알고 있으며, RAD

Studio 의 VCL 데이터 인식 컴포넌트들을 동작하게 하는 DataLink 인터페이스의 기본적인 연산을

사용할 수 있습니다.

이것이 중요한 부분이지만, 깊이 생각할 필요는 없습니다. 구체적으로 BindScopeDB 가 하는 일에

대해 말하자면, 일반적인 컴포넌트들이 RAD Studio 의 데이터 인식 매커니즘과 상호작용할 수

있도록 합니다. 심지어 VCL 자체가 존재하지 않을 때에도 말입니다. 예를 들어, BindScopeDB 는

dbExpress 뿐 아니라 ClientDataSet 클래스도 Mac OS 를 대상으로 컴파일 하고자 하는 개발자에게

사용 가능하게 합니다. BindScopeDB 는 파이어몽키 컨트롤을 DataSet 에 바인딩 가능하게 합니다.

파이어몽키에는 VCL 데이터 인식 컨트롤이 존재하지 않지만, BindScopeDB 가 데이터 인식 기능을

제공하게 됩니다.

이 것은 사소해 보일 수도 있지만, 그렇지 않습니다. 라이브바인딩은 RAD Studio 의 ClientDataSet

컴포넌트와 dbExpress 프레임워크에 이미 존재하는 강력한 기능들을 모든 컴포넌트로 확장하게

해줍니다. 이것은 윈도우즈가 아닌 플랫폼을 대상으로 하는 어플리케이션에 있어서 필수적인

부분입니다. 한편으로, BindScopeDB 는 ListBox, ListView 와 같은 VCL 컴포넌트에 데이터 인식

기능을 추가할 수 있게 해줍니다.

바인드 익스프레션 (BIND EXPRESSIONS)

지금까지 언급했던 컴포넌트들은 라이브바인딩 프레임워크의 컴포넌트이지만, 특정한 라이브바인딩

컴포넌트는 아니었습니다. 다시 말하면, 그 컴포넌트들은 라이브바인딩을 지원하지만,

라이브바인딩을 구현하지는 않았습니다. 아래의 절에서 언급할 List, Link 컴포넌트 뿐 아니라 Bind

Expression 컴포넌트들은 디자인 타임에 라이브바인딩을 생성하기 위해 사용할 수 있는

라이브바인딩 컴포넌트입니다.




Bind Expression 컴포넌트의 외양에 속하는 두 가지 컴포넌트가 있습니다. 바로 BindExpression,

BindExprItems 입니다. 이 라이브바인딩 컴포넌트는 관리 또는 비관리 라이브바인딩으로 설정될 수

있지만, RAD Studio 어플리케이션에서는 거의 항상 관리 컴포넌트로 사용됩니다. 이는

라이브바인딩을 설정해야 할 뿐 아니라, 익스프레션 엔진에게 라이브바인딩 익스프레션을 평가하고

목표 대상에 결과 값을 할당하라고 알리는 코드를 작성해야 한다는 것을 뜻합니다.

BindExpression 과 BindExprItems 는 한가지 방식에서 서로 다릅니다. BindExpression 컴포넌트는

하나의 익스프레션만 지원하지만, BindExprItems 는 여러 개의 익스프레션을 지원합니다. 각각의

익스프레션은 하나의 익스프레션 (문자열)을 평가하고, 그 값을 목표 대상에 할당할 수 있는 기능을

갖습니다. 이 목표 대상은 보통 ComponentExpression 이며, SourceExpression 일 수도 있습니다.

VCLLiveBindings 프로젝트에 정의된 BindExpression 에 대해 살펴보겠습니다.

BINDEXPRESSION

BindExpression 은 하나의 익스프레션과 할당만 지원하기 때문에, 여러분은 보통 하나의

익스프레션을 다른 컨트롤의 프로퍼티에 연결할 때 BindExpression 을 사용하게 됩니다.

VCLLiveBindings 프로젝트에서, BindExpression 은 TrackBar 의 Position 프로퍼티를 ProgressBar 의

Position 프로퍼티에 연결할 때 사용되었습니다.

이 라이브바인딩을 처음부터 새로 만들고 싶다면, TrackBar 와 ProgressBar 를 폼 위에 올려 놓은

상태에서 아래와 같은 단계를 따라야 합니다.

1. 첫 번째 단계는 어떤 컴포넌트를 ControlComponent 로 지정할 지, SourceComponent 로 지정할

지를 결정하는 것입니다. 대부분의 라이브바인딩은 값을 ControlComponent 에 할당합니다. 이

경우에 ProgressBar 를 ControlComponent 로 지정해야 합니다. (사용자는 유저 인터페이스에서

ProgressBar 를 조작할 수 없기 때문입니다.)

2. ProgressBar 에서 오른쪽 클릭을 하고, New LiveBindings 를 선택합니다. 그러면 그림 1 에서

보았던 것과 같은 New LiveBinding 대화상자가 표시됩니다. 여기서 BindExpression 을 선택합니다.

3. 새로운 BindExpression 이 오브젝트 인스펙터에 선택되었습니다. SourceComponent 에

TrackBar1 을, SourceExpression 에 Position 을, ControlExpression 에 Position (ProgressBar 의

Position)을 설정합니다. 또한 TrackBar1 의 Max 프로퍼티를 설정하길 원할 수도 있으며, 그 설정은

TrackBar1 의 Max 프로퍼티와 ProgressBar 의 Max 프로퍼티를 일치하게 만듭니다. 이것이

라이브바인딩에 대해 하는 모든 작업이지만, 이 라이브바인딩은 인상적인 결과를 보여줍니다.

4. 라이브바인딩이 모두 설정되었지만, 이 라이브바인딩이 관리 바인딩이기 때문에 익스프레션

평가를 위해 익스프레션 엔진에게 알림을 보내야 합니다. OnChange 이벤트 핸들러를 만들기 위해

TrackBar 를 더블 클릭합니다. 생성된 이벤트 핸들러 코드를 아래와 같이 수정합니다. 이는

익스프레션 엔진에게 알림을 보내기 위함입니다.





1 M

DM

begin

BindingsList1.Notify(TrackBar1, 'Position');

end;

5. 라이브바인딩에 대한 모든 작업이 끝났습니다. 이제 프로젝트를 실행합니다. TrackBar 의 위치값을

변경할 때, 그림 13 에서 확인할 수 있듯 ProgressBar 도 TrackBar 에 맞춰 변경됩니다.

그림 13. BindExpression 은 ProgressBar 를 TrackBar 에 맞춰 동기화합니다.

BindExpression 라이브바인딩이 하나의 익스프레션만 지원한다는 것을 보기 위해서는

BindExpression 라이브바인딩의 익스프레션 에디터를 보면 됩니다. 앞서 언급했던 것처럼, 여러분이

디자인타임에 첫 번째 라이브바인딩을 추가하고 나면 폼에 자동으로 추가되는 BindingsList 를 통해

이를 확인할 수 있습니다.

이 에디터를 표시하기 위한 몇 가지 방법이 더 있습니다. 예를 들면, 라이브바인딩을 생성한 뒤에,

정의된 라이브바인딩을 선택하는데 오브젝트 인스펙터의 오브젝트 셀렉터를 사용할 수 있습니다.

(오브젝트 셀렉터는 오브젝트 인스펙터의 상단에 위치한 콤보박스입니다.) 라이브바인딩이

선택되었을 때, ‘Expressions...’ 이라는 레이블을 가진 링크가 그림 14 와 같이 오브젝트 인스펙터의

하단에 표시됩니다.




그림 14. 라이브바인딩을 선택했을 때, 익스프레션 에디터를 표시하기 위해서 오브젝트 인스펙터에

표시되는 Expressions... 링크를 사용합니다.

익스프레션 에디터를 표시하기 위해서 Expressions... 링크를 클릭합니다. 그림 15 에 보이는

익스프레션 에디터는 오브젝트 인스펙터에 BindExpression 이 선택되었을 때 표시되는 것 중에

하나입니다. 익스프레션 에디터의 툴바가 비활성화되어 버튼들이 회색인 것에 주목하십시오. 게다가

그림 15 의 왼쪽 부분을 보면 알 수 있듯이 컬렉션을 표시하기 위한 패널도 없습니다. 다시

강조하지만, 이는 BindExpressions 이 오직 하나의 익스프레션만 지원하기 때문입니다.




1 M

DM

그림 15. BindExpression 의 익스프레션 에디터는 오직 하나의 익스프레션만을 포함할 수 있습니다.

VCLLiveBindings 프로젝트는 추가적인 BindExpression 라이브바인딩을 포함합니다. 이

라이브바인딩은 여러분이 어플리케이션의 동작을 구현하기 위해 생각하는데 있어 새로운 방법을

제공하고, 라이브바인딩이 RAD Studio 에서 사용 가능한 다른 매커니즘과는 어떻게 다른지에 대해

강조한다는 점에서 특별합니다. 결과적으로 저는 BindExpression 라이브바인딩에 대한 논의를 이

문서의 뒤에 있는 ‘라이브바인딩의 미래’라는 절을 위해 줄이겠습니다.

관리 라이브바인딩이 여러 개의 익스프레션을 평가할 필요가 있다면, 아래에서 설명할

BindExprItems 라이브바인딩을 사용하면 됩니다.

BINDEXPRITEMS

VCLLiveBindings 프로젝트는 두 개의 익스프레션을 가진 BindExprItems 을 포함합니다. 이

라이브바인딩의 첫 번째 익스프레션은 Value1Edit 에디트 컴포넌트의 내용을 Value2Edit 에디트

컴포넌트와 동기화된 상태로 유지하는 역할을 합니다. 두 번째 익스프레션은 Value2Edit 에디트

컴포넌트의 내용을 Value1Edit 에디트 컴포넌트와 동기화된 상태로 유지하는 역할을 합니다. 그림

16 은 이러한 BindExprItemsEdit21 라이브바인딩이 선택되었을 때의 익스프레션 에디터를

보여줍니다.




그림 16. BindExpression 라이브바인딩을 제외한 다른 모든 라이브바인딩들은 하나 이상의

익스프레션을 지원합니다.

그림 16 은 라이브바인딩의 풍부함을 보여줍니다. 컬렉션 패널에 Format, Clear 라는 두 가지 타입의

컬렉션이 있는 것에 주의해야 합니다. Format 컬렉션은 라이브바인딩이 활성화될 때 값을

할당하는데 사용되는 익스프레션들을 포함하고 있습니다. 그리고 이 익스프레션들은 컨트롤과 소스

컴포넌트, 컨트롤과 소스 익스프레션, 할당의 방향에 대해 기술하고 있습니다. 대조적으로, Clear

컬렉션은 라이브바인딩이 비활성화될 때 값을 할당하는데 사용되는 익스프레션들을 포함하고

있습니다.

Format 익스프레션들은 라이브바인딩의 대부분의 어려운 일들을 처리합니다. 대부분의

라이브바인딩이 생성 시에 활성화되는 것을 의미하는 AutoActivate 프로퍼티가 True 로 설정되기

때문입니다. 그러나 SourceComponent 가 BindScope 이고, 활성화 됐다 비활성화 됐다 하는

라이브바인딩을 위해서, Clear 익스프레션은 평가되고 있는 익스프레션에 근거하여 연관된

컴포넌트들을 리셋 할 수 있습니다. Clear 익스프레션은 활성화 상태를 비활성화 상태로 바꿀 수 있는

(또는 그 반대로 할 수 있는) DataSet 과 연관된 라이브바인딩을 사용할 때 좀더 유용합니다.

그렇더라도, 여러분이 이 기능이 필요하다면, BindExprItem 라이브바인딩이 이러한 컬렉션을

지원한다는 사실에 고마워 해야 할 것입니다.

다시 BindExprItemsEdit21 BindExprItems 라이브바인딩으로 관심을 돌려보면, 저는 그 예제에 대해

할 이야기가 있습니다. 이 경우에는 두 개까지 익스프레션이 필요하지는 않았고, 한 개로도

충분했습니다. 이러한 사실은 VCL LiveBindings 프로젝트에 있는 BindExprItemsValue3Edit1

BindExprItem 라이브바인딩이 보여줍니다.

이 라이브바인딩은 Value 3 과 Value 4 라는 라벨을 가진 에디트 컴포넌트를 바인딩 합니다. 여기

있는 하나의 익스프레션은 BindExprItemsEdit21 BindExprItem 라이브바인딩과 연관된 두 개의

익스프레션이 수행하는 것과 같은 작업을 수행합니다. 이 익스프레션은 양방향성(bidirectional)

익스프레션입니다. 익스프레션 엔진이 알림을 받을 때, Value3Edit 컴포넌트의 Text 프로퍼티의

변화는 Value4Edit 에디트 컴포넌트의 Text 에 할당됩니다. 그리고 그 반대의 경우도 마찬가지입니다.

이 라이브바인딩과 연관된 단일 익스프레션은 그림 17 의 익스프레션 에디터에서 볼 수 있습니다.




1 M

DM

그림 17. 양방향성(bidirectional) 익스프레션은 익스프레션 에디터에 보여집니다.

BindExprItems 익스프레션이 반드시 양방향성이지는 않습니다. 예를 들어, ControlExpression 과

SourceExpression 은 둘 다 그들 각각의 객체의 프로퍼티를 읽거나 쓸 수 있어야 합니다. 만약

여러분의 SourceExpression 이 리터럴과 연산자를 포함한다면, 익스프레션 엔진이 값을 양방향으로

할당하는 (dirBidirectional) 방법이나 컨트롤에서 소스로 값을 할당하는 (dirControlToSource) 것은

불가능합니다. 이와 비슷하게, 익스프레션 중 하나가 읽기전용 프로퍼티를 포함한다면, 그

익스프레션에 값을 할당할 수 있는 방법은 없습니다.

리스트 라이브바인딩 (LIST LIVEBINDINGS)

바인드 익스프레션으로도 할 수 있는 일이 많지만, 더욱 복잡한 라이브바인딩을 사용하기 위한

흥미로운 부분들에 대해 알아보도록 합시다. 이 절에서 저는 리스트(List) 라이브바인딩에 대해

설명할 것입니다. BindList 와 BindGridList 라는 두 개의 리스트 라이브바인딩이 있습니다.

이름이 말해주듯이, 리스트 라이브바인딩은 익스프레션의 값을 리스트나 그리드에 할당하기 위해

사용됩니다. 이 라이브바인딩들은 단방향성을 갖습니다. SourceComponent 의 SourceExpression 의

변화는 ControlComponent 의 ControlExpression 를 변화시킬 수는 있지만, SourceComponent 의

SourceExpression 에게 영향을 줄 수는 없습니다.

리스트 라이브바인딩은 BindExprItems 와 몇가지 공통점을 가지고 있습니다. 구체적으로, 리스트

라이브바인딩은 익스프레션 컬렉션을 지원하며, 여러분이 ControlComponent 의 다수의 프로퍼티에

값을 할당할 수 있도록 다수의 익스프레션을 정의할 수 있게 합니다. 예를 들어, BindExprItems 과

리스트 라이브바인딩은 모두 Format 과 Clear 익스프레션 컬렉션을 지원합니다.

좀더 나아가서 리스트 라이브바인딩은 리스트와 그리드 컨트롤의 기초가 되는 리스트 클래스와도

동작할 수 있도록 디자인되었습니다. ListBox, ComboBox, ListView, StringGrid 클래스와도 말이죠.

리스트 라이브바인딩은 익스프레션의 값을 클래스 내부 멤버에 할당하도록 설정할 수 있는

익스프레션 컬렉션을 제공함으로써 이러한 일을 합니다.




리스트 라이브바인딩이 바인드 익스프레션과 다른 또 하나의 측면은, 리스트 라이브바인딩이

BindScope 를 자주 사용한다는 것입니다. (대부분의 어플리케이션에서 BindScopeDB 를 사용합니다.)

BindScope 컴포넌트는 리스트나 그리드 구조를 가진 객체에 데이터를 바인딩하기 위해 리스트

라이브바인딩과 함께 사용될 수 있습니다. 이는 가능한 일이긴 하지만, 적어도 RAD Studio 의 현재

버전에서는 항상 리스트 라이브바인딩을 BindScopeDB 와만 사용하게 될 것입니다. 여러분의

리스트나 그리드 객체가 내부의 DataSet 의 데이터를 표시하는데 있어서 말이죠. 반면에 여러분이

리스트에 제네릭 TList<T>와 같은 열거형 객체의 내용을 채우기 원한다면, TBindScope 를 사용하고

런타임에 DataObject 프로퍼티를 설정할 수 있습니다.

VCLLiveBindings 프로젝트는 BindList 와 BindGridList 라이브바인딩의 사용 예를 모두 포함하고

있습니다. 이제 BindList 컴포넌트에 대해 알아보도록 합시다.

BINDLIST

앞에서 언급했다시피, 대부분의 리스트 라이브바인딩의 사용에 있어서 BindScopeDB 와 DataSet 을

사용하게 됩니다. 그리고 이는 VCLLiveBindings 프로젝트에서도 마찬가지입니다. 이 예제에서 사용된

BindScopeDB 와 DataSet 은 BindLink 의 데모에서도 사용되며, 아래의 절에서 좀더 자세히 설명할

것입니다. 따라서 데이터 관련 컴포넌트들을 설정하는 방법에 대해서 잠시 설명하도록 하겠습니다.

BindScopeDB 는 DataSource 의 대체품이 아님에도 DataSource 와 같은 역할을 수행합니다. 사실

BindScopeDB 는 DataSet 과 직접 연결되지 않습니다. 대신에 DataSource 와 연결되고,

DataSource 는 DataSet 과 연결됩니다.

VCLLiveBindings 프로젝트는 DataSet 으로 ClientDataSet 을 사용하고, 데이터의 소스로 샘플

ClientDataSet *.cds 파일을 사용합니다. 이 프로젝트에서 사용되는 샘플 cds 파일은

sampledata.cds 이고, 컴파일 될 실행파일과 같은 디렉토리에 위치합니다. 이 프로젝트의 메인 폼의

OnCreate 이벤트 핸들러에 있는 아래의 코드는 ClientDataSet 의 FileName 프로퍼티를 설정합니다.

(ClientDataSet 은 여기서 열리지 않고, 라이브바인딩에 의해 열립니다.)

procedure TForm1.FormCreate(Sender: TObject);

begin

ClientDataSet1.Close;

LogChanges := False;

ClientDataSet1.FileName :=

ExtractFilePath(Application.ExeName) + 'sampledata.cds';

end;

저자의 노트: ClientDataSet 의 FileName 프로퍼티를 설정할 경우, 디자인 타임에 ClientDataSet 를

활성화시킬 수 있습니다. 이는 또한 디자인타임에 리스트와 그리드를 채울 수 있는 라이브바인딩의

기능을 사용할 수 있도록 합니다. 이 테크닉이 유용하지만, cds 파일의 전체 경로와 이름이 FileName

프로퍼티에 지정되어야 함을 뜻합니다. 저는 이 프로퍼티를 비워두었고, 런타임에 현재 실행파일의

위치를 기준으로 cds 파일이 저장된 디렉토리를 얻어와서 설정하도록 하였습니다. 이렇게 하는 것이

예제 어플리케이션을 실행할 때 발생하는 문제를 최소화할 수 있게 해주기 때문입니다.




1 M

DM

이제 이 폼에서 사용된 BindList 에 대해 알아보도록 합시다. BindList 는 ClientDataSet 의 내용을

표시하는 리스트박스를 만들 수 있게 해줍니다. 이 바인딩의 결과는 그림 18 에서 볼 수 있으며,

리스트박스의 각 원소는 익스프레션 평가의 결과를 표시합니다.

그림 18. ListBox 와 StringGrid 는 각각 BindList 와 BindGridList 에 의해 데이터가 표시됩니다.

BindList 를 설정하는 방법은 그림 19 의 익스프레션 에디터에서 볼 수 있습니다. 여기에서 세 가지

익스프레션 컬렉션을 볼 수 있습니다. BindList 라이브바인딩은 BindExprItems 와 마찬가지로 Format

컬렉션이 있습니다. 그러나 BindExprItems 과는 다르게 BindList 라이브바인딩은

ControlComponent 의 Strings 프로퍼티에 적용됩니다.

그림 19. BindList 는 세가지 익스프레션 컬렉션을 제공합니다.




다른 두 개의 컬렉션은 FormatControl 과 ClearControl 이며, 리스트박스 자체에 적용됩니다.

FormatControl 은 라이브바인딩이 활성화될 때 익스프레션을 적용하기 위해 사용되며, ClearControl

익스프레션은 라이브바인딩이 비활성화될 때 적용하기 위해 사용됩니다. BindListListBox31

라이브바인딩의 경우, 하나의 Clear 익스프레션이 있으며, 이것은 라이브바인딩이 비활성화될 때

리스트박스를 비우도록 합니다. SourceExpression 은 빈 문자열 ('"")이며, ControlExpression 는

Items.Text 입니다. 다시 말하자면, DataSet 이 닫힐 때 리스트박스의 모든 아이템이 지워질 것입니다.

BindList 라이브바인딩의 세 번째 컬렉션은 FormatControl 입니다. FormatControl 은

ControlComponent 의 리스트보다는 ControlComponent 자체에 적용되는 익스프레션의 컬렉션을

담을 수 있습니다. 이번 경우의 리스트박스에서는 FormatControl 익스프레션을 사용하지는 않지만

FormatControl 익스프레션의 예를 이 문서에서 조금 뒤에 설명할 것입니다.

BindListListBox31 라이브바인딩의 대부분의 작업은 단일 Format 익스프레션에 의해 수행됩니다.

그림 19 에서 볼 수 있는 대로, SourceExpression 은 FirstName, LastName, City, State 필드를 그림

18 의 리스트 박스에 보이는 것과 같은 문자열 형태로 연결할 수 있습니다.

이 익스프레션은 BindScopeDB 의 몇 가지 능력을 보여줍니다. BindScopeDB 는 그것이 지정한

(DataSource 일지라도) DataSet 의 개별 필드들을 SourceComponent 와 연관된 스코프 안에서

사용할 수 있도록 해줍니다. 그 결과로 DataSet 의 필드는 익스프레션 안에서 쉽게 사용될 수

있습니다. 이 Format 익스프레션은 그림 19 에서 볼 수 있습니다.

이는 두 개의 익스프레션을 포함하는 간단한 BindList 입니다. BindList 는 익스프레션의 평가 결과를

리스트박스의 다양한 프로퍼티에 적용하기 위해서 다수의 익스프레션을 가질 수도 있습니다. 그러나

실질적으로 대부분의 BindList 는 리스트 형태의 컨트롤의 내용을 채우거나 지우기 위해 사용됩니다.

결과적으로 이러한 라이브바인딩 사용 형태가 일반적입니다.

BINDGRIDLIST

그러나 BindGridList 는 BindList 가 사용되는 형태와는 많이 다릅니다. StringGrid 와 다른 그리드 관련

컨트롤들은 훨씬 복잡합니다. 그 결과로 그리드 관련 컨트롤에 대해 설정하는 라이브바인딩은 보통

많은 수의 익스프레션을 가집니다. 그림 18 에 보여지는 라이브바인딩과 연관된 StringGrid 는 이것의

좋은 예입니다.

BindGridListStringGrid21 은 그림 20 에 보이는 대로 연관된 10 개의 익스프레션을 가지고 있습니다.

BindList 라이브바인딩과 같이, FormatControl 컬렉션은 라이브바인딩이 활성화될 때 그리드에

적용되는 익스프레션들을 제공합니다.




1 M

DM

그림 20. 익스프레션 에디터 안의 BindGridList 라이브바인딩의 익스프레션

세 번째 컬렉션인 Columns 는 익스프레션 컬렉션들의 컬렉션입니다. 음, 좀더 정확히 말하자면,

Columns 는 컬렉션들의 컬렉션들의 컬렉션입니다. 보통 여러분은 사용할 그리드의 각각의 컬럼에

하나의 컬럼 컬렉션을 추가합니다. 각각의 컬럼은 ColFormat 과 CellFormat 컬렉션을 가지고 있고, 그

컬렉션은 0 개 혹은 그 이상의 익스프레션을 제공할 수 있습니다. 보통 ColFormat 익스프레션은

익스프레션들을 개별 컬럼 전체에 적용하기 위해 사용됩니다. 이와 대조적으로 CellFormat

익스프레션은 익스프레션들을 컬럼과 연관된 개별 셀(cell)에 적용하기 위해 사용됩니다.

다시 컬럼 컬렉션에 대해 알아보자면, 여기서 우리는 마침내 SourceMemberName 프로퍼티를 보게

됩니다. BindGridList 와 함께 SourceMemberName 프로퍼티는 그리드의 특정 컬럼을

BindScopeDB 에 의해 참조되고 있는 DataSet 안의 특정 필드 이름과 연관 짓습니다.

BindGridListStringList21 라이브바인딩에 대해서 세 가지 컬럼이 ClientDataSet 의 FirstName,

LastName, City 필드와 연관되어 있습니다. 그리고 이 값들은 각각의 컬럼 컬렉션에 대한

SourceMemberName 프로퍼티에 보여집니다.

지금까지 여러분이 많은 라이브바인딩 익스프레션을 보아왔기에 아마도 익스프레션 에디터의

내용을 보는데 능숙할 것입니다. 그림 20 안의 익스프레션을 보도록 합시다. 두 개의 FormatControl

익스프레션이 있는데, 하나는 DataSet 이 활성화될 때 그리드를 보이도록 하고, 다른 하나는 컬럼의

개수를 설정합니다. 또한 ClearControl 도 있습니다. 이는 DataSet 이 비활성화될 때 그리드를 보이지

않게 합니다.

컬럼 컬렉션 안에는 네 개의 컬럼이 있고, 각각은 그것의 ColFormat, CellFormat 컬럭션 안에 적어도

하나의 익스프레션을 가지고 있습니다. ColFormat 익스프레션은 컬럼 헤더의 텍스트를 설정하며,

CellFormat 은 현재 셀에 DataSet 안의 SourceMemberName 필드와 연관된 데이터를 할당합니다.

그림 18 에서 보았던 대로, 그 결과는 여러분이 읽기전용 DBGrid 에서 보았던 것과 비슷합니다.




이 StringGrid 의 각각의 컬럼의 크기는 기본 크기인 64 입니다. 컬럼의 크기를 바꿔보도록 합시다. 이

작업은 여러분이 익스프레션 에디터를 사용해 볼 수 있는 기회를 줄 것입니다. 이 작업을 수행하기

위해서는 아래의 단계를 따라야 합니다.

1. 익스프레션 에디터의 컬렉션 패널 안의 State 컬럼과 연관된 ColFormat 컬렉션을 선택합니다. 그런

다음에, 새로운 ColFormat 익스프레션을 추가하기 위해서 익스프레션 에디터의 툴바에 있는 Add

버튼을 클릭합니다. (또는 Ins 키를 누릅니다.)

2. 오른쪽 패널의 하단 부분에 위치한 Control Expression 필드에 ColWidths[3]을 입력합니다.

ColWidths[3]은 StringGrid 의 네 번째 (0 부터 시작) 컬럼의 너비를 나타냅니다. Control Expression

필드의 오른쪽에 있는 체크 표시를 클릭하여 이 익스프레션을 적용합니다.

3. Source Expression 필드에 Size * 2 라고 입력합니다. 네 번째 컬럼은 State 의

SourceMemberName 값과 연관되어 있기 때문에, 이 익스프레션은 ClientDataSet 의 State 필드와

연관된 TField 의 Size 프로퍼티를 참조하고 있습니다. 요약하자면, 우리는 라이브바인딩에게 State

필드에 보일 수 있는 글자의 최대 수에 근거하여 State 컬럼의 너비를 설정하라고 지시하고 있는

것입니다. 이 변화를 적용하기 위해서 Source Expression 필드의 오른쪽의 체크 표시를 클릭합니다.

이제 여러분의 익스프레션 에디터는 그림 21 과 같이 보일 것입니다.

그림 21. 새로운 ColFormat 익스프레션은 ClientDataSet 안의 State 필드의 크기에 근거하여

StringGrid 의 State 컬럼의 너비를 설정합니다.

4. 이 프로젝트를 실행하고 ‘TBindList and TBindGrid’ 탭을 보면, 그림 22 와 같을 것입니다. 이제

State 필드가 다른 세 개의 필드보다 좁아진 것에 주목하십시오.




1 M

DM

그림 22. 이제 State 컬럼의 너비는 State 필드의 글자의 크기에 근거하여 조정되었습니다.

우리는 그리드의 요소들을 제어하기 위한 추가적인 익스프레션들을 만드는 방법에 대해 좀더 알아볼

수도 있습니다. 그러나 제가 이 문서의 끝부분에서 지적할 것처럼, 적어도 현재 버전의

라이브바인딩은 다소 느립니다. 따라서 우리는 라이브바인딩의 동적인 특성이 우리에게 이점을 주는

곳에 라이브 바인딩을 사용해야 합니다. 디자인 타임에 쉽게 설정할 수 있는 그리드의 컬럼 너비를

지정하는 것 말고요.

우리가 잠시 동안 익스프레션 에디터 사용에 관한 이야기에서 벗어났기 때문에, 이제 몇 가지

추가적인 부분에 대해서 알아보도록 합시다. 좀더 많은 컬럼 컬렉션을 라이브바인딩에 추가하기

원한다면, 여러분은 Collections 패널에서 Columns Node 를 선택하고, Insert 버튼을 클릭하면

됩니다. (또는 Ins 키를 누릅니다.) 익스프레션이나 컬럼을 지우려면, 익스프레션이나 컬럼을 선택한

뒤, 툴바의 Delete 버튼을 클릭하면 됩니다. (또는 Del 키를 누릅니다.)

여러분은 Source Expression 필드 아래의 버튼들을 사용할 수도 있습니다. 익스프레션을 평가하기

위해서나 익스프레션을 평가하도록 해서 그 결과를 익스프레션의 목표 대상에 할당하기 위해서

말입니다. (앞서 언급했듯이, 리스트 라이브바인딩은 항상 Source 에서 Control 로 할당합니다.)

그러나 디자인 타임에 타당한 익스프레션에 대해서만 이 작업이 성공적으로 수행됩니다. 이

프로젝트에서는 ClientDataSet 은 디자인 타임에 비활성화되어 있어서 State 필드에 대해 갓 생성된

새로운 소스 익스프레션을 평가하는 것은 이치에 맞지 않습니다. 그러나 StringGrid 는 네 개의

컬럼을 가지고 있기 때문에, 이를 위해 ColWidths[3] 을 평가하도록 Eval Control 버튼을 클릭할 수도

있습니다. 그러면 익스프레션 에디터는 그림 23 와 같은 대화상자를 표시합니다. 이 대화상자는

StringGrid2 의 ColWidths[3] 익스프레션을 평가하고 있다고 표시합니다. View As 리스트에서

String 이 선택되면, StringGrid 의 컬럼의 기본 너비인 64 가 표시되는 것을 볼 수 있습니다. View

As 에서 Type 이 선택되면, 대화상자는 익스프레션이 정수형(integer)으로 평가된다고 표시합니다.




그림 23. ControlComponent, SourceComponent 의 상태에 따라, 그들과 연관된 익스프레션을

디자인 타임에 평가해 볼 수 있습니다.

이제 비관리 라이브바인딩의 가장 특징적인 라이브바인딩인 링크(Link) 라이브바인딩에 대해

알아보도록 하겠습니다.

링크 라이브바인딩 (LINK LIVEBINDINGS)

네 가지 링크(Link) 라이브바인딩이 있고, 그것들은 읽기/쓰기 기능을 제공합니다. 리스트

라이브바인딩과 같게, 링크 라이브바인딩은 보통 BindScopeDB 컴포넌트와 함께 데이터 인식 기능을

가지고 있지 않은 컨트롤에 데이터 인식 기능을 구현하기 위해 사용됩니다.

링크 라이브바인딩 중 두 가지는 리스트 라이브바인딩과 상당 부분 공통점을 갖습니다. 따라서, 저는

두 타입 사이에 공통점이 없는 두 가지 링크 라이브바인딩에 대해 설명하겠습니다. 이는 BindLink 와

BindPosition 라이브바인딩입니다.

BINDLINK

BindLink 라이브바인딩은 단일 필드와 다른 컴포넌트 (보통 BindScopeDB)를 지원하는 컨트롤 사이의

읽기/쓰기 바인딩을 제공합니다. 좀더 구체적으로 말하자면, BindLink 는 IEditLinkObserver 나

IEditGridLinkObserver 를 구현한 컨트롤을 BindScopeDB 에 바인딩 할 수 있게 합니다.

VCLLiveBindings 프로젝트는 두 개의 BindLink 를 포함하고 있습니다.




1 M

DM

첫 번째 BindLink 는 사용자가 수정할 수 없는 컨트롤과 연관되어 있습니다. (그 BindLink 는 Label

컴포넌트와 연관되어 있습니다.) 이 라이브바인딩은 현재의 레코드와 연관된 사람의 전체 이름을

표시합니다. 이 라이브바인딩과 연관된 익스프레션은 BindScopeDB 의 하나 이상의 프로퍼티

(ClientDataSet 의 두 개의 필드)를 참조할 필요가 있기 때문에, 이 라이브바인딩은

SourceMemberName 프로퍼티를 사용할 수 없습니다.

익스프레션 에디터에서 이 BindLink 를 보면, 이 라이브바인딩이 세가지 컬렉션인 Format, Parse,

Clear 를 지원한다는 것을 알 수 있습니다. Format 과 Clear 컬렉션은 BindExprItems

라이브바인딩에서 보았던 것과 같은 목적으로 사용됩니다. 여러분은 라이브바인딩이 활성화될 때

ControlComponent 에 익스프레션을 할당하기 위해 하나 이상의 Format 컬렉션을 추가할 수

있습니다. 라이브바인딩이 비활성화될 때 하나 이상의 익스프레션을 할당하기 위해 Clear 컬렉션을

추가할 수도 있습니다. 저는 하나의 Format 익스프레션과 하나의 Clear 익스프레션을

추가하였습니다. Format 익스프레션은 ClientDataSet 의 FirstName 과 LastName 필드의 값을

조합하여, 전체 이름을 Edit 의 Text 프로퍼티에 할당합니다. Clear 익스프레션은 빈 문자열을 Text

프로퍼티에 할당합니다.

여러분의 예상대로, 이 라이브바인딩의 Format 익스프레션에는 전체 이름 형태를 만들기 위해

ClientDataSet 의 FirstName 과 LastName 필드를 문자열 리터럴 (스페이스)과 연결하는 익스프레션이

할당됩니다. (그리고 이 값은 Label 의 Caption 프로퍼티에 할당됩니다.) Clear 익스프레션은 Label 의

캡션에 빈 문자열을 할당합니다.

(BindScopeDB 를 통해) ClientDataSet 에 값을 쓸 수 있는 BindLink 라이브바인딩에 대해 다시

알아보도록 합시다. 첫째는 BindLink 라이브바인딩을 위한 전형적인 ControlComponent 입니다. 단일

필드를 수정할 수 있는 컨트롤이며, 이 예제에서는 Edit 가 사용됩니다.

StatusBar 와 Label 과 연관된 라이브바인딩처럼, Format 익스프레션은 BindScopeDB 에 의해

노출되는 필드의 값 (이 경우에는 LastName 필드의 값)을 받습니다. Clear 익스프레션은 Edit 의 Text

프로퍼티를 빈 문자열로 설정합니다.

ClientDataSet 에 값을 쓰는 일은 Parse 컬렉션의 익스프레션에 의해 수행되며, 이 익스프레션은

컨트롤에서 소스 방향을 사용합니다. Format 과 Clear 익스프레션은 소스에서 컨트롤 방향으로만

사용됩니다. 흥미롭게도 이 라이브바인딩에서 사용된 Parse 익스프레션은 매우 간단합니다. 사실

Parse 익스프레션은 Format 익스프레션과 익스프레션의 방향이 반대라는 것만 제외하면 완전히

동일합니다. 그림 24 에서 보듯이 말입니다.




그림 24. BindLinkLastNameEdit 라이브바인딩과 연관된 익스프레션들

BINDPOSITION

우리가 다음으로 살펴볼 라이브바인딩은 BindPosition 라이브바인딩입니다. 이 라이브바인딩은 가장

제한적인 비관리 라이브바인딩입니다. 이 라이브바인딩이 상대 위치를 조정할 수 있는

ControlComponent 와 동작하기 위해 디자인되었기 때문입니다. 사실 BindPosition 라이브바인딩은

IPositionObserver 인터페이스를 구현하는 어떤 컴포넌트와도 함께 사용할 수 있습니다. ScrollBar

컴포넌트는 이런 종류의 ControlComponent 의 한 예입니다.

BindPosition 라이브바인딩은 세가지 익스프레션 컬렉션인 PosControl, PosClear, PosSource 를

가지고 있습니다. 라이브바인딩이 활성화되었을 때 ControlComponent 에 영향을 주기 위해

PosControl 익스프레션을 생성할 수 있습니다. 여러분이 PosControl 익스프레션을 사용해서 할 수

있는 전형적인 작업은 SourceComponent 의 몇몇 서수형 프로퍼티에 근거하여

ControlComponent 의 상대 위치를 설정하는 것입니다. 비슷하게 여러분은 라이브바인딩이

비활성화될 때 ControlComponent 를 원래 상태로 설정하기 위해 PosClear 익스프레션을 사용할 수

있습니다.

PosControl 과 같이, PosSource 도 목적 컴포넌트의 위치를 변화시키는데 사용됩니다. BindLink

라이브바인딩에서 보았던 Parse 익스프레션 컬렉션처럼, 이 익스프레션의 방향은 컨트롤에서 소스

방향입니다. 사용자들은 ControlComponent 와 상호작용함으로써 소스 컨트롤에 영향을 줄 기회를

갖게 됩니다.

VCLLiveBindings 프로젝트는 BindPosition 라이브바인딩을 포함합니다. BindPosition 이 ScrollBar 과

함께 사용되는 경우에 대해서 알아보도록 하겠습니다. 그림 25 는 이 라이브바인딩의 익스프레션

에디터를 보여줍니다.




1 M

DM

그림 25. 익스프레스 에디터 안의 BindPosition 라이브바인딩과 연관된 익스프레션들

여러분이 보았듯이, 여기에는 두 개의 PosControl 익스프레션이 있습니다. 그 중 하나인 첫 번째

익스프레션은 ScrollBar 의 Max 프로퍼티를 설정합니다. Max 프로퍼티는 ClientDataSet 의 레코드의

수에 근거하여 설정하였으며, ScrollBar 의 최대 오른쪽 위치 값을 나타냅니다. 두 번째 익스프레션

역시 PosControl 익스프레션이며, Position 프로퍼티를 0 (0 은 ScrollBar 의 Min 프로퍼티의 기본

값이다.) 이나 현재 레코드 번호 (-1)로 설정합니다. 이 두 익스프레션은 ScrollBar 의 썸 탭(thumb

tab)의 위치를 ClientDataSet 의 현재 레코드 위치와 동기화하는 결과를 갖습니다.

PosSource 익스프레션은 BindPosition 라이브바인딩이 SourceComponent 를 변경하게 하고 싶을 때

사용합니다. 그림 25 에서 보았듯이, Position 프로퍼티에 생긴 변경은 DataSet 의 RecNo 프로퍼티를

변경하게 합니다. 기본 키 위반(primary key violation), BeforePost 이벤트 핸들러, 기타 다른 제약

사항과 같이 새로운 레코드를 탐색하는데 있어 ClientDataSet 가 처리하는 부분에서 변경이 막히는

경우를 제외하고는 말이죠.

그림 26 은 VCLLiveBindings 프로젝트의 Link 탭을 보여줍니다. ScrollBar 의 상대 위치는 StatusBar 에

표시되는 텍스트와 일치한다는 점에 주목하십시오. ListBox 와 StringGrid 안의 레코드의 상대 위치도

일치합니다. 이는 우리에게 BinkListLink 와 BindGridLink 라이브바인딩에 대해 생각해 볼 좋은 기회를

제공합니다.




그림 26. BindPosition 라이브바인딩은 ScrollBar 와 StatusBar 를 ClientDataSet 과 동기화된 상태로

유지해 줍니다.

BindPosition 라이브바인딩을 사용하는 두 번째 컨트롤은 StatusBar 입니다. 이 프로젝트는 현재

레코드가 ClientDataSet 의 어떤 레코드인지를 나타내기 위해서 StatusBar 를 사용합니다.

BindPosition 라이브바인딩은 이를 위한 최적의 라이브바인딩입니다. 사용자가 StatusBar 와 유저

인터페이스 상에서 상호작용하지 못하기 때문에 PosControl 와 PosClear 익스프레션만 필요한데도

말입니다.

PosControl 익스프레션은 ControlExpression 으로 SimpleText 를 사용합니다. (이를 위해 우리는

StatusBar 의 SimplePanel 을 True 로 설정해야 합니다.) SourceExpression 을 아래의 같은 문자열로

설정합니다.

'Record ' + ToStr(RecNo) + ' of ' + ToStr(RecordCount)

Clear 익스프레션은 ControlExpression 으로 SimpleText 를 사용하고, SourceExpression 으로 빈

문자열을 사용합니다. 이 두 익스프레션은 ClientDataSet 가 활성화될 때, 전체 레코드 수에 대한

ClientDataSet 의 레코드 위치를 표시하게 하고, ClientDataSet 이 닫힐 때, 텍스트가 표시되지 않도록

합니다.

앞에서 언급했듯이, BindListLink, BindGridLink 라이브바인딩은 많은 부분에서 BindList, BindGrid

라이브바인딩과 공통점을 갖습니다. 가장 큰 차이점은 Link 카테고리에 있는 다른

라이브바인딩들처럼 이 라이브바인딩은 컨트롤에서 소스로의 익스프레션 컬렉션을 지원한다는

것입니다. BindListLink, BindGridLink 라이브바인딩은 다수의 레코드를 참조하기 때문에, 이

컬렉션들은 소스 컴포넌트 안의 현재 레코드의 위치 뿐 아니라 SourceComponent 의 필드에도

영향을 줄 수 있습니다.




1 M

DM

BINDLISTLINK

그림 27 은 VCLLiveBindings 프로젝트의 Links 탭에 있는 ListBox 와 연관된 라이브바인딩을

보여줍니다. VCLLiveBindings 메인 폼의 Lists 탭에 있는 ListBox 와 연관된 라이브바인딩과

마찬가지로, 이 BindListLink 는 SourceComponent 에 근거하여 ListBox 아이템의 개수를 설정하는

Format 익스프레션을 포함합니다. 또한 ClientDataSet 이 닫힐 때, ListBox 의 아이템들을 삭제하는

Clear 익스프레션도 포함하고 있습니다. 또한, ListBox 의 현재 아이템을 ClientDataSet 의 현재

레코드와 동기화하는 PosControl 익스프레션도 포함하고 있으며, ListBox 에서 일어나는 사용자와의

상호작용을 통하여 ClientDataSet 의 현재 레코드를 변화하게 하는 PosSource 익스프레션도

포함하고 있습니다.

그림 27. VCLLiveBindings 프로젝트의 BindListLink 라이브바인딩과 연관된 익스프레션들

BINDGRIDLINK

BindGridLink 라이브바인딩은 RAD Studio XE2 의 모든 라이브바인딩 중에서 가장 기능이 많은

라이브바인딩입니다. 이 라이브바인딩은 지금까지 언급한 비관리 라이브바인딩의 모든 기능을

가지고 있습니다. BindGridLink 라이브바인딩은 그리드 전체, 개별 그리드 컬럼, 개별 그리드 셀,

그리드의 현재 레코드의 위치, 소스 DataSet 에 영향을 미칠 수 있는 익스프레션들을 지원합니다.

게다가 BindGridLink 는 그리드의 개별 셀에서 소스 DataSet 으로 데이터를 쓸 수 있게 하는 CellParse

컬렉션을 지원합니다.

그림 28 에 보이는 BindGridLinkStringGrid11 라이브바인딩에 대한 익스프레션 에디터를 살펴 봅시다.

여기에는 정말 많은 익스프레션들이 있습니다. 그러나 지금이 다양한 익스프레션들을 살펴볼 수 있는

좋은 기회이며, 이 익스프레션들은 비교적 읽기 쉬울 것입니다.




그림 28. BindGridLinkStringGrid11 라이브바인딩에 대한 익스프레션 에디터

여기에 있는 익스프레션들은 앞에서도 많이 보았을 것입니다. PosControl 과 PosSource 컬렉션은

StringGrid 와 ClientDataSet 를 동일한 현재 레코드로 동기화되도록 유지시켜 줍니다. FormatControl

익스프레션은 StringGrid 의 전체적인 모습을 설정하고, CellFormat 익스프레션은 그리드의 개별 셀

안의 데이터를 표시합니다. 첫 번째 CellFormat 익스프레션은 ClientDataSet 의 RecNo 프로퍼티를

표시하며, 두 번째 CellFormat 익스프레션은 FirstName 과 LastName 필드를 연결한 결과를

표시합니다. 세 번째 CellFormat 익스프레션은 해당하는 컬럼에 City 필드의 값을 표시합니다.

앞서 언급했듯이, CellParse 는 셀로부터 해당하는 ClientDataSet 의 필드에 값을 쓰는데 사용됩니다.

이 그리드의 경우, 필드로부터 데이터를 표시하는 컬럼이 한 개 있습니다. 그러므로 CellParse

익스프레션이 동작할 수 있는 컬럼은 한 개입니다. 이 익스프레션은 그림 28 의 익스프레션

에디터에서 선택되어 있는 익스프레션입니다.

여러분이 볼 수 있듯이, ControlComponent 는 StringGrid 이고, SourceComponent 는

BindScopeDB 입니다. CellParse 익스프레션의 방향은 항상 컨트롤에서 소스입니다.

소스 익스프레션은 City 필드의 AsString 프로퍼티입니다. (그리고 City 필드는 이 익스프레션의

SourceMemberName 에 의해 식별됩니다.) 컨트롤 익스프레션은 SelectedText(Self)이며, 이것은

약간의 설명을 필요로 합니다.

SelectedText 는 양방향성 커스텀 메서드이고, 컨트롤로부터 데이터를 가져오거나, 할당하는데

사용됩니다. SelectedText 가 참조하는 컨트롤은 이 익스프레션의 Self 변수에 의해 정의됩니다.

그리고 Self 는 익스프레션의 스코프 안의 컨트롤에 대한 참조입니다. StringGrid 의 문맥 안에서




1 M

DM

사용될 때, SelectedText 는 현재 셀의 값을 읽거나 쓸 수 있게 해줍니다. 그 결과, StringGrid 의 City

필드의 변화는 ClientDataSet 의 현재 레코드에 기록됩니다.

파이어몽키 어플리케이션에서의 라이브바인딩

여러분은 궁금할 것입니다. 라이브바인딩이 파이어몽키 어플리케이션에서 중대한 역할을 한다고

했는데, 왜 제가 지금까지 거의 모든 라이브바인딩을 VCL 어플리케이션에서 설명했는지에 대해서

말입니다. 그 대답은 다음과 같습니다. 저는 여러분이 라이브바인딩이 파이어몽키

어플리케이션에서의 데이터 인식을 구현하기 위한 독점적인 기술이라고 생각하길 원치 않았기

때문입니다. 물론 여러분이 라이브바인딩을 그러한 용도로 사용할 수 있지만, 그게 전부는 아닙니다.

우선, 데이터 인식(data awareness)은 라이브바인딩의 쓰임새 중 하나일 뿐입니다. VCLLiveBindings

프로젝트 안에 있는 StatusBar 와 연관된 BindPosition 과 두 개의 버튼과 연관된 BindLinks 에 대해

생각해 보도록 합시다. 이 라이브바인딩들은 유저 인터페이스에 대한 다른 방식의 생각을 제시하고

있습니다. 이 라이브바인딩들은 유저 인터페이스가 컨트롤들의 상태에 반응하도록 합니다. 컨트롤을

제어하기 위한 직접적인 지식이 있어야 작성할 수 있는 메서드 호출 코드를 작성하지 않고 말입니다.

라이브바인딩의 두 번째 측면은 이벤트 핸들러에 대한 대체품이 아니라는 것입니다. 그 좋은 예는

파이어몽키 컨트롤도 VCL 컨트롤처럼 이벤트 핸들러를 지원한다는 것입니다. 라이브바인딩은 새롭고

다른 매커니즘입니다. 물론 이벤트 핸들러로도 할 수 있는 것들이 있습니다. 동시에 라이브바인딩은

이벤트 핸들러로 하기 어려운 일들도 할 수 있습니다.

세 번째 이유는 저는 적절한 곳에 라이브바인딩을 사용하기 시작하는 것이 VCL 과 파이어몽키

어플리케이션 둘 다에서 중요하다고 생각하기 때문입니다. 여러분이 라이브바인딩을 사용하기

시작하면, 라이브바인딩에 대한 생각이 달라지기 시작할 것입니다. 프레임워크로써 라이브바인딩은

새로운 세대에 우리가 만들기 원하는 풍부한 유저 인터페이스를 가진 어플리케이션의 중요한 부분이

될 것입니다.

네 번째 이유는 파이어몽키에서 라이브바인딩을 설정하는 일에는 이 문서에서 지금까지 다룬 모든

기술이 사용된다는 것입니다. 제가 설명한 모든 라이브바인딩은 그에 상응하는 익스프레션 컬렉션과

함께 파이어몽키에서 사용됩니다.

또한 파이어몽키는 라이브바인딩의 VCL 구현에 없는 것들도 가지고 있습니다. 파이어몽키는 VCL

구현에서는 찾을 수 없는 8 개의 컴포넌트를 가지고 있습니다. 그 중 7 개는 링크(Link)

라이브바인딩입니다. 그것은 TBindDBEditLink, TBindDBTextLink, TBindDBCheckLink,

TBindDBGridLink, TBindDBListLink, TBindIDBImageLink, TBindDBMemoLink 입니다. 마지막

컴포넌트는 BindNavigator 이고, BindNavigator 는 컴포넌트이지만 라이브바인딩은 아닙니다.

BindNavigator 컴포넌트에 대해서는 이 절의 뒷부분에서 설명하겠습니다.

파이어몽키에서 링크 라이브바인딩은 컨트롤들을 DataSet 에 바인딩하는 작업을 쉽게 만들어 줍니다.

모든 필요한 익스프레션들을 생성하는 일을 라이브바인딩이 함으로써 말입니다.




코드: 이 프로젝트의 코드는 FireMonkeyLiveBindings 프로젝트에 존재하며, 이 프로젝트는 이 문서와

함께 다운로드 할 수 있습니다.

파이어몽키 어플리케이션에 데이터 인식 기능을 제공하기 위해 라이브바인딩을 사용하고 있는

간단한 프로젝트를 살펴보도록 하겠습니다. 실행된 어플리케이션은 그림 29 와 같습니다.

그림 29. 데이터 인식(data-aware) 파이어몽키 어플리케이션

이 어플리케이션은 매우 단순합니다. 제가 라이브바인딩을 특별한 무언가를 하기 위해 사용하지

않았기 때문입니다. 그러나 작은 노력으로도 VCLLiveBindings 프로젝트에서 사용했던 모든 기술들을

여기에 적용할 수 있습니다.

저는 이 어플리케이션을 간단한 형태로 유지했습니다. 파이어몽키 컨트롤을 데이터와 연관시키는

일이 정말이지 쉽다는 것을 보여주기 위해서 입니다. 요약하자면, 여러분이 폼과 연결된 DataSet,

DataSource, BindScopeDB 를 가지고 있다면, 이 인터페이스는 몇 분 안에 다시 만들 수 있습니다.

이제 여기에 여러분이 해야할 일이 있습니다. 이 폼의 비주얼 컨트롤들을 모두 제거한 뒤에, 이 폼을

여러분이 다시 구성하는 일 말입니다. 이를 위해서는 다음과 같은 단계를 따라야 합니다.

1. RAD Studio 에서 FireMonkeyLiveBindings 프로젝트를 엽니다.

2. 폼에서 StringGrid, 두 개의 Edit, BindNavigator 를 삭제합니다. 또한 BindingsList 를 더블 클릭하여,

폼에 이전에 추가되었던 모든 라이브바인딩들을 삭제합니다. 이제 여러분의 폼은 그림 30 과 같은

모양일 것입니다.




1 M

DM

그림 30. BindScopeDB 를 가진 기본적인 폼. BindScopeDB 는 DataSource 를 통해 활성화된

ClientDataSet 에 연결되어 있다.

3. 다음으로 ClientDataSet 을 설정하고 활성화시켜야 한다. ClientDataSet 을 선택한 뒤, 오브젝트

인스펙터를 사용하여 FileName 프로퍼티를 sampledata.cds 파일로 설정합니다. 그러면

ClientDataSet 은 데이터 파일을 FireMonkeyLiveBindings.dpr 파일과 동일한 디렉토리에서 찾게

됩니다. (ClientDataSet 의 FileName 프로퍼티 에디터는 기본값으로 파일 필터를 *.xml 으로 지정하고

있다는 것에 주의하십시오. 그래서 여러분은 파일 필터를 cds 파일로 변경해야 합니다.) 그런 다음에,

ClientDataSet 의 Active 프로퍼티를 True 로 설정합니다.

4. 이제 StringGrid 를 폼 위에 놓고, Align 프로퍼티를 alMostBottom 로 설정합니다. 그림 29 에

보이는 StringGrid 의 위치에서 좀더 크거나 작게 하기 위해서 StringGrid 크기를 조정합니다.

5. 폼을 선택하고 (그래서 StringGrid 는 선택이 해제됩니다.) 두 개의 Edit 를 폼에 놓습니다. 각각의

Label 아래에요.

6. 다시 폼을 선택하고, BindNavigator 을 놓습니다. 그리고 가장 위쪽의 라벨 위에 위치시킵니다.

7. 이제 라이브바인딩을 생성할 차례입니다. StringGrid 에 대한 라이브바인딩부터 생성해 봅시다.

StringGrid 에서 오른쪽 클릭을 하고, New LiveBinding...을 선택합니다. 그러면 RAD Studio 는 그림

31 에 보이는 것과 같은 New LiveBinding 대화상자를 표시합니다.




그림 31. 파이어몽키 StringGrid 에 대한 New LiveBinding 대화상자

보이는 바와 같이, 여러분이 VCL 에서 라이브바인딩을 생성할 때 보았던 대화상자와 비슷하지만

완전히 같지는 않습니다. 구체적으로, 이 대화상자는 DB Links 라는 추가적인 노드를 포함하고

있습니다.

8. DB Links 노드 아래에 있는 TBindDBGridLink 를 선택하고, OK 버튼을 클릭합니다.

BindDBGridLinkStringGrid11 라는 이름을 가진 새 라이브바인딩이 생성되며, 이 라이브바인딩은

오브젝트 인스펙터에서 선택되어 있습니다.

9. 오브젝트 인스펙터를 사용하여, 새 라이브바인딩의 DataSource 프로퍼티를 BindScopeDB 로

설정합니다. 이 프로퍼티를 설정함으로써, StringGrid 는 ClientDataSet 로부터 데이터를 가져올 수

있습니다. 이제 여러분의 폼은 그림 32 와 같은 모양으로 보일 것입니다.




1 M

DM

그림 32. BindScopeDB 와 연결되면, 새 라이브바인딩은 완전하게 동작합니다.

실제로는 제가 했던 것보다 좀더 어렵게 이것을 만들 수도 있습니다. StringGrid 의 컨텍스트 메뉴는

DB DataSource 에 대한 옵션 링크를 포함합니다. 여러분이 그 옵션을 선택한다면, 라이브바인딩은 그

링크를 생성하고 설정할 것입니다. 이제 2 개의 에디트에 대한 테크닉을 사용해 보도록 합시다.

10. First Name Label 아래에 보이는 Edit 를 오른쪽 클릭하고, DB Field... 링크를 선택합니다. 그림

33 에 보이는 것과 같은 New DB Link 대화상자가 표시됩니다. FirstName 을 선택하고, OK 버튼을

클릭합니다. 이제 Edit 의 설정이 끝났습니다. 이 과정을 Last Name Label 아래에 위치한 Edit 에도

동일하게 적용합니다. 이 때에는 New DB Link 대화상자에서 LastName 필드를 선택합니다.




그림 33. The New DB Link 대화상자

11. 이제 마지막으로 BindNavigator 를 설정해 보도록 합시다. BindNavigator 을 선택하고, BindScope

프로퍼티를 BindScopeDB 로 설정합니다.

이게 다입니다. 여러분의 컨트롤들은 이제 데이터를 인식하여 동작하게 되었습니다. 이제

어플리케이션을 실행하고, 데이터를 탐색하고, 데이터를 편집할 수 있습니다. 어플리케이션을

닫는다면, 여러분이 만든 변화는 저장될 것입니다. 사실 이 것 외에, 이 폼의 동작을 돕기 위한 두

가지 이벤트 핸들러가 있습니다. 하지만 여기 있는 이 이벤트 핸들러들은 무척이나 간단하다는 것에

동의하리라 생각합니다.


begin


ClientDataSet1.FileName := ExtractFilePath(ParamStr(0)) + 'sampledata.cds';

ClientDataSet1.LogChanges := False;

ClientDataSet1.Open;

end;

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);

begin

if ClientDataSet1.Active then

begin

ClientDataSet1.SaveToFile;


end;

end;




1 M

DM

그렇다면 VCL 과 파이어몽키 어플리케이션에서 라이브바인딩을 추가하는데 있어 다른 점은

무엇일까요? 이에 대한 대답은 컴포넌트 에디터가 링크 라이브바인딩을 생성하고 VCL

어플리케이션에서 수동으로 한 것과 거의 동일한 방법으로 그것이 설정된다는 것입니다. 클래스와

프로퍼티는 동일하지만, 한가지 차이가 있습니다. 여러분은 이 라이브바인딩들의 프로퍼티를 수정할

수 없다는 것입니다. 이 라이브바인딩 중 하나의 익스프레션 에디터를 열어보면, 그림 34 에 보이는

대로 익스프레션 컬렉션들이 읽기 전용이라는 것을 알 수 있습니다.

그림 34. 라이브바인딩은 StringGrid 컴포넌트 에디터에 의해 생성된다.

저는 우리가 디자인타임에 이 라이브바인딩들을 수정하지 못하는 것이 정말 아쉬운 일이라

생각합니다. 예를 들어, 여러분이 StringGrid 의 Column Editor 컴포넌트 에디터를 StringGrid 의 개별

컬럼을 변경하기 위해 사용하는 동안, 라이브바인딩이 생성한 개별 익스프레션을 수정할 수 없습니다.

여러분이 이러한 라이브바인딩들을 사용한다면, (링크 라이브바인딩을 수동으로 설정하는 것이

아니면) 하나 이상의 프로퍼티를 변경하는 것이 가능합니다만, 런타임에 해야만 합니다. 그 것을 하기

위해서는, 폼에 OnActivating 이벤트 핸들러를 추가하고, 라이브바인딩 객체의 참조를 얻기 위해

링크 라이브바인딩의 GetDelete 메서드를 사용합니다. 그러고 나면, 포함된 익스프레션 컬렉션을

변경하기 위해서 이 참조를 사용할 수 있습니다.

파이어몽키 어플리케이션에서 라이브바인딩을 사용하는데 있어 다루어야 할 또 하나의 주제가

있습니다. 파이어몽키는 VCL 툴 팔레트의 Data Control 페이지에 보이는 어떠한 데이터 인식

컨트롤들도 가지고 있지 않다는 것입니다. 이는 파이어몽키에는 DBNavigator 가 없다는 것을




의미합니다. 그래서 BindNavigator 가 필요한 것입니다. 여러분이 파이어몽키 어플리케이션에서 미리

정의된 네비게이터를 사용하기 원한다면, BindNavigator 를 사용하십시오.

라이브바인딩의 미래

저는 RAD Studio XE2 가 발표되었을 때부터 라이브바인딩에 관심을 가져 왔습니다. 저에게 있어

라이브바인딩은 객체와 함께 작업하는 새로운 방식이라는 점이 명백하게 다가왔고, 현재까지

라이브바인딩의 사용 방법을 알리기 위해 일해 오고 있습니다. 잡지의 기사, David Intersimone

(David I)에 의해 개최된 24 시간 델파이(24 Hours of Delphi) 이벤트 동안에 발표했던 라이브바인딩

프리젠테이션과 같은 프리젠테이션들을 통해서 말입니다. 라이브바인딩에 대해 블로그에 글을

쓰기도 했습니다.

그에 대한 반응은 흥미로웠고, 긍정적이지 않은 반응들도 있었습니다. 이를 요약하자면, 개발자들이

가진 세 가지의 공통된 불평이 있었고, 저는 이 자리에서 그 불평들에 대해 언급하고 싶습니다.

제가 가장 많이 들은 첫 번째 지적은 라이브바인딩에 정말 새로운 건 아무것도 없다는 것입니다.

다른 말로 하면, 라이브바인딩이 할 수 있는 일들은 기존의 RAD Studio 에 존재하는 이벤트 핸들러와

같은 매커니즘을 이용하면 어차피 다 할 수 있는 일이라는 것입니다.

저는 여기에 동의하지 않습니다. 물론 이벤트 핸들러도 강력하고 빠르지만, 만일 우리가

라이브바인딩을 그저 기존에 해오던 일의 다른 방식 정도로만 본다면, 그런 결론을 내릴 수도 있을

것입니다. 그리고 그건 단지 한가지 방법일 뿐입니다. 라이브바인딩은 우리가 다른 관점에서 우리의

목표를 볼 것을 요구합니다. 라이브바인딩은 전통적인 이벤트 핸들러의 이벤트 기반 모델에 맞지

않는 일들도 할 수 있습니다. 물론 현재 버전의 RAD Studio 에서는 그것이 다소 제한적이지만, 시간이

지나면 달라질 것입니다.

여기 제가 말하려는 것의 예가 있습니다. 저는 VCLLiveBindings 프로젝트에서 만들었던

BindExpression 이벤트 핸들러로 다시 돌아가 생각해 보고 싶습니다. 여기에는 아직 논의되지 않은

부분이 있습니다. 저에게 있어서 이 라이브바인딩은 컴포넌트와 함께 작업하는 새로운 방식을

뜻합니다.

우선 BindExpressions 은 SourceExpression 에서 부가 작용(side effects)을 일으키는 메서드 호출을

포함합니다. 이것이 그 메서드이고, 여러분이 볼 수 있듯이, 폼과 연관되어 있습니다.

function TForm1.OpenCDS(Open: Boolean): string;

begin

if Open then

begin



exit('Close');

end

else

begin






1 M

DM

exit('Open');

end;

end;

BindExpression 은 OpenCloseAction 라고 이름 지어진 ActionItem 과 연관되어 있습니다. 두 버튼은

그들의 동작을 위해 이 ActionItem 을 사용합니다. 이는 ActionItem 을 Caption, Enabled, images 와

같은 다수의 프로퍼티가 공유하여 사용한다는 것을 의미합니다. 또한 그들의 OnClick 이벤트

핸들러로 OnExecute 이벤트 핸들러를 사용합니다. 그 결과로, 이 버튼들은 둘 다 클릭하면

ClientDataSet 이 열리거나 닫히고, 이 ActionItem 을 사용하는 다수의 객체들의 캡션이

업데이트됩니다. 이 특정한 ActionItem 이 폼 위의 두 개의 버튼과 연관된 것과 다르게, 어떤 수의

다른 컴포넌트들도 (버튼 뿐만 아니라) 이론상 같은 ActionItem 을 사용할 수 있습니다.

다시 BindExpression 으로 돌아와서, ControlComponent 은 OpenCloseAction (ActionItem)이며, 이

OpenCloseAction 객체는 동일하게 SourceComponent 로 지정됩니다. ControlExpression 은

Caption 이고, SourceExpression 은 아래와 같습니다.

Owner.OpenCDS(Self.Caption="Close")

이 라이브바인딩은 오브젝트 인스펙터에 그림 35 와 같이 표시됩니다.




그림 35. 부가 작용(side effects)를 일으키는 이 라이브바인딩은 컴포넌트와의 상호작용을 가능케

하는 새로운 방법을 보여줍니다.

이 것은 관리 라이브바인딩이고 그런 이유로, ActionItem 에 대한 OnExecute 이벤트 핸들러는

Notify 를 호출해야 합니다. 그래서 Value1EditChange 이벤트 핸들러가 호출되면서 Notify 를

호출하게 됩니다. 이 이벤트 핸들러는 폼의 다른 관리 라이브바인딩에서 사용되는 것과 동일한

이벤트 핸들러입니다.

procedure TForm1.Value1EditChange(Sender: TObject);

begin


end;

여러분이 볼 수 있듯이, 사용자가 버튼을 클릭하면 익스프레션 엔진은 Sender 와 연관된

라이브바인딩을 평가하기 위한 알림을 받습니다. 이 경우에 Sender 는 ActionItem 을 의미합니다.

SourceExpression 은 OpenCDS 메서드를 호출하고, 이는 ActionItem 의 Caption 프로퍼티를 위한




1 M

DM

새로운 값을 반환합니다. 이것은 이 액션에서 사용하는 두 버튼에 같은 캡션이 적용되도록 합니다.

이는 또한 ClientDataSet 를 닫거나 여는 좀더 간단한 부가 작용을 수행합니다. 그러나 여기에서

구현될 수 있는 부가 작용에는 몇 가지 제한이 있습니다.

이는 일반적인 이벤트 핸들러의 사용 방법과는 완전히 다릅니다. 이벤트 핸들러의 경우는 연산은

직접 호출해야만 한다고 생각합니다. 라이브바인딩의 경우는 모든 행위는 SourceExpression 이

평가될 때 호출되는 메서드들 안에 정의된 액션과 함께 라이브바인딩에 명시적으로 정의됩니다. 좀더

흥미로운 점은 미래에는 이런 종류의 작용이 어떤 이벤트 핸들러 없이도 이루어 질 수 있다는

점입니다.

앞서 제가 언급했듯이, 익스프레션으로부터 부가 작용을 일으키는 메서드를 호출하는 것은 프로퍼티

접근 메서드를 사용할 때 발생하는 부가 작용의 장점과 비슷합니다. 실제로 이 두 가지 테크닉은

여러분이 생각하는 것 이상으로 더 가깝게 관련되어 있습니다. 새로운 클래스를 디자인할 때,

여러분은 프로퍼티 접근 메서드에서 부가 작용을 구현할 수 있습니다. 그러면 라이브바인딩이 연관된

프로퍼티에 데이터를 할당할 때, 이러한 부가 작용이 일어나게 됩니다.

반면에, 프로퍼티 접근 메서드에 의해 일어나는 부가 작용은 컴포넌트 내부의 일관성을 유지하는

것과 종종 관련되어 있습니다. 그에 비해, 여러분이 라이브바인딩을 통해 호출하는 메서드가 일으킬

수 있는 부가 작용은 좀더 넓은 범위의 영향력을 행사합니다. 폼의 많은 객체들 또는 전체

어플리케이션을 동기화할 수 있게 해주기 때문입니다.

사람들이 라이브바인딩에 대해 불평하는 두 번째 사항은 너무 복잡하다는 것입니다. 물론 몇몇

라이브바인딩은 다수의 다른 익스프레션을 필요로 하고, 우리가 이 과정과 친숙하지 않다면,

라이브바인딩을 사용하는 것은 도전일 수 있습니다. 그러나 그것들 대부분은 우리가 친숙하지 않은

새로운 도구와 이번 버전의 디자인 타임에서의 제한적인 라이브바인딩 지원이 총체적으로 합쳐진

것의 결과입니다. 저는 RAD Studio 의 새 버전이 발표될 때마다 라이브바인딩이 사용하기 편해질

것이라고 확신합니다. 그리고 여러분이 라이브바인딩 설정에 한번만 익숙해진다면, 복잡하게

생각되는 대부분의 것들이 사라질 것이라 생각합니다. 저에게는 그랬고, 약간의 시간이 걸렸습니다.

그리고 아래에 적힌 코드에 대해 생각해 보시기 바랍니다. 이것은 VCLLiveBindings 프로젝트의 메인

폼 부분에 구현된 코드입니다. 이게 프로젝트 전체에서 사용자가 구현해야 할 코드의 전부입니다.

여러분이 세가지 탭에서 보았던 주요 기능의 대부분은 라이브바인딩이 자동으로 구현해준

것들입니다.

implementation

{$R *.dfm}


begin

ClientDataSet1.FileName :=

ExtractFilePath(ParamStr(0)) + 'sampledata.cds';

PageControl1.ActivePageIndex := 0;

end;

function TForm1.OpenCDS(Open: Boolean): string;




begin

if Open then

begin



exit('Close');

end

else

begin



exit('Open');

end;

end;


begin

BindingsList1.Notify(TrackBar1, 'Position');

end;

procedure TForm1.Value1EditChange(Sender: TObject);

begin


end;

end.

우리는 TrackBar1Change 이벤트 핸들러를 없앨 수 있습니다. Value1EditChange 이벤트 핸들러를

사용하기 위해 TrackBar 의 OnChange 프로퍼티에 지정한다면 말이죠. 그렇게 하지 않아서 필요

이상으로 코드가 복잡해 졌습니다.

세 번째 불만은, 라이브바인딩은 많은 작업을 하기에는 불충분하다는 것입니다. RAD Studio 의 가장

열성적인 서포터 몇몇은 라이브바인딩을 사용하여 원하는 것을 할 수 없는 경우들을 알게

되었습니다. 예를 들어, 오랫동안 델파이를 지지하고 지원하던 로버트 러브(Robert Love)는 TList 와

StringGrid 사이의 양방향성 라이브바인딩을 만드는 것이 매우 어렵다는 사실을 언급하였습니다.

그의 말이 맞습니다. 그것이 가능은 하지만 적어도 이번 버전에서의 라이브바인딩에서는 그것을

쓸만하게 지원하지 못한다고 생각합니다.

불평들이 맞는 이야기지만, 그것이 라이브바인딩을 사용하지 않을 이유가 되지는 못합니다. 우선

이번 라이브바인딩은 라이브바인딩의 첫 릴리즈입니다. 개발자들이 라이브바인딩으로 무언가를

하려면, 라이브바인딩이 상당히 괜찮은 수준이어야 하겠지만, 현재는 그렇지 못합니다. 이런 점은

다음 릴리즈에서 상당 부분 개선될 것으로 보입니다. 구체적이지는 않지만, RAD Studio 의 프로젝트

매니저인 존 토마스(John Thomas)는 추후의 릴리즈에서는 라이브바인딩이 좀더 많은 객체들과

바인딩되고, 그 사용법도 훨씬 쉬워질 것이라고 말하고 있습니다.

RAD Studio 는 (특히 델파이에서) 17 년 이상 혁신의 중심에 있어 왔습니다. 그리고 항상 좋은

아이디어는 개선되어 왔습니다. 델파이의 RTTI (runtime type information)는 델파이의 첫

릴리즈에서는 정말이지 획기적인 것이었고, 폼 디자이너 구현의 중심적인 기술이었습니다. 몇 년

후에, RTTI 는 훨씬 강력하면서 사용하기 편하게 개선되었습니다.

뿐만 아니라 다른 예들도 있습니다만, 저는 이렇게 말하는 것이 적당하리라 생각합니다. 그렇습니다.

이번 릴리즈의 라이브바인딩은 몇 가지 제한들을 가지고 있습니다. 그러나 이 제한들은 오랫동안




1 M

DM

남아있을 것 같지 않습니다. 라이브바인딩은 중요한 새로운 기술이며, 확실히 시간과 함께 개선될

기술입니다. 한편으로, 라이브바인딩은 RAD Studio 의 능력에 완전히 새로운 차원을 더했습니다.

라이브바인딩이 현재 우리가 원하는 전부를 하지 못한다는 이유로 라이브바인딩 사용을 피해서는 안

될 것입니다.

또한 저는 라이브바인딩에 대한 개인적인 몇 가지 우려를 가지고 있습니다. 첫째로 라이브바인딩은

느립니다. 익스프레션 엔진은 인터프리터이며, 그것은 매번 각각의 익스프레션들을 다시 평가하는 것

같습니다. VCLLiveBindings 프로젝트를 생각해 보시기 바랍니다. 여러분이 버튼들 중 하나를

ClientDataSet 를 닫고 다시 열기 위해서 누른다고 했을 때, 마지막 익스프레션이 평가되기 전에

지연이 발생하는 것을 느낄 수 있었을 것입니다. 대조적으로 이벤트 핸들러는 빠릅니다. 컴파일

타임에 코드가 바이너리 명령 형태로 컴파일 되기 때문입니다.

이 것이 뜻하는 바는, 적어도 지금은 라이브바인딩은 적절한 곳에만 사용해야 한다는 것입니다.

그러나 라이브바인딩이 이벤트 핸들러나 디자인 타임 설정의 대체품은 아닙니다. 예를 들어

TrackBar 와 ProgressBar 와 연관된 BindExpression 라이브바인딩을 생각해 보시기 바랍니다.

BindExpression 을 사용하는 대신, 우리는 BindExprItems 을 사용해서 ProgressBar 의 Max

프로퍼티를 TrackBar 의 Max 프로퍼티와 동기화하는 두 번째 익스프레션을 추가할 수 있습니다.

하지만 이러한 익스프레션의 사용은 불필요할 것입니다. Max 프로퍼티는 디자인 타임에 쉽게 설정할

수 있기 때문입니다. 런타임에 매번 익스프레션이 평가되어서 설정되어야 한다는 것은 불필요한

오버헤드가 발생한다는 것을 뜻합니다.

저의 라이브바인딩에 대한 두 번째 우려는 라이브바인딩 정의를 공유할 수 없다는 점입니다.

VCLLiveBindings 프로젝트는 두 개의 거의 동일한 BindExpression 클래스를 가지고 있고, 그것은 두

개의 버튼과 연관되어 있습니다. 저는 그렇게 하는 것이 이치에 맞는지 확신할 수 없습니다만,

라이브바인딩이 두 개 이상의 컨트롤에 사용되어야 할 때 꽤 좋은 방법이라고 생각합니다.

제가 가진 마지막 우려는 익스프레션 엔진을 위한 디버거가 없다는 것입니다. 여러분이 연관된

익스프레션의 타입과 값을 검사하기 위해 익스프레션 에디터에 있는 Eval Control 과 Eval Source

버튼을 사용할 수는 있지만, 문제가 있을 때 표시되는 에러 메시지는 종종 도움이 되지 않습니다.

또한 익스프레션에 에러가 있을 때는 모든 것이 실패합니다. 현재는 익스프레션 엔진에서 실패되는

부분이 무엇인지 알려면 복잡한 익스프레션을 재조립해 가면서 확인해야 합니다.

그러나 다시 한번 말하지만, 저는 이 이슈가 오래가지 않을 것이라고 예상하고, 이런 점들은

라이브바인딩이 성숙해 가면서 당연히 없어질 것이라고 생각합니다.

요약

라이브바인딩은 RAD Studio XE2 에서 처음으로 도입된 새로운 객체 바인딩 기술입니다.

라이브바인딩은 고전적인 데이터 컨트롤들이 지원하지 않는 데이터 인식을 가능하게 할 뿐 아니라,

객체 간의 상호작용을 정의할 수 있는 새로운 방법을 제시합니다. 전통적인 이벤트 핸들러의

대안으로서 뿐 아니라, 라이브바인딩은 개발자들에게 이러한 작업에 있어서 새로운 차원을 제공해




줍니다. 그리고 모던한 어플리케이션으로부터 사용자들이 기대하는 풍부한 인터페이스를 가능하게

해 줄 것입니다.

이 문서에서 저는 라이브바인딩과 관련된 모든 컴포넌트들의 사용법과 설정법에 대해 보여

드렸습니다. 제 설명은 (폼 디자이너를 사용하여) 디자인 타임 방식으로 이루어졌지만, 원한다면

런타임 방식으로 (코드를 작성하여 라이브바인딩 컴포넌트들을 동적으로 생성하고 프로퍼티를

지정하는 식으로) 사용할 수도 있습니다. 심지어 여러분은 익스프레션 엔진을 직접적으로 사용하기

위한 코드를 작성할 수도 있습니다.

런타임 코드를 포함한 더욱 자세한 라이브바인딩 예제를 보시려면 Embarcadero Developer

Network 를 검색해 보길 바랍니다. CodeRage 6 에서 진행된 두 가지 프리젠테이션을 포함하여 Jim

Tierney 가 녹화한 라이브바인딩 자료들을 찾아보세요. 또한 제가 24 Hours of Delphi 에서 발표했던

라이브바인딩 프리젠테이션도 찾아볼 수 있습니다. Embarcadero Developer Network 는

edn.embarcadero.com 로 접속할 수 있습니다.

저자에 관하여

캐리 젠슨(Cary Jensen)은 Jensen Data Systems (JensenDaraSystems.com)의 CTO 입니다. Jensen

Data Systems 는 컨설팅과 교육, 개발, 문서화와 도움말 시스템을 개발하는 회사입니다. 1998 년부터

캐리는 광범위한 산업 분야의 데이터베이스, 인터넷 어플리케이션을 개발해 왔습니다. 캐리는

소프트웨어 개발 분야에서 20 권이 넘는 책의 베스트 셀러 작가이며, 이번 봄에 동료 작가인 Marco

Cantù 와 함께 Delphi Developer Days 2012 투어를 다니고 있습니다. 세계의 많은 곳에서 열리는

컨퍼런스와 워크샵, 세미나의 주된 강연자인 그는 겸손한 유머와 복잡한 문제에 대한 실용적인

접근으로 널리 존경 받고 있습니다. 캐리는 Rice 대학에서 인간/컴퓨터 상호작용 분야를 전공하여

인간 요인 심리학 박사 학위를 가지고 있습니다. 캐리의 최신 책인 Delphi in Depth:

ClientDataSets 은 http://www.JensenDataSystems.com/cdsbook에서 찾아 볼 수 있습니다.

감사의 글

저는 이 문서를 작성하면서 받은 많은 도움과 지원에 대해 감사하고 싶습니다. 특히 엠바카데로

테크놀로지의 수석 엔지니어인 Jim Tierney 에게 감사하고 싶습니다. 그는 참을성 있게

라이브바인딩의 내부 동작에 대해 많은 것을 설명해 주었고, 이 문서의 기술적 검토를 해주었습니다.

또한 많은 엠바카데로 직원들에게 감사하고 싶습니다. 엠바카데로 직원인 Michael Devery, Pawel

Glowacki, David Intersimone, Andreano Lanusse, Anders Ohlsson, Calvin Tang, John Thomas, Jason

Vokes 는 이 문서의 초안을 검토해 주었습니다. Jensen Data Systems 의 Loy Anderson 에게도

감사하고 싶습니다. 그는 이 문서의 여러 초안들을 정리(교열)해 주었습니다. 마지막으로, 저는

처음부터 끝까지 이 프로젝트를 관리해 준 Tim Del Chiaro 에게 감사하고 싶습니다.

http://www.jensendatasystems.com/cdsbook




1 M

DM

엠바카데로 테크놀로지는, 1993 년에 설립한 데이터베이스 툴 제작사입니다. 2008 년에 볼랜드의 개발툴 부문

「 CodeGear 」 를 합병하였습니다. 현재는 애플리케이션 개발자와 데이터베이스 기술자가 다양한 환경에서

소프트웨어 애플리케이션을 설계, 구축, 실행하기 위한 툴을 제공하는 최대 규모의 독립계 툴 제작사입니다.

미국 기업의 총수입 랭킹 「포천 100」중 90 개 기업과 전세계 300 만 이상의 고객이, 엠바카데로의 Delphi®、

C++Builder®, JBuilder® 등 CodeGear™제품과 ER/Studio®、DBArtisan®, RapidSQL® 등 DatabaseGear™

제품을 채용해, 생산성의 향상과 혁신적인 소프트웨어 개발을 실현하고 있습니다. 엠바카데로 테크놀로지스는,

샌프란시스코에 본사를 두고, 세계 각국에 지사를 전개하고 있습니다. 보다 자세한 내용은,

http://www.devgear.co.kr를 참고하시기 바랍니다.

데브기어는 미국 Embarcadero Technologies Inc.와 기존의 코드기어 한국 지사의 협력으로 전략적으로 설립된

엠바카데로 솔루션 전문 공급 기업입니다. 데브기어는 Delphi, C++Builder, JBuilder, Delphi Prism 등 개발툴

제품들과 ER/Studio, DB Optimizer, DB ChangeManager 등의 데이터베이스 툴 제품들에 대한 한국 시장에

공급은 물론 기술지원 및 교육 등의 기술 서비스를 제공합니다. 데브기어 웹 사이트는 http://www.devgear.co.kr/

이며 제품에 대한 문의는 [email protected] 로 하면 됩니다.

http://www.devgear.co.kr/

http://www.devgear.co.kr/

mailto:[email protected]

Technology

RAD Studio 라이브바인딩 이해하기