모범 사례 - SWF 애플리케이션 제작 지침

Animate 애플리케이션을 만드는 최선의 방법은 개발자가 만드는 애플리케이션 및 애플리케이션을 작성하는 데 사용되는 기술에 따라 다릅니다.

온라인 애플리케이션을 사용하면 해당 애플리케이션과의 상호 작용을 통해 사용자가 웹 사이트에 영향을 줄 수 있습니다. 예를 들어, 애플리케이션이 사용자로부터 정보(예: 등록을 위한 사용자 이름과 암호)를 수집하거나 정보가 포럼 등을 통해 사이트에 추가되거나 사용자가 채팅룸 또는 대화형 화이트 보드를 통해 실시간으로 사이트 방문자와 상호 작용할 수 있습니다. 상호 작용에 의존하여 서버의 결과는 흔히 SWF 파일에 표시됩니다. 이러한 예제는 사용자와 다양한 종류의 서버 상호 작용을 포함하는 애플리케이션입니다. 방문자 정보나 데이터를 사용하지 않는 웹 사이트는 애플리케이션이 아닙니다(예: 포트폴리오, 만화 애니메이션 또는 정적 정보 사이트). Animate 애플리케이션에는 사용자, 웹 애플리케이션 및 서버 간의 대화형 프로세스가 포함됩니다. 기본 프로세스는 다음과 같습니다.

애플리케이션을 작성할 경우 데이터 전송을 위한 프로토콜을 선택해야 합니다. 프로토콜은 데이터를 주고 받아야 하는 시점, 데이터를 전송할 때의 형식, 서버의 응답을 처리하는 방법을 애플리케이션에 알립니다. 데이터는 SWF 파일에 수신된 후 조작되고 형식이 지정되어야 합니다. 프로토콜을 사용하는 경우 데이터에 예기치 않은 형식이 지정되는 것을 염려할 필요가 없습니다. 이름-값 쌍을 사용하여 데이터를 전송하는 경우 데이터에 형식이 지정되는 방법을 확인할 수 있습니다. XML 형식 데이터가 수신되지 않고 SWF 파일에서 예상되는 데이터 및 작업할 데이터를 알 수 있도록 데이터에 올바르게 형식이 지정되는지 확인합니다.

데이터 수집 및 형식 지정

애플리케이션은 SWF 파일과의 사용자 상호 작용에 의존합니다. 종종 애플리케이션은 데이터를 양식에 입력하는 사용자에게 의존합니다. Animate는 Animate 애플리케이션에서 데이터를 입력하고 형식을 지정할 수 있는 다양한 방법을 제공합니다. 이러한 유연성이 제공되는 것은 애니메이션 기능, 인터페이스를 독창적으로 제어할 수 있는 기능, ActionScript를 통해 수행할 수 있는 오류 검사 및 유효성 검사 기능 등이 있기 때문입니다.

Animate를 사용하여 데이터를 수집하기 위한 양식을 작성할 경우 다음과 같은 이점이 있습니다.

• 디자인 제어가 향상됩니다.

• 페이지 새로 고침을 수행할 필요가 없거나 줄어듭니다.

• 공통된 에셋을 다시 사용합니다.

   사용자로부터 수집된 정보를 저장하려면 사용자 컴퓨터의 공유 객체에 해당 정보를 저장합니다. 공유 객체를 사용하면 쿠키를 사용하는 것과 비슷하게 사용자의 컴퓨터에 데이터를 저장할 수 있습니다. 공유 객체에 대한 자세한 내용은 ActionScript 2.0 언어 참조 설명서 또는 ActionScript 3.0 언어 및 구성 요소 참조 설명서의 sharedObject 클래스를 참조하십시오.

데이터 보내기 및 처리

일반적으로 정보를 서버에 보내기 전에 서버에서 이해할 수 있는 방식으로 형식이 지정되도록 정보를 처리해야 합니다. 서버에서 데이터를 수신하면 다양한 방법으로 데이터가 조작되어 SWF 파일에서 받을 수 있는 형식(이름-값 쌍에서 복잡한 객체에 이르는 다양한 형식)으로 SWF 파일에 다시 보내질 수 있습니다.

 애플리케이션 서버는 해당 출력의 MIME 유형을 application/x-www-urlform-encoded로 설정해야 합니다. 이러한 MIME 유형이 없을 경우 일반적으로 결과는 Animate에 도달했을 때 사용할 수 없습니다.

