'개발도 하냐?' 카테고리의 다른 글
| 웹2.0 지불대행서비스 이니시스 C2C Payment (0) | 2008.01.20 |
|---|---|
| 새로운 웹 표준 테스트, Acid3 (0) | 2008.01.11 |
| 오픈아이디로 사용가능한 웹서비스 (0) | 2007.07.27 |
| Struts에서 Spring으로의 이주 가이드. (0) | 2007.07.26 |
| 사파리 윈도우용 출시 (0) | 2007.07.03 |
개발도 하냐?
- 웹접근성 2008.01.03
- 오픈아이디로 사용가능한 웹서비스 2007.07.27
- Struts에서 Spring으로의 이주 가이드. 2007.07.26
- 사파리 윈도우용 출시 2007.07.03
- 미래를위한선택-웹호환성 2007.06.18
- EMAIL 에러메세지 2007.04.19
- CreateObject("CDO.Message") 2007.04.17
- CDOSYS를 사용하여 ASP에서 메일발송 2007.04.17
- 웹 호환성 평가항목 2007.02.07
웹접근성
2008. 1. 3. 10:18
오픈아이디로 사용가능한 웹서비스
2007. 7. 27. 10:19
오픈아이디로 사용가능한 웹서비스
집, 학교, 회사 언제 어디서나 쓸 수 있는 노트 한 권, 스프링노트는 함께 쓰는 인터넷 노트 입니다.
나만의 스프링노트에 글을 쉽게 쓰고 관리할 수 있으며, 노트를 여럿이 함께 쓸 수 있습니다.
오픈아이디로 누구나 스프링노트를 개설하고, 친구들을 초대할 수 있습니다.
라이프팟
라이프팟은 일정관리용 인터넷 캘린더로 내 일정관리는 물론, 일정 공유 기능을 활용하여
애인과 함께 커플일정을 관리하거나, 회사 내 팀원들과 일정을 공유하고 관리할 수 있습니다.
자신의 블로그나 새로운 정보를 비롯한 세상의 모든 콘텐츠 중 공유하고 싶은 정보를 만났을 때 간단한 주소(URL) 등록을 통해서 실시간으로 다른 회원들과 공유할 수 있는 서비스입니다.
특히 부가기능인 미니펌핏과 붐바는 자신의 블로그를 가장 빨리, 가장 쉬운 방법으로 홍보할 수 있는 수단으로도 활용할 수 있습니다.
뿐만 아니라 댓글를 통한 토론도 함께 할 수 있습니다. 이렇게 등록된 정보는 추천(펌프업)에 따라 인기도가 산정됩니다.
펌핏의 최종 모델은 온라인 토론 플랫폼입니다. 이를 위해 조만간 회원들이 실시간으로 가볍게 토론하고 설문조사도 할 수 있는 기능을 추가할 계획입니다.
레뷰는 리뷰를 중심으로 다양한 상품, 문화, 경험에 대한 쇼핑과 선택을 지원하는 소셜 쇼핑 사이트 입니다.
사용자는 오픈ID를 이용하여 로그인하실 수 있고, 로그인 후 다양한 관심 아이템의 등록, 평가, 태깅을 하실 수 있으며,관심있는 아이템들을 모아서 '내가 추천하는 핸드폰", "최고의 와인바", "여름 피서지 10선"등의 컬렉션도 만드실 수 있습니다.
여러분이 관심을 갖는 많은 상품이나 서비스에 대해 다른 사용자가 어떤 리뷰를 하고 있는지,어떤 평가를 하고 있는지 참고하시기에 가장 유용한 사이트입니다. 물론 가격이나 위치 정보도 보실 수 있고요.
'개발도 하냐?' 카테고리의 다른 글
| 새로운 웹 표준 테스트, Acid3 (0) | 2008.01.11 |
|---|---|
| 웹접근성 (0) | 2008.01.03 |
| Struts에서 Spring으로의 이주 가이드. (0) | 2007.07.26 |
| 사파리 윈도우용 출시 (0) | 2007.07.03 |
| 미래를위한선택-웹호환성 (0) | 2007.06.18 |
Struts에서 Spring으로의 이주 가이드.
2007. 7. 26. 18:13
원문 : http://www.devx.com/Java/Article/29208
Struts에서 Spring으로의 이주 가이드.
당신은 이 글을 통해 Struts애플리케이션에서 Spring MVC애플리케이션으로 변형하는 방법뿐 아니라 두 프레임워크사이의 논리적인 맵핑과 Struts개념을 Spring MVC개념에 관련시키는 수단을 배울것이다.
사실 Struts프레임워크는 기술발전이나 채택이 감소하기 시작하고 있다고 몇몇 사람들이 제기한다. 사실 Struts의 책임 개발자인 Craig McClanahan또한 Struts사용자에게 새로운 웹 프레임워크로의 이전을 권하고 있는 상황이다. 반면에 J2EE웹 공간에서, Spring MVC는 꾸준한 채택과 자바 개발자의 주의를 끌고 있다. 가장 인기있는 Spring프레임워크는 잘 디자인되었으며, 잘 만들어졌고, 혁신적이다. 그래서 많은 Struts사용자는 Struts를 위한 대체 프레임워크처럼 Spring을 MVC를 사용할것이다.
이 글은 Struts애플리케이션을 Spring MVC로 이전하길 원하는 개발자들을 도와준다. 그리고 다음의 두가지 핵심부분으로 나누어져있다.
Struts와 Spring MVC프레임워크의 기본 개념사이의 논리적인 맵핑.
이전 대체물을 위한 기본적인 추천사항들.
논리적인 맵핑 : 다른 프레임워크간의 유사함.
Struts와 Spring은 MVC패턴 구현에서 본질적으로 유사하다. 둘다 핵심 J2EE컴포넌트인 Servlet과 JSP에 기반한 모델2 타입의 개발방식을 주로 할려는 경향이 있다. Struts에 친숙한 개발자는 하나의 프레임워크에서 다른것으로 개념적으로 쉽게 이주할수 있다. 두가지 프레임워크 모두 View, Controller, Model의 역활을 제공하는 컴포넌트를 명백하게 서술하고 있다. 유사성은 구현레벨에서 멈춘다. Struts디자인은 각각의 사용자지정 action이 Struts Action컴포넌트의 구조적인 상속이 된다는것을 의미하는 견고한 상속에 기반을 둔다. Spring컨트롤러는 인터페이스이기 때문에, 어떠한 컴포넌트도 컨트롤러의 역활을 수행할수 있다. 이것은 애플리케이션 디자이너에게 컴포넌트 디자인의 좀더 나은 유연함을 제공한다.
프레임워크 컴포넌트 레벨에서 Struts는 Form Beans (정적이거나 동적인), Actions, Action Mappings, Action Forwards, 그리고 Request Processors와 같은 Struts 특유의 객체 사용을 요구한다. Spring MVC는 주요한 컴포넌트가 인터페이스처럼 정의된것처럼 좀더 유연하다.
Struts는 오직 웹 프레임워크일 뿐이다.
Struts는 애플리케이션 개발에서 오직 presentation계층에만 할당한다. 반면에 Spring MVC는 비지니스 컴포넌트에다가 Spring 기업용 개발의 다른 부분을 관리하는 Spring 프레임워크의 다른 부분과 완벽하게 통합되는 Spring프레임워크의 주요한 부분일뿐이다. 이제 좀더 상세하게 프레임워크 컴포넌트를 보자.
Struts Actions는 대략 Spring Controllers이다.
Struts에서 Action은 프레임워크의 핵심 "processing"객체이다. 그것들은 MVC패턴에서 컨트롤러의 역활을 수행한다. Struts Actions의 Spring이 가진 대안은 Controller인터페이스이다. 반면에 Controller는 Spring에서 사용자 입력을 처리하고 View컴포넌트로 전달한다. Struts Actions과 Spring Controller사이의 가장 명백한 차이점은 Actions는 추상 클래스이고 Controllers는 인터페이스라는 것이다. Spring MVC 컨트롤러처럼 설정되기 위해서, 객체는 오직 다음의 메소드를 구현할 필요가 있을것이다.
ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception;
이 디자인(인터페이스에 의한 디자인)은 애플리케이션과 프레임워크간의 커플링을 최소화한다. 또한 이것은 Controllers의 디자인에서 구조적으로 좀더 유연성을 제공한다. 이것을 염두해 두고, Struts에서 Spring으로의 가장 간단한 중계역활을 하는 이전(transition) 단계는 Action을 다시 쓰는 것이다. 그래서 그것들은 Controller인터페이슬ㄹ 구현하고 존재하는 코드를 재사용하는것이다. 이것은 애플리케이션 작동을 유지하는 동안 모든 Struts의존성의 제거를 증가시키는것을 허용한다.
Spring은 다른 Action대체물도 제공한다. 많은 수의 프레임워크가 제공하는 Controller구현물은 가장 공통적인 웹애플리케이션 작업에 대응된다. 몇몇 제공되는 Controller는 당신이 친숙한 Struts Action에 좀더 특성화된 것에 대응된다. 예를 들어, 당신이 DispatchActions을 사용한다면, MultiActionControllers와 좀더 잘 다듬어진 AbstractWizardFormControllers가 도움을 줄것이다. 다른 Controller구현문은 Spring MVC에 딸려나온다.
Action Forms이 없다.
Spring프레임워크내에서 가장 크고 가장 긍정적인 차이점중에 하나는 특성화된 ActionForm객체가 없다는 것이다. 프레임워크는 HTTP폼 값을 직접적으로 POJO에 바인딩하는것을 지원한다. 이 기능은 생성하고 유지할 클래스의 수를 제한하여 애플리케이션 유지관리를 단순화한다. 이 경우, 이전(migration)은 폼빈즈를 삭제하고 직접적으로 도메인 객체를 사용하는것을 의미한다. 어쨌든, 이것은 당신이 폼입력과 도메인 객체간의 맵핑처럼 Form Bean객체를 사용할수 있다면 필수단계는 아니다. Spring MVC에서, AbstractFormController구현물을 확장하는 특수한 목적의 Controllers는 폼을 지지하는 빈즈를 지원한다. AbstractFormController의 사용자지정 하위클래스는 폼객체처럼 폼을 지지하는(Command) Beans를 사용한다. 다시 말해, 이러한 빈즈를 정의하는 요구사항은 없다. Command객체는 java.lang.Object의 어떠한 하위클래스도 될수 있다.
ActionForwards vs. ModelAndView
Struts ActionMapping에서, 객체는 표현자원(Actions, JSPs, Tiles, HTML 파일들 등등.)을 가리킨다. Spring MVC에서 ActionMapping에 대해 가장 가까운 의미의 컴포넌트는 ModelAndView인터페이스이다. Spring Controllers는 사용자에 의해 구현될수 있는것처럼 ModelAndView인터페이스의 구현물을 반환한다. 또는 당신이 원한다면 Spring MVC에 의해 제공되는 ModelAndView구현물을 사용할수도 있다. 내포하는 이름처럼, ModelAndView객체는 Model과 View컴포넌트를 가진다. Model컴포넌트는 View컴포넌트를 통해 표시되기 위한 비지니스 객체를 포함한다. 시나리오에 따르면, ModelAndView구현물은 포함된 어떠한 Model컴포넌트를 가지지 않는다. 그것들은 아마도 실질적인 View컴포넌트(JSP, XSLT, Tiles, HTML, XML, 등등)의 몇몇 형태로 이끌것이다. Controller구현물에서 처럼, 나는 Spring MVC가 제공하는 Model의 구현물과 View인터페이스 그리고 View해석자(Resolver)를 조사하는것을 강력히 권한다.
사용자지정 JSP 태그들
Spring MVC는 표준 JSP태그 라이브러리의 의미있는 힘을 신뢰한다. Struts와는 달리, Spring MVC는 HTML, logic, 또는 bean처리를 위한 분리된 태그 라이브러리를 제공하지 않는다. 이것은 Command객체에서 Web form으로의 바인딩을 가능하게 하는 작은 태그라이브러리만을 제공한다. 당신은 다른 모든 작업을 위해 표준적인 템플릿 라이브러리(JSTL)를 사용할것이다.
유효성체크(Validation)
만약 당신이 Struts의 Commons Validator을 사용한다면, 당신은 Spring내에서 완벽하게 재사용할수 있을것이다. Spring 1.2는 Commons기반 유효성체크를 지원하지 않지만 Spring MVC의 "sandbox"버전은 Commons Validator마크업 (validator.xml 과 validation-rules.xml)으로 쓰여진 유효성체크 정의의 재사용을 지원한다. 유효성체크 선언를 가진 당신의 XML파일을 버리지 마라. 그것들은 Spring내에서 재사용가능할것이다.
Error 와 Validation Messages
좀더 좋은 소식이 있다. Spring은 동일한 형태로 Struts message번들을 인식한다. Spring MVC내 존재하는 Message자원들을 재사용하기 위해서, 당신은 Spring MVC 설정파일내 messageSource가 다음처럼 설정한다.
<bean id="messageSource"
class="org.springframework.context.support.ResourceBundleMessageSource">
<property name="basename">
<value>resources.ApplicationResources</value>
</property>
</bean>
또한, 당신은 Controller구현물내 messageSource프라퍼티로써 당신의 Controller처럼 이것을 사용할 필요가 있다. 요구되는 변경사항은 없다.
Dispatcher Servlet
Spring MVC는 Request Processor/Action Servlet의 자신만의 버전을 가진다. 이것은 URL표시그룹으로 맵핑되는 DispatcherServlet이다. Dispatcher Servlet의 개념을 이해하기 위해서, Controller를 Spring MVC내 설정하는 방법을 보자.
설정파일들
Struts사용자라면, 당신은 모든 forward, action mapping, form definition 그리고 플러그인 선언등을 가지는 적어도 하나의 struts-config.xml파일을 사용한다. Spring MVC에서, 모든 웹 애플리케이션관련 컨트롤러 선언은 Spring Beans처럼 설정된다. 하나이상의 Dispatcher Controller는 웹자원을 위한 모든 요청을 적당한 Controller로 보낸다. 예를 들면, 만약 당신이 ".do"애플리케이션을 Spring MVC애플리케이션으로 다시 맵핑시키길 원한다면, 당신은 애플리케이션의 web.xml에 다음처럼 서블릿 맵핑을 등록하라. (나는 당신이 .do 확장자를 사용하는것을 실질적으로 권하지 않는다. Struts만 사용하는 규칙처럼 ".do"를 남겨두라.)
<servlet>
<servlet-name>applicationDispatcher</servlet-name>
<servlet-class>
org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
...
<servlet-mapping>
<servlet-name>applicationDispatcher</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
지금 당신은 Spring MVC Controller선언을 가진 Spring 설정파일(applicationDispatcher-servlet.xml)을 가진다. "-servlet.xml"는 applicationDispatcher파일을 위한 접미사이다. 이것은 Spring MVC맵핑파일을 자동 리로드하는 DispatcherServlet을 가능하게 하는 Spring MVC규칙이다.
Spring MVC내에서 웹 action을 적당한 컨트롤러로 맵핑하는것은 매우 쉽다. 이것은 Spring애플리케이션의 일부처럼 같은 "wiring"형태로 수행된다. 다음의 예제는 URL expression /showCatalog.do를 Controller showCatalog로 포워드하는 방법을 보여준다.
<bean id="urlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="mappings">
<props>
<prop key="/showCatalog.do">showCatalog</prop>
</props>
</property>
</bean>
Controller showCatalog는 Controller인터페이스를 구현하는 클래스에 의해 구현된 다른 빈처럼 설정될것이다. 이 예제에서, showCatalog는 URL요청을 카테고리로 명명된 ModelAndView컴포넌트로 포워드하는 간단한 포워딩 컨트롤러에 지나지 않는다.
<bean id="showCatalog" name="showCatalog"
class="org.springframework.web.servlet.mvc.ParameterizableViewController">
<property name="viewName" value="catalog"/>
</bean>
Struts에서 Spring MVC로의 이전 경로.
Struts애플리케이션을 Spring MVC로 이전하기 위해서는 3가지 접근법이 있다. 몇몇은 애플리케이션을 점차적으로 이전할것이다. 다른것들은 Struts프레임워크를 완벽하게 포기하고 완전히 다시 쓰는 작업을 수행할것이다. 접근법들은 아래에서 개요를 말하고, 이전의 완벽함 순서대로 정렬된다.
1. Spring은 Struts컴포넌트를 가능하게 한다. 천천히 이전하길 원하는 사람들을 위해, 첫번째이고 완벽하게 이전에 따른 무리가 없는것은.? Spring Beans처럼 Struts Actions를 가능하게 하는것이다. 이것은 간단한 작업이고, Spring문서에 잘 설명되어 있다. 이것은 Struts코드에 대한 변경을 요구하지 않지만, 이것은 Spring Beans처럼 처리되기 위해 Struts Controller컴포넌트, Actions를 가능하게 한다. 이 처리로, Actions은 Spring Beans의 상태를 상속한다. 그러므로, Spring Controller처럼 많은 것을 보기 시작하라. 늦으면서 단계별로 현명한 이전은 이 처리로 가능하다. 각각의 Action은 애플리케이션 재작성과 현재 웹 연속물의 중단없이 Spring Controller에 의해 한번에 대체될수 있다.
2. Tiles를 사용하는 Spring Spring프레임워크에 의해 완전히 제공되는 다른 대체물은 순수한 "view" 프레임워크처럼 Tiles를 유지하는 동안 Spring MVC컴포넌트로 Struts Controller과 관련 컴포넌트(Actions, Form Beans, 등등)를 대체하는것이다. Spring MVC는 Tiles에 대한 특정 대안을 가지지 않는다. 그래서 구조는 Tiles에 대한 것을 유지하기로 결정하고 Spring MVC를 통해 그 작업을 하도록 만든다. 이 접근법의 하나의 심각한 단점은 당신이 웹애플리케이션내 두개의 다양한 웹 프레임워크를 효과적으로 유지관리하기 위해 유지관리를 위한 많은 노력과 두가지 프레임워크를 위한 추가적인 학습이 필요하다는 것이다.
3. 완전한 이전 완전한 이전은 Struts프레임워크의 모든 컴포넌트를 Spring MVC로 교체하는것을 의미한다. 이 처리의 마지막에는 Struts특성의 컴포넌트는 애플리케이션에 남지않는다.
Struts에서 Spring으로의 이주 가이드.
당신은 이 글을 통해 Struts애플리케이션에서 Spring MVC애플리케이션으로 변형하는 방법뿐 아니라 두 프레임워크사이의 논리적인 맵핑과 Struts개념을 Spring MVC개념에 관련시키는 수단을 배울것이다.
사실 Struts프레임워크는 기술발전이나 채택이 감소하기 시작하고 있다고 몇몇 사람들이 제기한다. 사실 Struts의 책임 개발자인 Craig McClanahan또한 Struts사용자에게 새로운 웹 프레임워크로의 이전을 권하고 있는 상황이다. 반면에 J2EE웹 공간에서, Spring MVC는 꾸준한 채택과 자바 개발자의 주의를 끌고 있다. 가장 인기있는 Spring프레임워크는 잘 디자인되었으며, 잘 만들어졌고, 혁신적이다. 그래서 많은 Struts사용자는 Struts를 위한 대체 프레임워크처럼 Spring을 MVC를 사용할것이다.
이 글은 Struts애플리케이션을 Spring MVC로 이전하길 원하는 개발자들을 도와준다. 그리고 다음의 두가지 핵심부분으로 나누어져있다.
Struts와 Spring MVC프레임워크의 기본 개념사이의 논리적인 맵핑.
이전 대체물을 위한 기본적인 추천사항들.
논리적인 맵핑 : 다른 프레임워크간의 유사함.
Struts와 Spring은 MVC패턴 구현에서 본질적으로 유사하다. 둘다 핵심 J2EE컴포넌트인 Servlet과 JSP에 기반한 모델2 타입의 개발방식을 주로 할려는 경향이 있다. Struts에 친숙한 개발자는 하나의 프레임워크에서 다른것으로 개념적으로 쉽게 이주할수 있다. 두가지 프레임워크 모두 View, Controller, Model의 역활을 제공하는 컴포넌트를 명백하게 서술하고 있다. 유사성은 구현레벨에서 멈춘다. Struts디자인은 각각의 사용자지정 action이 Struts Action컴포넌트의 구조적인 상속이 된다는것을 의미하는 견고한 상속에 기반을 둔다. Spring컨트롤러는 인터페이스이기 때문에, 어떠한 컴포넌트도 컨트롤러의 역활을 수행할수 있다. 이것은 애플리케이션 디자이너에게 컴포넌트 디자인의 좀더 나은 유연함을 제공한다.
프레임워크 컴포넌트 레벨에서 Struts는 Form Beans (정적이거나 동적인), Actions, Action Mappings, Action Forwards, 그리고 Request Processors와 같은 Struts 특유의 객체 사용을 요구한다. Spring MVC는 주요한 컴포넌트가 인터페이스처럼 정의된것처럼 좀더 유연하다.
Struts는 오직 웹 프레임워크일 뿐이다.
Struts는 애플리케이션 개발에서 오직 presentation계층에만 할당한다. 반면에 Spring MVC는 비지니스 컴포넌트에다가 Spring 기업용 개발의 다른 부분을 관리하는 Spring 프레임워크의 다른 부분과 완벽하게 통합되는 Spring프레임워크의 주요한 부분일뿐이다. 이제 좀더 상세하게 프레임워크 컴포넌트를 보자.
Struts Actions는 대략 Spring Controllers이다.
Struts에서 Action은 프레임워크의 핵심 "processing"객체이다. 그것들은 MVC패턴에서 컨트롤러의 역활을 수행한다. Struts Actions의 Spring이 가진 대안은 Controller인터페이스이다. 반면에 Controller는 Spring에서 사용자 입력을 처리하고 View컴포넌트로 전달한다. Struts Actions과 Spring Controller사이의 가장 명백한 차이점은 Actions는 추상 클래스이고 Controllers는 인터페이스라는 것이다. Spring MVC 컨트롤러처럼 설정되기 위해서, 객체는 오직 다음의 메소드를 구현할 필요가 있을것이다.
ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception;
이 디자인(인터페이스에 의한 디자인)은 애플리케이션과 프레임워크간의 커플링을 최소화한다. 또한 이것은 Controllers의 디자인에서 구조적으로 좀더 유연성을 제공한다. 이것을 염두해 두고, Struts에서 Spring으로의 가장 간단한 중계역활을 하는 이전(transition) 단계는 Action을 다시 쓰는 것이다. 그래서 그것들은 Controller인터페이슬ㄹ 구현하고 존재하는 코드를 재사용하는것이다. 이것은 애플리케이션 작동을 유지하는 동안 모든 Struts의존성의 제거를 증가시키는것을 허용한다.
Spring은 다른 Action대체물도 제공한다. 많은 수의 프레임워크가 제공하는 Controller구현물은 가장 공통적인 웹애플리케이션 작업에 대응된다. 몇몇 제공되는 Controller는 당신이 친숙한 Struts Action에 좀더 특성화된 것에 대응된다. 예를 들어, 당신이 DispatchActions을 사용한다면, MultiActionControllers와 좀더 잘 다듬어진 AbstractWizardFormControllers가 도움을 줄것이다. 다른 Controller구현문은 Spring MVC에 딸려나온다.
Action Forms이 없다.
Spring프레임워크내에서 가장 크고 가장 긍정적인 차이점중에 하나는 특성화된 ActionForm객체가 없다는 것이다. 프레임워크는 HTTP폼 값을 직접적으로 POJO에 바인딩하는것을 지원한다. 이 기능은 생성하고 유지할 클래스의 수를 제한하여 애플리케이션 유지관리를 단순화한다. 이 경우, 이전(migration)은 폼빈즈를 삭제하고 직접적으로 도메인 객체를 사용하는것을 의미한다. 어쨌든, 이것은 당신이 폼입력과 도메인 객체간의 맵핑처럼 Form Bean객체를 사용할수 있다면 필수단계는 아니다. Spring MVC에서, AbstractFormController구현물을 확장하는 특수한 목적의 Controllers는 폼을 지지하는 빈즈를 지원한다. AbstractFormController의 사용자지정 하위클래스는 폼객체처럼 폼을 지지하는(Command) Beans를 사용한다. 다시 말해, 이러한 빈즈를 정의하는 요구사항은 없다. Command객체는 java.lang.Object의 어떠한 하위클래스도 될수 있다.
ActionForwards vs. ModelAndView
Struts ActionMapping에서, 객체는 표현자원(Actions, JSPs, Tiles, HTML 파일들 등등.)을 가리킨다. Spring MVC에서 ActionMapping에 대해 가장 가까운 의미의 컴포넌트는 ModelAndView인터페이스이다. Spring Controllers는 사용자에 의해 구현될수 있는것처럼 ModelAndView인터페이스의 구현물을 반환한다. 또는 당신이 원한다면 Spring MVC에 의해 제공되는 ModelAndView구현물을 사용할수도 있다. 내포하는 이름처럼, ModelAndView객체는 Model과 View컴포넌트를 가진다. Model컴포넌트는 View컴포넌트를 통해 표시되기 위한 비지니스 객체를 포함한다. 시나리오에 따르면, ModelAndView구현물은 포함된 어떠한 Model컴포넌트를 가지지 않는다. 그것들은 아마도 실질적인 View컴포넌트(JSP, XSLT, Tiles, HTML, XML, 등등)의 몇몇 형태로 이끌것이다. Controller구현물에서 처럼, 나는 Spring MVC가 제공하는 Model의 구현물과 View인터페이스 그리고 View해석자(Resolver)를 조사하는것을 강력히 권한다.
사용자지정 JSP 태그들
Spring MVC는 표준 JSP태그 라이브러리의 의미있는 힘을 신뢰한다. Struts와는 달리, Spring MVC는 HTML, logic, 또는 bean처리를 위한 분리된 태그 라이브러리를 제공하지 않는다. 이것은 Command객체에서 Web form으로의 바인딩을 가능하게 하는 작은 태그라이브러리만을 제공한다. 당신은 다른 모든 작업을 위해 표준적인 템플릿 라이브러리(JSTL)를 사용할것이다.
유효성체크(Validation)
만약 당신이 Struts의 Commons Validator을 사용한다면, 당신은 Spring내에서 완벽하게 재사용할수 있을것이다. Spring 1.2는 Commons기반 유효성체크를 지원하지 않지만 Spring MVC의 "sandbox"버전은 Commons Validator마크업 (validator.xml 과 validation-rules.xml)으로 쓰여진 유효성체크 정의의 재사용을 지원한다. 유효성체크 선언를 가진 당신의 XML파일을 버리지 마라. 그것들은 Spring내에서 재사용가능할것이다.
Error 와 Validation Messages
좀더 좋은 소식이 있다. Spring은 동일한 형태로 Struts message번들을 인식한다. Spring MVC내 존재하는 Message자원들을 재사용하기 위해서, 당신은 Spring MVC 설정파일내 messageSource가 다음처럼 설정한다.
<bean id="messageSource"
class="org.springframework.context.support.ResourceBundleMessageSource">
<property name="basename">
<value>resources.ApplicationResources</value>
</property>
</bean>
또한, 당신은 Controller구현물내 messageSource프라퍼티로써 당신의 Controller처럼 이것을 사용할 필요가 있다. 요구되는 변경사항은 없다.
Dispatcher Servlet
Spring MVC는 Request Processor/Action Servlet의 자신만의 버전을 가진다. 이것은 URL표시그룹으로 맵핑되는 DispatcherServlet이다. Dispatcher Servlet의 개념을 이해하기 위해서, Controller를 Spring MVC내 설정하는 방법을 보자.
설정파일들
Struts사용자라면, 당신은 모든 forward, action mapping, form definition 그리고 플러그인 선언등을 가지는 적어도 하나의 struts-config.xml파일을 사용한다. Spring MVC에서, 모든 웹 애플리케이션관련 컨트롤러 선언은 Spring Beans처럼 설정된다. 하나이상의 Dispatcher Controller는 웹자원을 위한 모든 요청을 적당한 Controller로 보낸다. 예를 들면, 만약 당신이 ".do"애플리케이션을 Spring MVC애플리케이션으로 다시 맵핑시키길 원한다면, 당신은 애플리케이션의 web.xml에 다음처럼 서블릿 맵핑을 등록하라. (나는 당신이 .do 확장자를 사용하는것을 실질적으로 권하지 않는다. Struts만 사용하는 규칙처럼 ".do"를 남겨두라.)
<servlet>
<servlet-name>applicationDispatcher</servlet-name>
<servlet-class>
org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
...
<servlet-mapping>
<servlet-name>applicationDispatcher</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
지금 당신은 Spring MVC Controller선언을 가진 Spring 설정파일(applicationDispatcher-servlet.xml)을 가진다. "-servlet.xml"는 applicationDispatcher파일을 위한 접미사이다. 이것은 Spring MVC맵핑파일을 자동 리로드하는 DispatcherServlet을 가능하게 하는 Spring MVC규칙이다.
Spring MVC내에서 웹 action을 적당한 컨트롤러로 맵핑하는것은 매우 쉽다. 이것은 Spring애플리케이션의 일부처럼 같은 "wiring"형태로 수행된다. 다음의 예제는 URL expression /showCatalog.do를 Controller showCatalog로 포워드하는 방법을 보여준다.
<bean id="urlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="mappings">
<props>
<prop key="/showCatalog.do">showCatalog</prop>
</props>
</property>
</bean>
Controller showCatalog는 Controller인터페이스를 구현하는 클래스에 의해 구현된 다른 빈처럼 설정될것이다. 이 예제에서, showCatalog는 URL요청을 카테고리로 명명된 ModelAndView컴포넌트로 포워드하는 간단한 포워딩 컨트롤러에 지나지 않는다.
<bean id="showCatalog" name="showCatalog"
class="org.springframework.web.servlet.mvc.ParameterizableViewController">
<property name="viewName" value="catalog"/>
</bean>
Struts에서 Spring MVC로의 이전 경로.
Struts애플리케이션을 Spring MVC로 이전하기 위해서는 3가지 접근법이 있다. 몇몇은 애플리케이션을 점차적으로 이전할것이다. 다른것들은 Struts프레임워크를 완벽하게 포기하고 완전히 다시 쓰는 작업을 수행할것이다. 접근법들은 아래에서 개요를 말하고, 이전의 완벽함 순서대로 정렬된다.
1. Spring은 Struts컴포넌트를 가능하게 한다. 천천히 이전하길 원하는 사람들을 위해, 첫번째이고 완벽하게 이전에 따른 무리가 없는것은.? Spring Beans처럼 Struts Actions를 가능하게 하는것이다. 이것은 간단한 작업이고, Spring문서에 잘 설명되어 있다. 이것은 Struts코드에 대한 변경을 요구하지 않지만, 이것은 Spring Beans처럼 처리되기 위해 Struts Controller컴포넌트, Actions를 가능하게 한다. 이 처리로, Actions은 Spring Beans의 상태를 상속한다. 그러므로, Spring Controller처럼 많은 것을 보기 시작하라. 늦으면서 단계별로 현명한 이전은 이 처리로 가능하다. 각각의 Action은 애플리케이션 재작성과 현재 웹 연속물의 중단없이 Spring Controller에 의해 한번에 대체될수 있다.
2. Tiles를 사용하는 Spring Spring프레임워크에 의해 완전히 제공되는 다른 대체물은 순수한 "view" 프레임워크처럼 Tiles를 유지하는 동안 Spring MVC컴포넌트로 Struts Controller과 관련 컴포넌트(Actions, Form Beans, 등등)를 대체하는것이다. Spring MVC는 Tiles에 대한 특정 대안을 가지지 않는다. 그래서 구조는 Tiles에 대한 것을 유지하기로 결정하고 Spring MVC를 통해 그 작업을 하도록 만든다. 이 접근법의 하나의 심각한 단점은 당신이 웹애플리케이션내 두개의 다양한 웹 프레임워크를 효과적으로 유지관리하기 위해 유지관리를 위한 많은 노력과 두가지 프레임워크를 위한 추가적인 학습이 필요하다는 것이다.
3. 완전한 이전 완전한 이전은 Struts프레임워크의 모든 컴포넌트를 Spring MVC로 교체하는것을 의미한다. 이 처리의 마지막에는 Struts특성의 컴포넌트는 애플리케이션에 남지않는다.
'개발도 하냐?' 카테고리의 다른 글
| 웹접근성 (0) | 2008.01.03 |
|---|---|
| 오픈아이디로 사용가능한 웹서비스 (0) | 2007.07.27 |
| 사파리 윈도우용 출시 (0) | 2007.07.03 |
| 미래를위한선택-웹호환성 (0) | 2007.06.18 |
| EMAIL 에러메세지 (0) | 2007.04.19 |
사파리 윈도우용 출시
2007. 7. 3. 11:23
사파리 윈도우용 버젼은 윈도우 XP 와 비스타에서 동작
Safari 의 특징
1. 인터넷 익스플로러 7 보다 2배 빠른 페이지 로딩
파이어폭스 보다 1.6 배 빠름
2. 자바스크립트 해석 2배가량 빠름
3. 멋진 사용자 인터페이스
4. 쉬운 북마크
5. 팝업 차단
6. 인라인 파인드
7. 탭 브라우징
8. 스냅백
9. 폼 자동 채우기
10. RSS 내장
11. 텍스트필드 크기조절 가능
12. Private 브라우징
13. 끊임없는 시큐리티 향상
다운로드
http://www.apple.com/safari/download/
Safari 의 특징
1. 인터넷 익스플로러 7 보다 2배 빠른 페이지 로딩
파이어폭스 보다 1.6 배 빠름
2. 자바스크립트 해석 2배가량 빠름
3. 멋진 사용자 인터페이스
4. 쉬운 북마크
5. 팝업 차단
6. 인라인 파인드
7. 탭 브라우징
8. 스냅백
9. 폼 자동 채우기
10. RSS 내장
11. 텍스트필드 크기조절 가능
12. Private 브라우징
13. 끊임없는 시큐리티 향상
다운로드
http://www.apple.com/safari/download/
'개발도 하냐?' 카테고리의 다른 글
| 오픈아이디로 사용가능한 웹서비스 (0) | 2007.07.27 |
|---|---|
| Struts에서 Spring으로의 이주 가이드. (0) | 2007.07.26 |
| 미래를위한선택-웹호환성 (0) | 2007.06.18 |
| EMAIL 에러메세지 (0) | 2007.04.19 |
| CreateObject("CDO.Message") (0) | 2007.04.17 |
미래를위한선택-웹호환성
2007. 6. 18. 02:12
웹에 대한 중요성이 갈수록 대두되면서, 그에 따라서 웹접근성, 웹표준, 웹호환성이라는 단어를 자주 접하게 됩니다.
오늘 제가 이야기할 내용은 웹이란 어떤것이가, 그리고 웹표준, 웹호환성은 무엇을 의미하는가 정도를 이야기 드리고, 국내 웹환경의 현실을 짚어보면서 어떻게 하는것이 좋을까 같이 고민해보도록 하겠습니다.
웹호환성에 대한 이야기를 하기위해서 우선 웹이 어떻게, 왜 시작되었는지를 알 필요가 있습니다.
오늘날 웹이라부르는 월드와이드웹은 영국의물리학자 팀버너스리에 의해서 탄생되게 됩니다. 팀버너스리는 CERN연구소의 수천명 연구자들이 이기종 OS와 개발 환경에서 정보를 공유할 수 있도록 어떤 컴퓨터에서도 접근할 수 있는 리소스를 쉽게 제공하려는 목적으로 웹을 만들게 되었습니다.
그러므로 웹이 탄생한 이유는 "정보의연결을통한 지식의 공유와 학습"이라고 할 수 있습니다.
팀버너스리는 1980년 후반 다양한 환경에서 정보공유를 계속 고민하게 되었고, 1990년 최초의 인터넷주소 info.cern.ch 를 탄생시킵니다. 바로 제 1호 인터넷주소가 생긴 1990년을 인터넷의 시작이라고 볼수 있습니다
그후 1994년 월드와이드웹콘소시업 줄여서 W3C라고 부르는 웹을 위한 단체가 결성되어
현재는 510여개의 IT기업이 참여하여 세계 웹표준을 주도하고 있습니다.
웹표준 주도단체 W3C에서 이야기하는 웹의 주요이념은 7가지가 있는데
그중 웹표준, 웹호환성과 관련이 있는 3가지 이념에 대해서 알아보도록 하겠습니다.
첫째 Universal Access가 있습니다.
보편적접근이란 언어나 지역 그리고 계층, SW나 단말기, 운영체제등에 상관없이 웹을 사용할수 있어야 한다는 의미입니다
두번째 Semantic Web이 있습니다.
요즘 웹2.0을 기반으로한 기술을 논의하면서 자주 나타나는 용어인데 사람 뿐 아니라 컴퓨터도 이해 가능한 의미론적 웹을 말합니다.
세번째는 Interoperability 가 있습니다. 정보처리 상호운용성을 의미하죠.
상호운용성이란 어떠한 소프트웨어,하드웨어를 이용해서 웹을 보더라도 웹서비스에 이상이 없어야 한다는것을 의미합니다.
이전장에서 웹이 어떻게 생겨난 것인지를 살펴보았습니다.
이번에는 웹이 어떤것인지를 살펴보고, 웹표준이란 무엇을 말하는지 알아보도록 하겠습니다.
일반적으로 웹의 구성요소를 나누어보면 텍스트, 이미지, 동영상, 사운드, 기타플러그인 프로그램(인증서,파일업로드등)으로 구성되어 있습니다.
이런 콘텐츠를 표현하기 위한 웹의 기술은 HTML, CSS, ECMAScript, XML, DOM, AciveX 등이 벡엔드에서 사용되고 있습니다.
여러가지 다양한 기술요소들이 있는데 이것들은 크게 3가지 그룹으로 나누어집니다.
내용을 구성하는 기술(HTML,XHTML,XML)
표현을 담당하는 기술(CSS,XSL)
행동을 담당하는 기술(DOM & ECMAScript) 로 나누어지는데 가장 핵심적인 기술요소 3가지만 알아보도록 하겠습니다.
첫째 HTML
HTML(Hypertext Markup Languege) HTML은 웹페이지의 내용을 구성하는 대표적인 표준 언어를 말한다
Hypertext란 웹페이지에서 링크를 포함시켜 그 링크를 클릭했을 때 다른 웹페이지 또는 문서로 이동할 수 있게 해주는 기능을 의미하며 예전의 문서를 읽는 선형읽기 구조에서 비선형읽기가 가능하게 해주는 핵심적인 요소입니다. 그외 내용을 표현하는 요소들로는 데이터구조를 유연하게 표현할수있는 XML, XML과HTML의 중간단계 XHTML이 있습니다
두번째 CSS
CSS(Cascading Stylesheet)는 웹문서의 표현을 담당하는 언어입니다.
CSS는 주로 HTML을 구조적으로 출력하고, 외관을 장식하기 위한 역할을 하며, XML 문서를 간단한 방법으로 출력하는 방법으로는 XSL을 사용합니다.
세번째 DOM & ECMAScript
DOM
DOM은 문서의구조를 트리형태로 접근가능한 인터페이스 즉 각종 프로그램이나 스크립트를 통해 HTML을 동적으로 변화기키고자 할때 제공해주는 프로그램을 위한 문서구조입니다
ECMAScript
ECMAScript는 ECMA International의 ECMA-262 기술 명세에 정의된 표준화된 스크립트 프로그래밍 언어.
즉 ECMAscript 는 공통 javascript를 의미합니다.
웹 브라우저시장은 90년대 초반에 두개의 대표적인 회사의 제품이 대표적이었습니다
마이크로소프트사의 인터넷 익스플로러와 넷스케이프사의 넷스케이프 네비게이터(또는 커뮤니케이터)가 그것입니다. 두 회사는 각각 브라우저를 업데이트를 할 때마다 새로운 HTML에 대한 동적인 기능구현을 위해 각각의 javascript를 추가시켜 왔고 그로인해 넷스케이프사와 마이크로소프트사는 서로 다른 스크립트를 각자의 브라우저에서 사용하게 되었습니다 (넷스케이프는 Javascript, 마이크로소프트의 Jscript)
그러던 중 넷스케이프에서 ECMA International 에 웹문서 스크립트표준에 대한 명세를 제출하여 서로 규정을 맺고 javascript 1.5를 기준으로 표준 script 즉 ECMAScript 3rd 가 나왔으며, 이를 스크립트 표준 언어라고 이야기합니다.
지금도 각각 개발하긴 하지만 ECMAscript의 기본에 충실히 개발하고 있기 때문에 점차로 호환적인 측면에서 나아지고 있는 현실입니다. 물론 다른 웹브라우저(오페라나 모질라 등등) 에서도 이 표준을 따릅니다.
웹표준이란 지금까지 이야기한 W3C에서 제시하는 웹의 내용, 표현, 행동에 관련된 각종 기술표준을 의미하는것입니다.
지금까지 웹이란 어떤것인가, 그리고 웹표준은 무엇을 의미하는가에 대해서 알아보았습니다.
이번장부터는 국내웹환경의 문제점들을 짚어보고, 어떻게 해야할지에 대해서 고민해보도록 하겠습니다
국내웹환경의 첫번째문제는 브라우저호환성의 무시입니다.
대부분의 사람들에게 인터넷이 무엇이냐고 묻는다면 데스크탑바탕화면에 설치된 푸른색e아이콘 즉 마이크로소프트의 인터넷 익스플로러라고 이야기 할 것입니다.
그러나. 인터넷을 사용할수 있는 웹브라우저는 보시는 것처럼 인터넷익스플로러 이외에도 파이어폭스, 오페라, 사파리, 그외에도 퀑쿼러 링스등 다양하게 존재하고 있습니다.
실제 전세계 브라우저 사용량을 보면 90프로는 IE를 그외 10프로는 파이어폭스를 사용하고 있으며 그외의 브라우저들도 소수 사용되고 있습니다.
국내 웹환경의 두 번째 문제는 단말기접근성을 제공하지 않는다는 점입니다.
화면은 일반적으로 흔히 볼수 있는 웹사이트의 구조입니다.
텍스트버전,모바일버전,시각장애인용등의 웹사이트를 각각 제공하고 있는데 , 이것은 웹사이트를 제작할때 웹표준을 준수하지 않았기 때문에 중복개발비용이 발생되고있는 사례입니다 웹표준을 준수한다면 별도로 각각의 버전을 제작하는것이 아니라 CSS, 즉 내용과는 별개로 표현만 변경하는 방식을 적용하여 개발비용을 절감할수 있습니다.
CSS Zen Garden에서 보여주는 웹사이트들입니다.
이 사이트들은 모두 동일한 내용에 CSS만 변경한 같은 사이트입니다.
금방 이야기했던 표현과 구조의 분리를 통한 웹표준 개발을 하였을 때 한 개의 내용으로 표현할 수 있는 다양한 웹사이트의 사례입니다.
국내 웹환경의 세 번째 문제는 모든 레이아웃을 테이블로 처리하는 것입니다.
실제 HTML소스를 열어서 내용을 확인하면 콘텐츠간의 간격이나 레이아웃의 배치를 위해서, 테이블안의 테이블 또 그안의 테이블. 이런 형식으로 중첩된 테이블을 사용하고 있습니다.
구조와 표현을 분리하는 웹표준 개발방식을 적용한다면 테이블 레이아웃은 CSS레이아웃으로 대체되고 웹페이지는 용량이 줄어들게 되므로 트래픽 감소효과를 가져오게 됩니다.
실제 마이크로소프트는 2004년 테이블을 모두 빼고 웹표준 개발방식을 적용하여 CSS레이아웃을 사용하여 웹사이트 전면 개편 하였습니다. 그 결과 하루에 924GB의 트래픽을 감소시키게 되었고 속도향상을 가져왔습니다.
국내 웹환경의 4번째 문제는 비표준 스크립트의 남용입니다.
한국소프트웨어진흥원에서 실시한 2006년 1007개 국내 공공 및 민간 홈페이지에 대한 웹호환성 조사결과에 따르면 국내 스크립트 표준 준수율은 16.8% 입니다.
대부분의 웹사이트가 웹표준 비준수로인한 오류를 다수포함하고 있으며, 특히 스크립트표준 비준수로 인한 브라우저간 상호운용성이 심각한 수준입니다
마지막으로 정보접근성에 대한 배려가 없는점을 들수있습니다.
- 소수 운영체제 및 브라우저 사용자(리눅스의 파이어폭스, 매킨토시의 사파리등)
- 비 PC단말기 사용자 (PDA, Phone)
- 인터넷 환경이 열악한 제3세계 재한국인
- 정보 소외 계층(노인 및 장애인, 농민 및 빈민)
이 부분은 오늘 많이 들으신 내용이죠.
지금까지 국내 웹환경의 현실에 대해서 전반적으로 살펴보았습니다.
여기에서 한가지 의문사항이 있습니다. 웹접근성, 웹표준, 웹호환성은 어떤차이가 있는걸까요?
웹표준이란 앞에서 이야기드린것처럼 W3C에서 제시하는 웹의 내용,표현,행동에 관련된 각종 기술표준을 이야기합니다.
웹접근성과 웹호환성은 화면에 보시는것처럼 웹표준을 공통으로 포함하고 있습니다.
이 이야기는 웹표준을 준수하는것 만으로는 웹접근성이나 웹호환성이 보장되지 않는 다는 것을 의미합니다.
그리고 웹호환성을 준수하더라도 웹접근성은 보장되지 않는다는 이야기이기도 합니다.
웹접근성이란 보편적접근성 확보를 우선시하고, 웹호환성은 OS,SW에 독립적인 상호운용성 확보를 우선시합니다.
처음부분에서 설명드린것 처럼 웹의 이념은 유니버셜액세스(보편적 접근성)도 필요하고, 시맨틱웹(컴퓨터가 이해가능한웹), 인터오퍼러빌리티(상호운용성)까지 모두 포함하고 있습니다.
그러므로, 웹2.0시대에 맞는 웹서비스를 위해서는 웹표준을 준수하면서 웹접근성과 웹호환성을 다같이 고민해야 하는것입니다.
이 내용은 한국소프트웨어진흥원에서 2006년 실시한 웹호환성 준수검사의 평가항목입니다.
평가항목은 앞에서 이야기드린것처럼 웹표준준수여부에 대한 3가지항목 HTML , CSS, ECMAScript 준수여부와 함께 인터넷익스플로러, 파이어폭스, 사파리를 이용한 브라우저간 상호운용성 9개항목으로 웹표준과 상호운용성을 포함하여 구성되어 있습니다.
보시는 화면은 국내 웹사이트 호환성을 조사한 결과입니다.
전체 호환성 준수율은 66.5점, 공공부문이 민간부문보다는 조금 높은 수준이었고, 민간부문중 금융부문은 ActiveX의 과다한 사용으로인해 매우낮은 수준으로 조사되었습니다.
도대체 그럼 왜 웹호환성이 이렇게 나빠진것일까 요.
외부적인 요인으로
첫째, 96~99년간 소위 브라우저 전쟁기간 동안 IE vs. Netscape의 비표준을 기반한 경쟁 후 IE 전용 기술만 잔재로 남게 되었기 때문입니다.
다른 브라우저를 고려할 필요가 없는 현실이었다는 이야기입니다
둘째, 표준 기술에 대한 웹디자이너/UI 개발자 등 웹 생산 종사자 재교육 및 자기 개발 부재입니다.
다른 브라우저를 고려할 필요가 없으니 당연히, 가르칠필요도 배울필요도 없는 현실이 되었던 것입니다.
내부적인 요인으로는
첫째, 국내 인터넷 환경의 급격한 성장을 꼽을수 있습니다.
급격한 인터넷 산업화로 인해서 엔터테인먼트 인터넷으로 진화하게 되었고, 세계에서 첫째가는 IT인프라를 보유하게 되었습니다. 그러다보니 더많은 기능을 요구하게 되었고, 웹에 대한 기본 인식 및 개발 방식에 대한 이해가 없는 상황에서 공공재로서의 웹이라는 인식없이 각종 비표준 플러그인기술을 발전시키게 되었습니다.
그 결과 엄청난 비표준 웹페이지가 양산되었고 현재 국내의 웹페이지를 보면 테이블 레이아웃을 사용하는것이 거의 100%, 링크 대신 자바스크립트 액션을 사용하는것이 80% 정도로 판단하고 있습니다
비 표준 주요 실례를 보면
- MS 기반 태그 : <marquee>, <object>, <iframe>
- W3C DOM vs. MS DOM
- document.all -> document.getElementByID
- MS 기반 Java Script/VBScript vs. ECMA Script (스크립트 표준)등을 들 수 있으며
뿐만 아니라 Windows Media Player 호환 포맷만 사용함으로 인해서 다른 운영체제 사용자는 해당 콘텐츠를 볼 수 없는 상황이므로 Cross Platform 미디어 포맷에 대한 고려가 필요합니다.
호환성이 안지켜지는 또다른문제는 ActiveX입니다.
ActiveX는 특정 OS 및 브라우저에 종속적인 기술로 국내 ActiveX 사용량은 세계 최고입니다.
-코드사인 인증서 배포율 1위 (Verisign:Thawte=320:720 per year)
-1400여개가 넘는 배포 사이트 존재 (거의 대부분 기업 웹사이트)
-외국에서는 주요 플러그인 외에는 스파이웨어 취급을 당하고 있음.
ActiveX 문제가 발생한 주요 원인
- 일찍 수립된 공인 인증 체계: IE 브라우저 독점화에 기술 종속
- 빠른 브로드 밴드 진입 : 플러그인 다운로드가 쉬움
- 어플리케이션 웹: 정보 제공 수단이 아닌 기능적 웹으로 진화
- 오락적인 인터넷 사용 행태 : 온라인 게임, 채팅, 사용자 제어 등
ActiveX 주요 사용처
-공인 인증 사용: 인터넷 뱅킹, 증권 거래, 카드 결제, 보험, 전자 정부 등
-엔터테인먼트: 온라인 게임, 로그인, 채팅 및 메신저, 파일 첨부
-스파이 웨어: 광고 및 해킹 프로그램
그럼 도대체 왜 최근에 웹호환성이 제기되는 것일까요
이슈의 첫번째 원인은 공개SW 파이어폭스가 나타나서 새로운 웹브라우저가 시장을 점유하기 시작했기 때문입니다
Mozilla Firefox는 웹 표준을 기반으로 하는 경량의 공개 SW 웹브라우저로서 출시 100일 만에 2천8백만 다운로드 기록하였고,100개 언어로 프로젝트가 진행되며, 1만명의 테스터를 가진 SW입니다
파이어폭스는 웹 표준을 가장 잘 표현하는 브라우저이며, 탭브라우징 및 팝업 차단, 라이브 북마크 및 RSS 구독 기능 그 외 통합 검색 및 테마 및 웹 개발자를 위한 확장 기능등을 제공하는 우수한 브라우저입니다.
두번째는 윈도우 비스타 출시에 따른 ActiveX 배포방식변경입니다.
액티브X를 활용한 응용 프로그램과 윈도 비스타의 충돌문제로 전자정부, 인터넷뱅킹 등 대국민 서비스에 차질을 빚은 이후 행정자치부, 정보통신부 등 정부기관들이 액티브X 사용 배제, 모든 브라우저 지원 등 표준 준수 움직임을 본격화하고 하고 있으며, 행자부에서는 액티브X 사태 이후 신규 발주사업의 제안요청서에 특정 업체 제품(기술)만 지원하지 않도록 하고 웹 표준을 준수해 다양한 운영체제(OS)와 한 개 이상의 브라우저에서 작동할 수 있게 구현할 것을 지시하고 있습니다.
폭발적인 파이어폭스 점유율. 2003년 4%부터 꾸준히 증가하여 2007년 현재 전세계 11.69% 사용 중
그럼 웹표준을 지키면 무엇이 좋아지는 것일까요.
첫째, 고객의 양적 질적 증가
- 웹표준 준수는 친환경 경영과 같은 것. 고객의 기업 인지도 향상.
- 브라우저 호환을 통해서도 훌륭한 서비스 구현 가능
- 야후닷컴, 구글 Gmail, Maps
- 소수 사용자는 오피니언 리더다.
- 리눅스 및 맥킨토시 사용자는 인터넷 오피니언 리더이다.
둘째, 개발 속도 및 효율성 증가
- 브라우저에 따른 고려가 없어지므로 개발이 빠름.
- 표준 구현이 능숙해 지는 경우 개발 속도 향상
셋째, 레이아웃 변경이 용이
- 일반, 다국어 웹사이트, 텍스트, 장애인, 모바일 다양한 레이아웃 한꺼번에 제공 가능
- 구조와 표현의 분리에 따른 개발자-디자이너 협업 체계 구축.
- 개발자와 디자이너의 이중 작업 감소 및 영역 보장
넷째, 품질관리제공
- W3C Validation 및 자바스크립트 디버거를 통한 QA 보장
다섯째, 유지 비용의 감소
- 웹페이지 서버 트래픽 및 장비 비용 최소화
- 야후!닷컴: 같은 UI로도 첫화면 파일 크기를 1/3로 줄임.
- ESPN.com: 50kb의 파일 크기가 감소. Wired.com은 62% 가량 감소.
- MSN.com: Filesize 64% 감소. 하루 940GB의 트래픽 감소 효과 얻음.
- 재개발 비용의 감소
- 구조/표현 분리에 따른 리뉴얼 및 재개발에 따른 비용 감소
여섯째, 사용성 및 재생산성 증대
- Table 기반 렌더링에 비해 페이지 접속 체감도 증가
- 단말기 독립적인 웹서비스 제공 가능 (PDA, 텍스트, 장애인, 다국어 사이트)
일곱째, 글로벌 비즈니스 구현
- Section 508을 통과하지 않는 경우 미국 연방 정부 조달 불가능
- 중요한 10%의 사용자 확보
- 1천만의 10%는 십만명이나 1억의 10%는 천만명이다.
그럼 웹호환성 준수를 위해서 우리는 어떻게 해야할까요
우선 공급자측면에서 보면 웹 표준 규격 준수하는 것이 필수입니다
- W3C의 일반 표준 준수 (HTML4.1, XHTML1.0, CSS1, DOM1)
- ECMAscript(자바스크립트)의 일반 표준 준수
- 웹디자이너/UI 개발자/웹개발자에 대한 표준 준수에 대한 재교육
- 표준 준수는 생산성에 대한 경쟁력임을 전략화
구조와 표현 분리 사용
- 구조화된 HTML을 사용하고 표현은 CSS로 대체
- 테이블 구조를 CSS Boxing 모델로 수정
- 다수의 스타일로 각종 접근성 문제 해결 (노약자, 장애인, 비PC단말)
최소한의 디버깅 및 QA
- 표준 준수 Validator로 QA (W3C에서 제공)
- Firefox 자바스크립트 디버거 이용
- 다수 브라우저 테스트를 거칠 것
호환성있는 플러그인도입(업계)
- ActiveX 대체 기술들을 사용한 플러그인 제작
- Java, NSplugin : 예전 기술이거나 XP 환경에 적합하지 않음
- AJAX: xmlhttp과 Javascript를 통한 인터랙티브 UI기술
- 일반적인 웹 기술을 통해서도 대부분 구현 가능
브라우저 확장 기능
- Mozilla : XUL/Javascript/CSS를 통한 확장 가능
- Microsoft: XAML(Longhorn)을 기반으로 하는 닷넷 어플리케이션
호환성준수실태관리(관리자)
- 정보시스템 구축사업 계획 및 검수시에 호환성준수 항목을 포함하여 확인
- 정기적인 웹호환성 실태를 관리하여 수준 유지가 필요
마지막으로
웹2.0, 전자정부2.0시대에 맞는 웹서비스의 제공을 위해서는 생산자, 공급자, 관리자 모두가 힘을 합쳐서 웹표준 준수를 통한 웹접근성 보장, 웹호환성 확보를 위해 노력해야 한다는 것을 말씀드립니다.
오늘 제가 이야기할 내용은 웹이란 어떤것이가, 그리고 웹표준, 웹호환성은 무엇을 의미하는가 정도를 이야기 드리고, 국내 웹환경의 현실을 짚어보면서 어떻게 하는것이 좋을까 같이 고민해보도록 하겠습니다.
웹호환성에 대한 이야기를 하기위해서 우선 웹이 어떻게, 왜 시작되었는지를 알 필요가 있습니다.
오늘날 웹이라부르는 월드와이드웹은 영국의물리학자 팀버너스리에 의해서 탄생되게 됩니다. 팀버너스리는 CERN연구소의 수천명 연구자들이 이기종 OS와 개발 환경에서 정보를 공유할 수 있도록 어떤 컴퓨터에서도 접근할 수 있는 리소스를 쉽게 제공하려는 목적으로 웹을 만들게 되었습니다.
그러므로 웹이 탄생한 이유는 "정보의연결을통한 지식의 공유와 학습"이라고 할 수 있습니다.
팀버너스리는 1980년 후반 다양한 환경에서 정보공유를 계속 고민하게 되었고, 1990년 최초의 인터넷주소 info.cern.ch 를 탄생시킵니다. 바로 제 1호 인터넷주소가 생긴 1990년을 인터넷의 시작이라고 볼수 있습니다
그후 1994년 월드와이드웹콘소시업 줄여서 W3C라고 부르는 웹을 위한 단체가 결성되어
현재는 510여개의 IT기업이 참여하여 세계 웹표준을 주도하고 있습니다.
웹표준 주도단체 W3C에서 이야기하는 웹의 주요이념은 7가지가 있는데
그중 웹표준, 웹호환성과 관련이 있는 3가지 이념에 대해서 알아보도록 하겠습니다.
첫째 Universal Access가 있습니다.
보편적접근이란 언어나 지역 그리고 계층, SW나 단말기, 운영체제등에 상관없이 웹을 사용할수 있어야 한다는 의미입니다
두번째 Semantic Web이 있습니다.
요즘 웹2.0을 기반으로한 기술을 논의하면서 자주 나타나는 용어인데 사람 뿐 아니라 컴퓨터도 이해 가능한 의미론적 웹을 말합니다.
세번째는 Interoperability 가 있습니다. 정보처리 상호운용성을 의미하죠.
상호운용성이란 어떠한 소프트웨어,하드웨어를 이용해서 웹을 보더라도 웹서비스에 이상이 없어야 한다는것을 의미합니다.
이전장에서 웹이 어떻게 생겨난 것인지를 살펴보았습니다.
이번에는 웹이 어떤것인지를 살펴보고, 웹표준이란 무엇을 말하는지 알아보도록 하겠습니다.
일반적으로 웹의 구성요소를 나누어보면 텍스트, 이미지, 동영상, 사운드, 기타플러그인 프로그램(인증서,파일업로드등)으로 구성되어 있습니다.
이런 콘텐츠를 표현하기 위한 웹의 기술은 HTML, CSS, ECMAScript, XML, DOM, AciveX 등이 벡엔드에서 사용되고 있습니다.
여러가지 다양한 기술요소들이 있는데 이것들은 크게 3가지 그룹으로 나누어집니다.
내용을 구성하는 기술(HTML,XHTML,XML)
표현을 담당하는 기술(CSS,XSL)
행동을 담당하는 기술(DOM & ECMAScript) 로 나누어지는데 가장 핵심적인 기술요소 3가지만 알아보도록 하겠습니다.
첫째 HTML
HTML(Hypertext Markup Languege) HTML은 웹페이지의 내용을 구성하는 대표적인 표준 언어를 말한다
Hypertext란 웹페이지에서 링크를 포함시켜 그 링크를 클릭했을 때 다른 웹페이지 또는 문서로 이동할 수 있게 해주는 기능을 의미하며 예전의 문서를 읽는 선형읽기 구조에서 비선형읽기가 가능하게 해주는 핵심적인 요소입니다. 그외 내용을 표현하는 요소들로는 데이터구조를 유연하게 표현할수있는 XML, XML과HTML의 중간단계 XHTML이 있습니다
두번째 CSS
CSS(Cascading Stylesheet)는 웹문서의 표현을 담당하는 언어입니다.
CSS는 주로 HTML을 구조적으로 출력하고, 외관을 장식하기 위한 역할을 하며, XML 문서를 간단한 방법으로 출력하는 방법으로는 XSL을 사용합니다.
세번째 DOM & ECMAScript
DOM
DOM은 문서의구조를 트리형태로 접근가능한 인터페이스 즉 각종 프로그램이나 스크립트를 통해 HTML을 동적으로 변화기키고자 할때 제공해주는 프로그램을 위한 문서구조입니다
ECMAScript
ECMAScript는 ECMA International의 ECMA-262 기술 명세에 정의된 표준화된 스크립트 프로그래밍 언어.
즉 ECMAscript 는 공통 javascript를 의미합니다.
웹 브라우저시장은 90년대 초반에 두개의 대표적인 회사의 제품이 대표적이었습니다
마이크로소프트사의 인터넷 익스플로러와 넷스케이프사의 넷스케이프 네비게이터(또는 커뮤니케이터)가 그것입니다. 두 회사는 각각 브라우저를 업데이트를 할 때마다 새로운 HTML에 대한 동적인 기능구현을 위해 각각의 javascript를 추가시켜 왔고 그로인해 넷스케이프사와 마이크로소프트사는 서로 다른 스크립트를 각자의 브라우저에서 사용하게 되었습니다 (넷스케이프는 Javascript, 마이크로소프트의 Jscript)
그러던 중 넷스케이프에서 ECMA International 에 웹문서 스크립트표준에 대한 명세를 제출하여 서로 규정을 맺고 javascript 1.5를 기준으로 표준 script 즉 ECMAScript 3rd 가 나왔으며, 이를 스크립트 표준 언어라고 이야기합니다.
지금도 각각 개발하긴 하지만 ECMAscript의 기본에 충실히 개발하고 있기 때문에 점차로 호환적인 측면에서 나아지고 있는 현실입니다. 물론 다른 웹브라우저(오페라나 모질라 등등) 에서도 이 표준을 따릅니다.
웹표준이란 지금까지 이야기한 W3C에서 제시하는 웹의 내용, 표현, 행동에 관련된 각종 기술표준을 의미하는것입니다.
지금까지 웹이란 어떤것인가, 그리고 웹표준은 무엇을 의미하는가에 대해서 알아보았습니다.
이번장부터는 국내웹환경의 문제점들을 짚어보고, 어떻게 해야할지에 대해서 고민해보도록 하겠습니다
국내웹환경의 첫번째문제는 브라우저호환성의 무시입니다.
대부분의 사람들에게 인터넷이 무엇이냐고 묻는다면 데스크탑바탕화면에 설치된 푸른색e아이콘 즉 마이크로소프트의 인터넷 익스플로러라고 이야기 할 것입니다.
그러나. 인터넷을 사용할수 있는 웹브라우저는 보시는 것처럼 인터넷익스플로러 이외에도 파이어폭스, 오페라, 사파리, 그외에도 퀑쿼러 링스등 다양하게 존재하고 있습니다.
실제 전세계 브라우저 사용량을 보면 90프로는 IE를 그외 10프로는 파이어폭스를 사용하고 있으며 그외의 브라우저들도 소수 사용되고 있습니다.
국내 웹환경의 두 번째 문제는 단말기접근성을 제공하지 않는다는 점입니다.
화면은 일반적으로 흔히 볼수 있는 웹사이트의 구조입니다.
텍스트버전,모바일버전,시각장애인용등의 웹사이트를 각각 제공하고 있는데 , 이것은 웹사이트를 제작할때 웹표준을 준수하지 않았기 때문에 중복개발비용이 발생되고있는 사례입니다 웹표준을 준수한다면 별도로 각각의 버전을 제작하는것이 아니라 CSS, 즉 내용과는 별개로 표현만 변경하는 방식을 적용하여 개발비용을 절감할수 있습니다.
CSS Zen Garden에서 보여주는 웹사이트들입니다.
이 사이트들은 모두 동일한 내용에 CSS만 변경한 같은 사이트입니다.
금방 이야기했던 표현과 구조의 분리를 통한 웹표준 개발을 하였을 때 한 개의 내용으로 표현할 수 있는 다양한 웹사이트의 사례입니다.
국내 웹환경의 세 번째 문제는 모든 레이아웃을 테이블로 처리하는 것입니다.
실제 HTML소스를 열어서 내용을 확인하면 콘텐츠간의 간격이나 레이아웃의 배치를 위해서, 테이블안의 테이블 또 그안의 테이블. 이런 형식으로 중첩된 테이블을 사용하고 있습니다.
구조와 표현을 분리하는 웹표준 개발방식을 적용한다면 테이블 레이아웃은 CSS레이아웃으로 대체되고 웹페이지는 용량이 줄어들게 되므로 트래픽 감소효과를 가져오게 됩니다.
실제 마이크로소프트는 2004년 테이블을 모두 빼고 웹표준 개발방식을 적용하여 CSS레이아웃을 사용하여 웹사이트 전면 개편 하였습니다. 그 결과 하루에 924GB의 트래픽을 감소시키게 되었고 속도향상을 가져왔습니다.
국내 웹환경의 4번째 문제는 비표준 스크립트의 남용입니다.
한국소프트웨어진흥원에서 실시한 2006년 1007개 국내 공공 및 민간 홈페이지에 대한 웹호환성 조사결과에 따르면 국내 스크립트 표준 준수율은 16.8% 입니다.
대부분의 웹사이트가 웹표준 비준수로인한 오류를 다수포함하고 있으며, 특히 스크립트표준 비준수로 인한 브라우저간 상호운용성이 심각한 수준입니다
마지막으로 정보접근성에 대한 배려가 없는점을 들수있습니다.
- 소수 운영체제 및 브라우저 사용자(리눅스의 파이어폭스, 매킨토시의 사파리등)
- 비 PC단말기 사용자 (PDA, Phone)
- 인터넷 환경이 열악한 제3세계 재한국인
- 정보 소외 계층(노인 및 장애인, 농민 및 빈민)
이 부분은 오늘 많이 들으신 내용이죠.
지금까지 국내 웹환경의 현실에 대해서 전반적으로 살펴보았습니다.
여기에서 한가지 의문사항이 있습니다. 웹접근성, 웹표준, 웹호환성은 어떤차이가 있는걸까요?
웹표준이란 앞에서 이야기드린것처럼 W3C에서 제시하는 웹의 내용,표현,행동에 관련된 각종 기술표준을 이야기합니다.
웹접근성과 웹호환성은 화면에 보시는것처럼 웹표준을 공통으로 포함하고 있습니다.
이 이야기는 웹표준을 준수하는것 만으로는 웹접근성이나 웹호환성이 보장되지 않는 다는 것을 의미합니다.
그리고 웹호환성을 준수하더라도 웹접근성은 보장되지 않는다는 이야기이기도 합니다.
웹접근성이란 보편적접근성 확보를 우선시하고, 웹호환성은 OS,SW에 독립적인 상호운용성 확보를 우선시합니다.
처음부분에서 설명드린것 처럼 웹의 이념은 유니버셜액세스(보편적 접근성)도 필요하고, 시맨틱웹(컴퓨터가 이해가능한웹), 인터오퍼러빌리티(상호운용성)까지 모두 포함하고 있습니다.
그러므로, 웹2.0시대에 맞는 웹서비스를 위해서는 웹표준을 준수하면서 웹접근성과 웹호환성을 다같이 고민해야 하는것입니다.
이 내용은 한국소프트웨어진흥원에서 2006년 실시한 웹호환성 준수검사의 평가항목입니다.
평가항목은 앞에서 이야기드린것처럼 웹표준준수여부에 대한 3가지항목 HTML , CSS, ECMAScript 준수여부와 함께 인터넷익스플로러, 파이어폭스, 사파리를 이용한 브라우저간 상호운용성 9개항목으로 웹표준과 상호운용성을 포함하여 구성되어 있습니다.
보시는 화면은 국내 웹사이트 호환성을 조사한 결과입니다.
전체 호환성 준수율은 66.5점, 공공부문이 민간부문보다는 조금 높은 수준이었고, 민간부문중 금융부문은 ActiveX의 과다한 사용으로인해 매우낮은 수준으로 조사되었습니다.
도대체 그럼 왜 웹호환성이 이렇게 나빠진것일까 요.
외부적인 요인으로
첫째, 96~99년간 소위 브라우저 전쟁기간 동안 IE vs. Netscape의 비표준을 기반한 경쟁 후 IE 전용 기술만 잔재로 남게 되었기 때문입니다.
다른 브라우저를 고려할 필요가 없는 현실이었다는 이야기입니다
둘째, 표준 기술에 대한 웹디자이너/UI 개발자 등 웹 생산 종사자 재교육 및 자기 개발 부재입니다.
다른 브라우저를 고려할 필요가 없으니 당연히, 가르칠필요도 배울필요도 없는 현실이 되었던 것입니다.
내부적인 요인으로는
첫째, 국내 인터넷 환경의 급격한 성장을 꼽을수 있습니다.
급격한 인터넷 산업화로 인해서 엔터테인먼트 인터넷으로 진화하게 되었고, 세계에서 첫째가는 IT인프라를 보유하게 되었습니다. 그러다보니 더많은 기능을 요구하게 되었고, 웹에 대한 기본 인식 및 개발 방식에 대한 이해가 없는 상황에서 공공재로서의 웹이라는 인식없이 각종 비표준 플러그인기술을 발전시키게 되었습니다.
그 결과 엄청난 비표준 웹페이지가 양산되었고 현재 국내의 웹페이지를 보면 테이블 레이아웃을 사용하는것이 거의 100%, 링크 대신 자바스크립트 액션을 사용하는것이 80% 정도로 판단하고 있습니다
비 표준 주요 실례를 보면
- MS 기반 태그 : <marquee>, <object>, <iframe>
- W3C DOM vs. MS DOM
- document.all -> document.getElementByID
- MS 기반 Java Script/VBScript vs. ECMA Script (스크립트 표준)등을 들 수 있으며
뿐만 아니라 Windows Media Player 호환 포맷만 사용함으로 인해서 다른 운영체제 사용자는 해당 콘텐츠를 볼 수 없는 상황이므로 Cross Platform 미디어 포맷에 대한 고려가 필요합니다.
호환성이 안지켜지는 또다른문제는 ActiveX입니다.
ActiveX는 특정 OS 및 브라우저에 종속적인 기술로 국내 ActiveX 사용량은 세계 최고입니다.
-코드사인 인증서 배포율 1위 (Verisign:Thawte=320:720 per year)
-1400여개가 넘는 배포 사이트 존재 (거의 대부분 기업 웹사이트)
-외국에서는 주요 플러그인 외에는 스파이웨어 취급을 당하고 있음.
ActiveX 문제가 발생한 주요 원인
- 일찍 수립된 공인 인증 체계: IE 브라우저 독점화에 기술 종속
- 빠른 브로드 밴드 진입 : 플러그인 다운로드가 쉬움
- 어플리케이션 웹: 정보 제공 수단이 아닌 기능적 웹으로 진화
- 오락적인 인터넷 사용 행태 : 온라인 게임, 채팅, 사용자 제어 등
ActiveX 주요 사용처
-공인 인증 사용: 인터넷 뱅킹, 증권 거래, 카드 결제, 보험, 전자 정부 등
-엔터테인먼트: 온라인 게임, 로그인, 채팅 및 메신저, 파일 첨부
-스파이 웨어: 광고 및 해킹 프로그램
그럼 도대체 왜 최근에 웹호환성이 제기되는 것일까요
이슈의 첫번째 원인은 공개SW 파이어폭스가 나타나서 새로운 웹브라우저가 시장을 점유하기 시작했기 때문입니다
Mozilla Firefox는 웹 표준을 기반으로 하는 경량의 공개 SW 웹브라우저로서 출시 100일 만에 2천8백만 다운로드 기록하였고,100개 언어로 프로젝트가 진행되며, 1만명의 테스터를 가진 SW입니다
파이어폭스는 웹 표준을 가장 잘 표현하는 브라우저이며, 탭브라우징 및 팝업 차단, 라이브 북마크 및 RSS 구독 기능 그 외 통합 검색 및 테마 및 웹 개발자를 위한 확장 기능등을 제공하는 우수한 브라우저입니다.
두번째는 윈도우 비스타 출시에 따른 ActiveX 배포방식변경입니다.
액티브X를 활용한 응용 프로그램과 윈도 비스타의 충돌문제로 전자정부, 인터넷뱅킹 등 대국민 서비스에 차질을 빚은 이후 행정자치부, 정보통신부 등 정부기관들이 액티브X 사용 배제, 모든 브라우저 지원 등 표준 준수 움직임을 본격화하고 하고 있으며, 행자부에서는 액티브X 사태 이후 신규 발주사업의 제안요청서에 특정 업체 제품(기술)만 지원하지 않도록 하고 웹 표준을 준수해 다양한 운영체제(OS)와 한 개 이상의 브라우저에서 작동할 수 있게 구현할 것을 지시하고 있습니다.
폭발적인 파이어폭스 점유율. 2003년 4%부터 꾸준히 증가하여 2007년 현재 전세계 11.69% 사용 중
그럼 웹표준을 지키면 무엇이 좋아지는 것일까요.
첫째, 고객의 양적 질적 증가
- 웹표준 준수는 친환경 경영과 같은 것. 고객의 기업 인지도 향상.
- 브라우저 호환을 통해서도 훌륭한 서비스 구현 가능
- 야후닷컴, 구글 Gmail, Maps
- 소수 사용자는 오피니언 리더다.
- 리눅스 및 맥킨토시 사용자는 인터넷 오피니언 리더이다.
둘째, 개발 속도 및 효율성 증가
- 브라우저에 따른 고려가 없어지므로 개발이 빠름.
- 표준 구현이 능숙해 지는 경우 개발 속도 향상
셋째, 레이아웃 변경이 용이
- 일반, 다국어 웹사이트, 텍스트, 장애인, 모바일 다양한 레이아웃 한꺼번에 제공 가능
- 구조와 표현의 분리에 따른 개발자-디자이너 협업 체계 구축.
- 개발자와 디자이너의 이중 작업 감소 및 영역 보장
넷째, 품질관리제공
- W3C Validation 및 자바스크립트 디버거를 통한 QA 보장
다섯째, 유지 비용의 감소
- 웹페이지 서버 트래픽 및 장비 비용 최소화
- 야후!닷컴: 같은 UI로도 첫화면 파일 크기를 1/3로 줄임.
- ESPN.com: 50kb의 파일 크기가 감소. Wired.com은 62% 가량 감소.
- MSN.com: Filesize 64% 감소. 하루 940GB의 트래픽 감소 효과 얻음.
- 재개발 비용의 감소
- 구조/표현 분리에 따른 리뉴얼 및 재개발에 따른 비용 감소
여섯째, 사용성 및 재생산성 증대
- Table 기반 렌더링에 비해 페이지 접속 체감도 증가
- 단말기 독립적인 웹서비스 제공 가능 (PDA, 텍스트, 장애인, 다국어 사이트)
일곱째, 글로벌 비즈니스 구현
- Section 508을 통과하지 않는 경우 미국 연방 정부 조달 불가능
- 중요한 10%의 사용자 확보
- 1천만의 10%는 십만명이나 1억의 10%는 천만명이다.
그럼 웹호환성 준수를 위해서 우리는 어떻게 해야할까요
우선 공급자측면에서 보면 웹 표준 규격 준수하는 것이 필수입니다
- W3C의 일반 표준 준수 (HTML4.1, XHTML1.0, CSS1, DOM1)
- ECMAscript(자바스크립트)의 일반 표준 준수
- 웹디자이너/UI 개발자/웹개발자에 대한 표준 준수에 대한 재교육
- 표준 준수는 생산성에 대한 경쟁력임을 전략화
구조와 표현 분리 사용
- 구조화된 HTML을 사용하고 표현은 CSS로 대체
- 테이블 구조를 CSS Boxing 모델로 수정
- 다수의 스타일로 각종 접근성 문제 해결 (노약자, 장애인, 비PC단말)
최소한의 디버깅 및 QA
- 표준 준수 Validator로 QA (W3C에서 제공)
- Firefox 자바스크립트 디버거 이용
- 다수 브라우저 테스트를 거칠 것
호환성있는 플러그인도입(업계)
- ActiveX 대체 기술들을 사용한 플러그인 제작
- Java, NSplugin : 예전 기술이거나 XP 환경에 적합하지 않음
- AJAX: xmlhttp과 Javascript를 통한 인터랙티브 UI기술
- 일반적인 웹 기술을 통해서도 대부분 구현 가능
브라우저 확장 기능
- Mozilla : XUL/Javascript/CSS를 통한 확장 가능
- Microsoft: XAML(Longhorn)을 기반으로 하는 닷넷 어플리케이션
호환성준수실태관리(관리자)
- 정보시스템 구축사업 계획 및 검수시에 호환성준수 항목을 포함하여 확인
- 정기적인 웹호환성 실태를 관리하여 수준 유지가 필요
마지막으로
웹2.0, 전자정부2.0시대에 맞는 웹서비스의 제공을 위해서는 생산자, 공급자, 관리자 모두가 힘을 합쳐서 웹표준 준수를 통한 웹접근성 보장, 웹호환성 확보를 위해 노력해야 한다는 것을 말씀드립니다.
'개발도 하냐?' 카테고리의 다른 글
| Struts에서 Spring으로의 이주 가이드. (0) | 2007.07.26 |
|---|---|
| 사파리 윈도우용 출시 (0) | 2007.07.03 |
| EMAIL 에러메세지 (0) | 2007.04.19 |
| CreateObject("CDO.Message") (0) | 2007.04.17 |
| CDOSYS를 사용하여 ASP에서 메일발송 (0) | 2007.04.17 |
EMAIL 에러메세지
2007. 4. 19. 14:08
▶ SERVER REPLY: 501 Denied domain name
; 도메인주소를 잘못 입력 or 수신측에서 도메인을 수신거부한 경우
▶ 421 Server too busy.
; 수신측 서버의 응답지연. 수신서버의 트래픽등으로 메일을 수신 받지 못하는 상황에서 발송자에게 리턴 메일을 보냄.
▶ 421-Microsoft ESMTP MAIL Service, Version: 5.0.2195.5600 ready at Service not available, closing transmission channel
; MS사의 smtp 서버의 장애로 인해 메일을 수신받지 못하는 상황에서 리턴된 메시지.
▶ 421 4.3.2 Your IP(218.236.206.104) is filtered and this connection will be closed. You must register your IP to spammaster@interidea.co.kr By SpaceLee, the Lord of mail server.
; 우리쪽 (mail.interidea.co.kr) 서버로 메일을 발송시 필터링 조건에 위배되어 스패머로 인식되고 필터링 되어 발신자에게 리턴되는 메시지.
▶ 441 4.4.1 No answer from host
; 수신측 서버의 응답이 없어서 리턴된 메시지.
▶ 451 4.4.0 DNS resolving error
; 수신측 서버의 도메인을 못찾아 리턴된 메시지.
▶ 451 4.3.0 Other or undefined mail system status
; 수신측 메일 시스템의 프로토콜이 틀리거나 수신 smtp 서버가 아닐경우 리턴되는 메시지.
▶ 451 4.3.0 Temporary system failure. Please try again later.
; 수신 서버의 일시적인 장애로 인해 메일을 수신받지 못해 리턴된 메시지.
▶ 451 4.4.2 Bad connection (io timeout)
; 수신 서버의 응답이 없어서 응답시간이 초과 되어 리턴된 메시지.
▶ 451 Relay Server Not Ready.
; 수신측 서버에서 릴레이 기능이 안돼어 리턴된 메시지.
▶ 452 4.4.5 Insufficient disk space; try again later
; 수신서버의 디스크용량이 부족하여 메일을 수신받지 못해 리턴된 메시지.
▶ 452 4.4.5 ... Insufficient disk space; try again later
; 수신자(leo@buffgame.com)의 메일함 용량이 부족하여 메일을 수신받지 못해 리턴된 메시지
▶ 500 Syntax Error, Command Unrecognized EHLO mo02.hanafos.com
; 발송자의 메일 발송기(아웃룩, 유도라 등등)에서 메일발송시 수신측 메일 서버에서 SMTP 명령어를 인식하지 못해 리턴된 메시지.
▶ 500 5.5.1 Command unrecognized: "XXXX mo02.hanafos.com"
; 수신서버가 SMTP 명령어를 인식 하지 못함. (위와 동일).
▶ 501 5.1.8 Sender domain must exist(honorstech.com)
; 수신측 도메인(honorstech.com) 이 존재 하지 않아 리턴된 메시지.
▶ 502 Not implemented
; 수신측 서버가 smtp 명령어를 인식 하지 못해 리턴된 메시지.
▶ 505 Authentication required
; 수신측 서버가 릴레이 인증 등을 허용하지 않아 리턴된 메시지.
▶ 512 5.1.2 Bad destination system address
; 수신 서버의 장애나 네트웍 트래픽등으로 인헤 수신서버가 응답이 없을 때 리턴된 메시지.
▶ 550 5.1.1 Suspended user
; 수신자의 사용자의 계정이 중단 상태.
▶ 550 5.1.2 ... Unsupported mail destination
; 수신 서버가 응답이 지연되어 리턴된 메시지.
▶ 550 5.7.1 ... Access denied.(211.202.13.144)
; 수신자(gyunu@chollian.net)가 발신자의 메일주소를 수신 거부한 상태.
▶ 550 5.7.1 ... Relaying denied. IP name lookup failed 211.202.13.144]
; 수신 서버에서 발신자의 IP에 대해 릴레이 거부를 하여 메일을 보내지 못해 리턴된 메시지.
▶ 550 Requested action not taken: mailbox unavailable
; 수신자의 메일함을 찾지 못해 리턴된 메시지.
▶ 550 Mail is reject ( filtering reject )
; 수신 서버에서 발신자의 메일 주소나 IP를 필터링 하여 거부되어 리턴된 메시지.
▶ 550 5.1.1 ... User unknown
; 수신자 (hkaprk@jeill.co.kr)계정을 찾지 못해 리턴된 메시지.
▶ 550 5.7.1 Unable to relay for lyc410@hanafos.net
; 수신 서버에서 릴레이 거부를 하여 리턴된 메시지.
▶ 550 Invalid recipient lobster@fernand.com
; 수신자 계정을 찾지 못해 리턴된 메시지 .
▶ 550 RCPT ERROR. Mailbox doesn't exist
; 수신자 메일함이 존재 하지 않아서 리턴된 메시지.
▶ 553 5.3.0 ... spam
; 발송자의 계정이 수신서버 상에서 스패머로 등록이 되어 메일 수신 거부를 해서 리턴된 메시지
▶ 553 sorry, your envelope sender is in my badmailfrom list
; 발신자의 메일 주소가 수신서버상에서 블랙리스트에 올라 거부되어 리턴됨.
▶ 553 sorry, that domain isn't in my list of allowed rcpt hosts
; 발신자의 메일 도메인주소 자체가 수신 서버에서 차단되어 리턴된 메시지.
▶ 553 5.1.8 ... Domain of sender address uni@honorstech.com does not exist
; 발신자의 도메인에 대해 수신서버에서 체크 하여 없는 도메인일 경우 리턴시킨 메시지.
▶ 553 5.0.0 We do not accept mail from spammers - If you have questions,please email admin@www.narun.net.
; 발신자의 메일 계정이 스패머로 수신서버에서 등록이 되어 리턴된 메시지.
▶ 553 5.0.0 Your message may contain the Win32.Klez worm!!- If you have questions,please email postmaster@ecweb-1.blueweb.co.kr.
; 발신자의 메일에서 Win32.Klez 라는 웜바이러스가 발견되어 리턴된 메시지.
▶ 553 sorry, your envelope sender is enlisted as spammer.
; 발신자의 메일 주소가 수신서버상의 스패머 리스트에 등록 되어 리턴된 메시지.
▶ 553-This target address is not our MX service
; 수신자의 주소가 수신서버에서 서비스 안하는 도메인일 경우 리턴된 메시지.
▶ 554 5.3.2 Rejected by mailbox host. REPLY:(250 ... Sender ok)
; 수신자가 발송자의 메일 계정에 대해 수신 거부를 하여 리턴된 메시지 .
▶ 554 5.3.0 Mail have traversed Too many hops. Reject it.
; 발신자가 메일을 보낼 때 동보메일로 수신자의 메일 계정을 수신서버의 제한량 이상 넣어 보내어 리턴된 메시지.
▶ 554 5.3.2 Rejected by mailbox host. REPLY:(550 5.1.1 unknown or illegal alias: kgng_h_w@samsung.com)
; 수신자가 발송자의 메일 계정에 대해 수신거부를 설정하여 리턴된 메시지.
▶ 554 1048035239.13309.hanmir accept failed. [code=-1]
; hanmir 서버에서 응답이 안돼어 리턴된 메시지.
▶ 554 delivery error: dd Sorry, your message to bk6218@yahoo.co.kr cannot be delivered. This account is over quota. - mta111.mail.yahoo.co.kr
; 수신자의 메일함 용량 초과로 인해 리턴된 메시지.
▶ 554 5.1.0 Sender Denied
; 발신자의 계정을 수신서버에서 수신 거부함.
▶ 554 : Recipient address rejected: Access denied
; 수신자가 발신자의 계정에 대해 수신 거부를 설정함.
* 스패머정보조회
http://www.dnsstuff.com/tools/ip4r.ch?ip=211.250.xx.xx
; 도메인주소를 잘못 입력 or 수신측에서 도메인을 수신거부한 경우
▶ 421 Server too busy.
; 수신측 서버의 응답지연. 수신서버의 트래픽등으로 메일을 수신 받지 못하는 상황에서 발송자에게 리턴 메일을 보냄.
▶ 421-Microsoft ESMTP MAIL Service, Version: 5.0.2195.5600 ready at Service not available, closing transmission channel
; MS사의 smtp 서버의 장애로 인해 메일을 수신받지 못하는 상황에서 리턴된 메시지.
▶ 421 4.3.2 Your IP(218.236.206.104) is filtered and this connection will be closed. You must register your IP to spammaster@interidea.co.kr By SpaceLee, the Lord of mail server.
; 우리쪽 (mail.interidea.co.kr) 서버로 메일을 발송시 필터링 조건에 위배되어 스패머로 인식되고 필터링 되어 발신자에게 리턴되는 메시지.
▶ 441 4.4.1 No answer from host
; 수신측 서버의 응답이 없어서 리턴된 메시지.
▶ 451 4.4.0 DNS resolving error
; 수신측 서버의 도메인을 못찾아 리턴된 메시지.
▶ 451 4.3.0 Other or undefined mail system status
; 수신측 메일 시스템의 프로토콜이 틀리거나 수신 smtp 서버가 아닐경우 리턴되는 메시지.
▶ 451 4.3.0 Temporary system failure. Please try again later.
; 수신 서버의 일시적인 장애로 인해 메일을 수신받지 못해 리턴된 메시지.
▶ 451 4.4.2 Bad connection (io timeout)
; 수신 서버의 응답이 없어서 응답시간이 초과 되어 리턴된 메시지.
▶ 451 Relay Server Not Ready.
; 수신측 서버에서 릴레이 기능이 안돼어 리턴된 메시지.
▶ 452 4.4.5 Insufficient disk space; try again later
; 수신서버의 디스크용량이 부족하여 메일을 수신받지 못해 리턴된 메시지.
▶ 452 4.4.5 ... Insufficient disk space; try again later
; 수신자(leo@buffgame.com)의 메일함 용량이 부족하여 메일을 수신받지 못해 리턴된 메시지
▶ 500 Syntax Error, Command Unrecognized EHLO mo02.hanafos.com
; 발송자의 메일 발송기(아웃룩, 유도라 등등)에서 메일발송시 수신측 메일 서버에서 SMTP 명령어를 인식하지 못해 리턴된 메시지.
▶ 500 5.5.1 Command unrecognized: "XXXX mo02.hanafos.com"
; 수신서버가 SMTP 명령어를 인식 하지 못함. (위와 동일).
▶ 501 5.1.8 Sender domain must exist(honorstech.com)
; 수신측 도메인(honorstech.com) 이 존재 하지 않아 리턴된 메시지.
▶ 502 Not implemented
; 수신측 서버가 smtp 명령어를 인식 하지 못해 리턴된 메시지.
▶ 505 Authentication required
; 수신측 서버가 릴레이 인증 등을 허용하지 않아 리턴된 메시지.
▶ 512 5.1.2 Bad destination system address
; 수신 서버의 장애나 네트웍 트래픽등으로 인헤 수신서버가 응답이 없을 때 리턴된 메시지.
▶ 550 5.1.1 Suspended user
; 수신자의 사용자의 계정이 중단 상태.
▶ 550 5.1.2 ... Unsupported mail destination
; 수신 서버가 응답이 지연되어 리턴된 메시지.
▶ 550 5.7.1 ... Access denied.(211.202.13.144)
; 수신자(gyunu@chollian.net)가 발신자의 메일주소를 수신 거부한 상태.
▶ 550 5.7.1 ... Relaying denied. IP name lookup failed 211.202.13.144]
; 수신 서버에서 발신자의 IP에 대해 릴레이 거부를 하여 메일을 보내지 못해 리턴된 메시지.
▶ 550 Requested action not taken: mailbox unavailable
; 수신자의 메일함을 찾지 못해 리턴된 메시지.
▶ 550 Mail is reject ( filtering reject )
; 수신 서버에서 발신자의 메일 주소나 IP를 필터링 하여 거부되어 리턴된 메시지.
▶ 550 5.1.1 ... User unknown
; 수신자 (hkaprk@jeill.co.kr)계정을 찾지 못해 리턴된 메시지.
▶ 550 5.7.1 Unable to relay for lyc410@hanafos.net
; 수신 서버에서 릴레이 거부를 하여 리턴된 메시지.
▶ 550 Invalid recipient lobster@fernand.com
; 수신자 계정을 찾지 못해 리턴된 메시지 .
▶ 550 RCPT ERROR. Mailbox doesn't exist
; 수신자 메일함이 존재 하지 않아서 리턴된 메시지.
▶ 553 5.3.0 ... spam
; 발송자의 계정이 수신서버 상에서 스패머로 등록이 되어 메일 수신 거부를 해서 리턴된 메시지
▶ 553 sorry, your envelope sender is in my badmailfrom list
; 발신자의 메일 주소가 수신서버상에서 블랙리스트에 올라 거부되어 리턴됨.
▶ 553 sorry, that domain isn't in my list of allowed rcpt hosts
; 발신자의 메일 도메인주소 자체가 수신 서버에서 차단되어 리턴된 메시지.
▶ 553 5.1.8 ... Domain of sender address uni@honorstech.com does not exist
; 발신자의 도메인에 대해 수신서버에서 체크 하여 없는 도메인일 경우 리턴시킨 메시지.
▶ 553 5.0.0 We do not accept mail from spammers - If you have questions,please email admin@www.narun.net.
; 발신자의 메일 계정이 스패머로 수신서버에서 등록이 되어 리턴된 메시지.
▶ 553 5.0.0 Your message may contain the Win32.Klez worm!!- If you have questions,please email postmaster@ecweb-1.blueweb.co.kr.
; 발신자의 메일에서 Win32.Klez 라는 웜바이러스가 발견되어 리턴된 메시지.
▶ 553 sorry, your envelope sender is enlisted as spammer.
; 발신자의 메일 주소가 수신서버상의 스패머 리스트에 등록 되어 리턴된 메시지.
▶ 553-This target address is not our MX service
; 수신자의 주소가 수신서버에서 서비스 안하는 도메인일 경우 리턴된 메시지.
▶ 554 5.3.2 Rejected by mailbox host. REPLY:(250 ... Sender ok)
; 수신자가 발송자의 메일 계정에 대해 수신 거부를 하여 리턴된 메시지 .
▶ 554 5.3.0 Mail have traversed Too many hops. Reject it.
; 발신자가 메일을 보낼 때 동보메일로 수신자의 메일 계정을 수신서버의 제한량 이상 넣어 보내어 리턴된 메시지.
▶ 554 5.3.2 Rejected by mailbox host. REPLY:(550 5.1.1 unknown or illegal alias: kgng_h_w@samsung.com)
; 수신자가 발송자의 메일 계정에 대해 수신거부를 설정하여 리턴된 메시지.
▶ 554 1048035239.13309.hanmir accept failed. [code=-1]
; hanmir 서버에서 응답이 안돼어 리턴된 메시지.
▶ 554 delivery error: dd Sorry, your message to bk6218@yahoo.co.kr cannot be delivered. This account is over quota. - mta111.mail.yahoo.co.kr
; 수신자의 메일함 용량 초과로 인해 리턴된 메시지.
▶ 554 5.1.0 Sender Denied
; 발신자의 계정을 수신서버에서 수신 거부함.
▶ 554 : Recipient address rejected: Access denied
; 수신자가 발신자의 계정에 대해 수신 거부를 설정함.
* 스패머정보조회
http://www.dnsstuff.com/tools/ip4r.ch?ip=211.250.xx.xx
'개발도 하냐?' 카테고리의 다른 글
| 사파리 윈도우용 출시 (0) | 2007.07.03 |
|---|---|
| 미래를위한선택-웹호환성 (0) | 2007.06.18 |
| CreateObject("CDO.Message") (0) | 2007.04.17 |
| CDOSYS를 사용하여 ASP에서 메일발송 (0) | 2007.04.17 |
| 웹 호환성 평가항목 (0) | 2007.02.07 |
CreateObject("CDO.Message")
2007. 4. 17. 23:40
2003 서버에서 asp를 사용하여 이메일을 보낼때는
CreateObject("CDO.Message") 를 사용해야 한다고 하네요,,
정리한거 올립니다...^^
CDOSYS 예제
---- 메일보낼때의 가장 간단한 예..
Set m =CreateObject("CDO.Message")
m.From = "user1@company.com"
m.To ="user2@company.com"
m.Subject = "test 1"
m.TextBody = "hello there"
m.send
---- html의 내용을 보낼때..
sHTML = "<html><body><fontcolor=""#FF0000"">" & _ "hello,Red</font></body></html>"
Set m = CreateObject("CDO.Message")
m.From = "user1@company.com"
m.To = "user2@company.com"
m.Subject = "test 1"
m.HtmlBody = sHTML --> 위의 예제는 TextBody인데,, HtmlBody로 바뀐거 보이시죠?
m.send
--- MIME 형식의 첨부파일이 포함될 때입니다..
Set m= CreateObject("CDO.Message")
m.From = "user1@company.com"
m.To ="user2@company.com"
m.Subject = "test.doc"
m.TextBody = "Here is the documentyou requested."
m.AddAttachment "file://d:\ptsp\test\test.doc"
m.send
-- uuencode 형식의 첨부파일이 포함될 때입니다...
Set m =CreateObject("CDO.Message")
m.MimeFormatted = false
m.From ="user1@company.com"
m.To = "user2@company.com"
m.Subject = "test.doc"
m.TextBody = "Here is the document you requested."
m.AddAttachment "file://d:\ptsp\test\test.doc"
m.send
-- 유니코드 메시지 텍스트 보내기 입니다..
set m =CreateObject("CDO.Message")
m.From = "User1 <user1@company.com>"
m.To ="Joe € <joe.euro@company.com>"
m.Subject = "Unicode content"
set b = m.bodypart
b.charset = "unicode-1-1-utf-7"
m.textbody = "That will be €5,please."
m.send
아직도 배울게 넘 많은거 같네요...^^
출처 :
HOWTO: NTS용 Collaboration Data Objects 응용프로그램을
Windows 2000용 Microsoft Collaboration Data Objects로 마이그레이션
의 내용을 정리한것임.
'개발도 하냐?' 카테고리의 다른 글
| 사파리 윈도우용 출시 (0) | 2007.07.03 |
|---|---|
| 미래를위한선택-웹호환성 (0) | 2007.06.18 |
| EMAIL 에러메세지 (0) | 2007.04.19 |
| CDOSYS를 사용하여 ASP에서 메일발송 (0) | 2007.04.17 |
| 웹 호환성 평가항목 (0) | 2007.02.07 |
CDOSYS를 사용하여 ASP에서 메일발송
2007. 4. 17. 22:19
CDOSYS를 사용하여 ASP에서 메일발송
--------------------------------------------------------------------------------
CDOSYS는 ASP의 컴포넌트로 내장되어 있으며 이 컴포넌트는 ASP에서 메일을 발송할 때 사용합니다.
--------------------------------------------------------------------------------
CDO (Collaboration Data Objects)는 마이크로소프트의 메시징 애플리케이션 생성을 위하여 설계된 기술입니다.
CDOSYS는 ASP의 컴포넌트로 내장되어 있으며 ASP에서 메일 발송시 사용하는 예제를 아래에 간단히 설명하였습니다.
CDONTs는?
마이크로소프트에서는 Windows 2000, XP, 2003에서 CDONTs의 사용을 더이상 지원하지 않습니다.
CDONTs를 ASP에서 사용하려면 새로운 CDO 기술을 사용하기 위해 코드를 갱신하여야 합니다.
CDOSYS를 사용한 예제
테스트 메일 발송:
<%
Set myMail=CreateObject("CDO.Message")
myMail.Subject="Sending email with CDO"
myMail.From="mymail@mydomain.com"
myMail.To="someone@somedomain.com"
myMail.TextBody="This is a message."
myMail.Send
set myMail=nothing
%>
CC와 BCC를 사용한 텍스트 메일 발송:
<%
Set myMail=CreateObject("CDO.Message")
myMail.Subject="Sending email with CDO"
myMail.From="mymail@mydomain.com"
myMail.To="someone@somedomain.com"
myMail.Bcc="someoneelse@somedomain.com"
myMail.Cc="someoneelse2@somedomain.com"
myMail.TextBody="This is a message."
myMail.Send
set myMail=nothing
%>
HTML 메일 발송 :
<%
Set myMail=CreateObject("CDO.Message")
myMail.Subject="Sending email with CDO"
myMail.From="mymail@mydomain.com"
myMail.To="someone@somedomain.com"
myMail.HTMLBody = "<h1>This is a message.</h1>"
myMail.Send
set myMail=nothing
%>
asp 웹페이지에서 HTML 메일을 발송하는 예제:
<%
Set myMail=CreateObject("CDO.Message")
myMail.Subject="Sending email with CDO"
myMail.From="mymail@mydomain.com"
myMail.To="someone@somedomain.com"
myMail.CreateMHTMLBody "http://www.w3schools.com/asp/"
myMail.Send
set myMail=nothing
%>
컴퓨터 상의 파일을 웹페이지에서 HTML 메일로 발송하는 방법:
<%
Set myMail=CreateObject("CDO.Message")
myMail.Subject="Sending email with CDO"
myMail.From="mymail@mydomain.com"
myMail.To="someone@somedomain.com"
myMail.CreateMHTMLBody "file://c:/mydocuments/test.htm"
myMail.Send
set myMail=nothing
%>
첨부파일을 텍스트 메일로 발송하는 방법:
<%
Set myMail=CreateObject("CDO.Message")
myMail.Subject="Sending email with CDO"
myMail.From="mymail@mydomain.com"
myMail.To="someone@somedomain.com"
myMail.TextBody="This is a message."
myMail.AddAttachment "c:\mydocuments\test.txt"
myMail.Send
set myMail=nothing
%>
원격지 메일 서버를 사용하여 텍스트 메일을 발송하는 방법:
<%
Set myMail=CreateObject("CDO.Message")
myMail.Subject="Sending email with CDO"
myMail.From="mymail@mydomain.com"
myMail.To="someone@somedomain.com"
myMail.TextBody="This is a message."
myMail.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/sendusing")=2
'Name or IP of remote SMTP server
myMail.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/smtpserver") _
="smtp.server.com"
'Server port
myMail.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/smtpserverport") _
=25
myMail.Configuration.Fields.Update
myMail.Send
set myMail=nothing
%>
--------------------------------------------------------------------------------
CDOSYS는 ASP의 컴포넌트로 내장되어 있으며 이 컴포넌트는 ASP에서 메일을 발송할 때 사용합니다.
--------------------------------------------------------------------------------
CDO (Collaboration Data Objects)는 마이크로소프트의 메시징 애플리케이션 생성을 위하여 설계된 기술입니다.
CDOSYS는 ASP의 컴포넌트로 내장되어 있으며 ASP에서 메일 발송시 사용하는 예제를 아래에 간단히 설명하였습니다.
CDONTs는?
마이크로소프트에서는 Windows 2000, XP, 2003에서 CDONTs의 사용을 더이상 지원하지 않습니다.
CDONTs를 ASP에서 사용하려면 새로운 CDO 기술을 사용하기 위해 코드를 갱신하여야 합니다.
CDOSYS를 사용한 예제
테스트 메일 발송:
<%
Set myMail=CreateObject("CDO.Message")
myMail.Subject="Sending email with CDO"
myMail.From="mymail@mydomain.com"
myMail.To="someone@somedomain.com"
myMail.TextBody="This is a message."
myMail.Send
set myMail=nothing
%>
CC와 BCC를 사용한 텍스트 메일 발송:
<%
Set myMail=CreateObject("CDO.Message")
myMail.Subject="Sending email with CDO"
myMail.From="mymail@mydomain.com"
myMail.To="someone@somedomain.com"
myMail.Bcc="someoneelse@somedomain.com"
myMail.Cc="someoneelse2@somedomain.com"
myMail.TextBody="This is a message."
myMail.Send
set myMail=nothing
%>
HTML 메일 발송 :
<%
Set myMail=CreateObject("CDO.Message")
myMail.Subject="Sending email with CDO"
myMail.From="mymail@mydomain.com"
myMail.To="someone@somedomain.com"
myMail.HTMLBody = "<h1>This is a message.</h1>"
myMail.Send
set myMail=nothing
%>
asp 웹페이지에서 HTML 메일을 발송하는 예제:
<%
Set myMail=CreateObject("CDO.Message")
myMail.Subject="Sending email with CDO"
myMail.From="mymail@mydomain.com"
myMail.To="someone@somedomain.com"
myMail.CreateMHTMLBody "http://www.w3schools.com/asp/"
myMail.Send
set myMail=nothing
%>
컴퓨터 상의 파일을 웹페이지에서 HTML 메일로 발송하는 방법:
<%
Set myMail=CreateObject("CDO.Message")
myMail.Subject="Sending email with CDO"
myMail.From="mymail@mydomain.com"
myMail.To="someone@somedomain.com"
myMail.CreateMHTMLBody "file://c:/mydocuments/test.htm"
myMail.Send
set myMail=nothing
%>
첨부파일을 텍스트 메일로 발송하는 방법:
<%
Set myMail=CreateObject("CDO.Message")
myMail.Subject="Sending email with CDO"
myMail.From="mymail@mydomain.com"
myMail.To="someone@somedomain.com"
myMail.TextBody="This is a message."
myMail.AddAttachment "c:\mydocuments\test.txt"
myMail.Send
set myMail=nothing
%>
원격지 메일 서버를 사용하여 텍스트 메일을 발송하는 방법:
<%
Set myMail=CreateObject("CDO.Message")
myMail.Subject="Sending email with CDO"
myMail.From="mymail@mydomain.com"
myMail.To="someone@somedomain.com"
myMail.TextBody="This is a message."
myMail.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/sendusing")=2
'Name or IP of remote SMTP server
myMail.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/smtpserver") _
="smtp.server.com"
'Server port
myMail.Configuration.Fields.Item _
("http://schemas.microsoft.com/cdo/configuration/smtpserverport") _
=25
myMail.Configuration.Fields.Update
myMail.Send
set myMail=nothing
%>
'개발도 하냐?' 카테고리의 다른 글
| 사파리 윈도우용 출시 (0) | 2007.07.03 |
|---|---|
| 미래를위한선택-웹호환성 (0) | 2007.06.18 |
| EMAIL 에러메세지 (0) | 2007.04.19 |
| CreateObject("CDO.Message") (0) | 2007.04.17 |
| 웹 호환성 평가항목 (0) | 2007.02.07 |
웹 호환성 평가항목
2007. 2. 7. 14:53
웹 호환성을 점검하는 항목으로 선정했던 내용.
1) HTML 문법 준수여부
- 홈페이지언어사용 표준(HTML 4.01 또는 XHTML 1.0)
- http://validator.w3.org/, http://validator.kldp.org/ 검사.
(HTML 4.01 또는 XHTML 1.0 인지의 여부는 자동판별 불가시 수동평가필요하며, 웹 페이지 캐릭터셋의 사용이 미적용 된 경우는 euc-kr 또는 utf-8로 전환하며 평가 수행)
2) CSS 문법 준수여부
- 웹 문서 구성요소에 대한 스타일 정의 표준(CSS 1.0)
- http://jigsaw.w3.org/css-validator/, http://css-validator.kldp.org/ 에서 CSS 부분에 대한 오류 평가
(프레임 구조로 제작된 경우는 메인프레임의 URL을 사용해서 평가 수행)
3) JavaScript 오류
- W3C DOM & ECMAScript 3rd 의 준수여부
- 파이어폭스의 내장 자바스크립트 콘솔을 이용한 DOM & 스크립트 문법의 오류가 있는지 판별
- 각 운영체제에 탑재된 기본 웹브라우저를 이용한 스크립트 오류 평가
4) 글로벌 네비게이션 정상작동
- 웹 사이트 메뉴 전체를 직접 클릭하여 접근해 보고, 모든 페이지에 접근이 가능한지 평가
- 각 운영체제별로 메뉴를 브라우징해서 접근이 불가능한 경우는 오류로 판별
5) 회원가입 정상작동
- 회원 가입이 정상적으로 가능한지 평가 (회원가입이 없는 경우는 제외)
- 회원가입시 요구하는 실명인증 또는 기타인증이 불가능한경우도 기능오류로 판단
6) 로그인 정상작동
- 회원 로그인이 정상적으로 가능한지 평가 (로그인 없는 경우는 제외)
- 호환성 오류가 아닌 경우(프로그램오류)도 기능오류로 판단
7) 콘텐츠 정상표시
- 플래쉬, 동영상, 이미지, vod 등의 콘텐츠가 모든 브라우저에서 제대로 표시되는지 평가
8) 파일다운로드 정상작동
- 게시물에 첨부된 파일의 다운로드 또는 사이트에서 제공하는 다운로드 기능들이 모든 브라우저에서 정상작동인지 평가 (다운로드 기능이 없는 경우 제외)
(한글이름의 파일들이 비정상으로 다운로드 되거나 문자셋이 다르게 다운로드 되는 경우도 모두 오류로 평가)
9) 인쇄기능 정상작동
- 운영체제에서 제공하는 인쇄기능이 아니라, 사이트내의 기능으로 구현한 인쇄기능의 경우를 검사하여, 인쇄에 이상이 없는지 평가 (사이트 내 인쇄기능이 없는 경우는 제외)
- 브라우저의 인쇄버튼이 아니고, 사이트내부 기능으로 인쇄버튼을 구현한 목록에 대한 평가
10) 인증서기능 정상작동
- 사용자의 인증을 요구하는 기능이 있는 경우 모든 브라우저에서 정상작동 하는지 평가 ( 인증서 요청이 없는 경우는 제외)
11) 정보검색 및 조회기능 정상작동
- 사이트에서 제공하는 검색 및 조회 기능을 수행하여, 모든 브라우저에서 기능이 정상인지 평가
12) 사용자의사 전달기능 정상작동
- 사용자 측면에서 웹 사이트에 의사를 전달하는 기능이 정상작동 되는지 평가
- 사용자가 사이트에 의사를 전달하는 모든 기능, 게시판 글쓰기, 폼 메일 발송 등의 기능에 대한 평가
'개발도 하냐?' 카테고리의 다른 글
| 사파리 윈도우용 출시 (0) | 2007.07.03 |
|---|---|
| 미래를위한선택-웹호환성 (0) | 2007.06.18 |
| EMAIL 에러메세지 (0) | 2007.04.19 |
| CreateObject("CDO.Message") (0) | 2007.04.17 |
| CDOSYS를 사용하여 ASP에서 메일발송 (0) | 2007.04.17 |