다음 표는 Animate를 사용하여 데이터를 서버로 보내고 데이터를 받기 위한 여러 옵션을 보여 줍니다.

데이터 로드 및 유효성 검사 추가

해당 데이터를 서버로 보내기 전에 검색된 모든 정보의 유효성을 검사합니다. 이렇게 하면 사용자가 필수 필드를 입력하지 않을 경우 원격 서버에서 많은 요청을 처리하지 않으므로 원격 서버의 부담이 줄어듭니다. 어떠한 애플리케이션에서도 클라이언트측 유효성 검사에만 의존해서는 안 되며 서버측 유효성 검사도 수행되어야 합니다.

간단한 등록 또는 로그인 양식을 작성하는 경우라도 사용자가 이름과 암호를 입력했는지 확인합니다. 요청을 원격 서버측 스크립트로 보내 결과를 기다리기 전에 이 유효성 검사를 수행합니다. 서버측 유효성 검사에만 의존해서는 안 됩니다. 사용자가 사용자 이름만 입력한 경우 서버측 스크립트는 요청을 받아서 전송되는 데이터의 유효성을 검사한 다음 사용자가 이름과 암호가 모두 필요하다는 오류 메시지를 Animate 애플리케이션에 보내야 합니다. 마찬가지로 유효성 검사가 클라이언트측에서만 수행될 경우(SWF 파일 내에서) 사용자는 SWF 파일을 해킹하여 유효성 검사를 회피하고 서버에 잘못된 데이터를 보내서 게시할 수 있습니다.

클라이언트측 유효성 검사는 양식 필드가 최소한 1자 길이인지 확인하거나 사용자가 문자열이 아니라 숫자 값을 입력했는지 확인하는 것처럼 간단한 작업이 될 수 있습니다. 예를 들어, 전자 메일 주소의 유효성을 검사하기 위해 Animate의 텍스트 필드가 비어 있지 않은지, 그리고 적어도 at 기호(@) 및 점(.) 문자가 포함되어 있는지 확인합니다. 서버측 유효성 검사의 경우 더 복잡한 유효성 검사를 추가하거나 전자 메일 주소가 유효한 도메인에 속하는지 확인합니다.

서버에서 SWF 파일로 로드되는 데이터를 처리하기 위해 ActionScript를 작성해야 합니다. 데이터를 SWF 파일로 로드한 후에는 해당 위치에서 데이터에 액세스할 수 있습니다. ActionScript를 사용하여 데이터가 완전하게 로드되는지 확인합니다. 콜백 함수나 리스너를 사용하여 데이터를 문서에 로드했다는 신호를 보낼 수 있습니다.

데이터를 로드할 때 다음과 같은 여러 방법으로 데이터에 형식을 지정할 수 있습니다.

• XML을 로드할 수 있습니다. 이 경우에 XML 클래스 메서드와 속성을 사용하여 데이터를 구문 분석하고 사용합니다. 이름-값 쌍을 사용하는 경우 쌍이 변수로 바뀌므로 이러한 쌍을 변수로 조작할 수 있습니다.

• 웹 서비스나 Animate Remoting에서 데이터를 수신할 수 있습니다.

두 경우 모두에 배열, 객체 또는 레코드 집합과 같은 복잡한 데이터 구조를 받을 수 있으며 이러한 구조를 적절하게 구문 분석하고 바인딩해야 합니다.

오류 처리 및 디버깅 사용

애플리케이션은 특정 오류를 예상하고 적절하게 처리할 수 있을 만큼 견고해야 합니다.

ActionScript 2.0에서 오류를 처리하는 가장 좋은 방법 중 하나는 사용자 정의 오류를 throw하고 catch할 수 있는 try-catch-finally 블록을 사용하는 것입니다. 사용자 정의 오류 클래스를 만들면 오류 처리 코드를 다시 작성할 필요 없이 애플리케이션 전체에서 코드를 다시 사용할 수 있습니다. 사용자 정의 오류 발생에 대한 자세한 내용은 ActionScript 2.0 언어 참조 설명서의 Error 클래스를 참조하십시오. try-catch-finally 블록에 대한 자세한 내용은 try..catch..finally(ActionScript 2.0 언어 참조 설명서)를 참조하십시오.

ActionScript 3.0에서는 flash.errors 클래스를 사용하여 오류를 catch합니다.

자세한 내용은 ActionScript 3.0 프로그래밍의 "애플리케이션에서 동기 오류 처리"를 참조하십시오.

파일 구성 및 코드 저장

파일 구성 및 코드 저장을 시작하기 전에 다음 지침을 고려해야 합니다.

• SWF 파일을 여러 SWF 파일로 분리합니까? 그렇다면 이러한 파일은 어떤 방법으로 상호 작용합니까?

• SWF 파일에서 공유할 수 있는 에셋은 무엇입니까?

• 동적으로 로드하는 파일은 무엇입니까?

• ActionScript를 어디에 어떤 방법으로 저장합니까?

  애플리케이션을 개발하는 경우 ActionScript 패키지의 경우와 비슷한 논리적 디렉토리 구조에 서버측 코드와 파일을 저장합니다. 코드를 이러한 방식으로 배열하면 잘 정리된 상태로 유지하고 코드를 덮어쓰는 위험성을 줄일 수 있습니다.

  보다 큰 애플리케이션의 경우 클라이언트 및 서버 간의 통신과 클래스의 서비스를 캡슐화합니다. 클래스를 사용할 경우 다음과 같은 이점이 있습니다.

• 둘 이상의 SWF 파일에서 코드를 다시 사용할 수 있습니다.

• 중앙 위치에서 코드를 편집하고 모든 SWF 파일을 다시 제작하여 업데이트할 수 있습니다.

• 비슷한 기능을 수행하는 서로 다른 UI 요소 또는 기타 에셋을 조작할 수 있는 단일 API를 만들 수 있습니다.

MVC 디자인 패턴 사용

MVC 디자인 패턴은 애플리케이션에서 정보, 출력 및 데이터 처리를 분리하는 데 사용됩니다. 애플리케이션은 세 가지 요소인 모델, 뷰 및 컨트롤러로 구분됩니다. 각 요소는 프로세스의 다른 부분을 처리합니다.

애플리케이션의 데이터와 규칙을 통합합니다. 대부분의 애플리케이션 처리는 디자인 패턴의 이 부분에서 발생합니다. 또한 모델에는 모든 구성 요소(예: CFC, EJB 및 웹 서비스)와 데이터베이스가 포함되어 있습니다. 반환된 데이터는 프로세스의 이 부분에서 애플리케이션의 인터페이스 또는 프런트 엔드에 맞게 형식이 지정됩니다. 반환된 데이터를 여러 다른 인터페이스나 뷰에 사용할 수 있습니다.

애플리케이션의 프런트 엔드(사용자가 상호 작용하는 인터페이스)를 처리하고 모델의 내용을 렌더링합니다. 인터페이스는 모델의 데이터가 표시되고 사용자가 사용할 뷰를 출력하는 방법을 지정하며 애플리케이션의 데이터를 조작 및 액세스할 수 있는 기능을 사용자에게 제공합니다. 모델이 변경될 경우 뷰는 데이터를 밀어넣거나 가져와서(보내거나 요청해서) 이러한 변경 사항을 반영하도록 업데이트됩니다. 혼합 웹 애플리케이션(예: 페이지에서 다른 애플리케이션과 상호 작용하는 Animate를 포함하는 애플리케이션)을 만드는 경우 디자인 패턴에서 뷰의 일부로 여러 인터페이스를 고려해야 합니다. MVC 디자인 패턴은 다양한 뷰를 처리하는 것을 지원합니다.

데이터를 처리 및 표시하기 위해 모델과 뷰의 요구 사항을 처리하며 일반적으로 많은 코드를 포함합니다. 인터페이스 또는 뷰에서의 사용자 요청에 따라 모델의 임의 부분을 호출하며 애플리케이션과 관련된 코드를 포함합니다. 이 코드는 애플리케이션과 관련되므로 일반적으로 다시 사용할 수 없습니다. 하지만 디자인 패턴의 다른 구성 요소는 다시 사용할 수 있습니다. 컨트롤러는 데이터를 처리하거나 출력하지 않지만 사용자로부터 요청을 가져와 호출해야 하는 모델 또는 뷰 구성 요소의 부분을 결정하고 데이터를 보낼 위치 및 반환된 데이터에 적용되는 형식을 확인합니다. 컨트롤러는 뷰가 표시해야 하는 모델 데이터의 일부분에 해당 뷰가 액세스할 수 있도록 합니다. 일반적으로 컨트롤러는 모델과 뷰를 포함하는 변경 사항을 전송하고 응답합니다.

모델의 각 부분은 전체 프로세스에서 포함된 구성 요소로 작성됩니다. 모델의 한 부분을 변경할 경우(예를 들어, 인터페이스를 재작업할 경우) 일반적으로 프로세스의 다른 부분에는 수정이 필요하지 않으므로 문제가 줄어듭니다. 디자인 패턴이 올바르게 만들어진 경우 모델 또는 컨트롤러를 재작업하지 않고 뷰를 변경할 수 있습니다. 애플리케이션에서 MVC를 사용하지 않을 경우 한 부분을 변경하면 모든 코드에 영향을 줄 수 있습니다. 이 경우 특정 디자인 패턴을 사용할 때보다 많은 변경이 필요합니다.

MVC 패턴을 사용하는 중요한 이유는 데이터와 논리가 사용자 인터페이스에서 분리되기 때문입니다. 프로세스의 이러한 부분을 분리하면 동일한 모델과 형식이 지정되지 않은 데이터를 사용하는 여러 다른 그래픽 인터페이스를 가질 수 있습니다. 즉, 웹을 위한 인터페이스, Pocket PC를 위한 인터페이스, 휴대 전화를 위한 버전, Animate를 전혀 사용하지 않는 HTML 버전 등과 같은 다양한 Animate 인터페이스와 함께 애플리케이션을 사용할 수 있습니다. 데이터를 애플리케이션의 나머지 부분에서 분리하면 둘 이상의 클라이언트 인터페이스를 개발, 테스트 및 심지어 업데이트하는 데 필요한 시간이 크게 줄어들 수 있습니다. 마찬가지로 사용할 기존 모델이 있는 경우 동일한 애플리케이션을 위한 새 프런트 엔드를 보다 쉽게 추가할 수 있습니다.

전자 상거래 웹 사이트나 전자 학습 애플리케이션과 같은 크거나 복잡한 애플리케이션을 작성할 경우에만 MVC를 사용합니다. 아키텍처를 사용하면 Animate 및 이 디자인 패턴이 작동하는 방법을 계획하고 이해해야 합니다. 여러 다른 부분이 서로 상호 작용하는 방법을 신중하게 고려하십시오. 일반적으로 테스트와 디버깅이 이 작업에 포함됩니다. MVC를 사용할 경우 일반적인 Animate 애플리케이션의 경우보다 테스트와 디버깅이 더 어렵고 복잡합니다. 더욱 복잡한 애플리케이션을 작성하는 경우 MVC를 사용하여 작업을 구성하는 것이 좋습니다.

보안 애플리케이션 만들기

로그인하여 문서를 읽을 수 있는 작은 포털 사이트를 작성하든지, 큰 전자 상거래 사이트를 작성하든지 상관없이 악의적인 사용자가 애플리케이션의 해킹을 시도할 수 있습니다. 이러한 이유 때문에 애플리케이션 보안을 위한 다음 단계를 고려해야 합니다.

• 보안이 필요한 데이터의 경우 데이터를 HTTPS에 게시합니다. 값을 처리하기 위해 원격 서버로 보내기 전에 Animate에서 값을 암호화합니다.

   사용자에게 표시하지 않으려는 정보나 코드는 SWF 파일에 저장하지 마십시오. 타사 소프트웨어를 사용하여 SWF 파일을 손쉽게 분해하고 내용을 볼 수 있습니다.

• 허가되지 않은 도메인이 에셋에 액세스하는 것을 방지하는 크로스 도메인 정책을 추가합니다.