화면처리 레이어(Presentation Layer)

화면처리 레이어는 MVC(Model-View-Controller) 패턴에서 View에 해당합니다. 화면처리 레이어의 구성은 다음과 같습니다.  


<그림> 화면처리 레이어 구성  




Spring MVC, Internationalization, Ajax Support, Security, UI Adaptor 이상 5가지 기능을 제공합니다.  


MVC 패턴의 프레임워크는 스프링 MVC, 스트럿츠(Struts), 웹워크(Webwork) 등이 있지만, 표준프레임워크에서는 스프링 MVC를 채택하였습니다.  


국제화(Internationalization) 기능은 다국어를 처리하는 방법입니다. 스프링 MVC의 LocaleResolver를 이용합니다. 브라우저 헤더, 세션, 쿠키 등에 있는 언어 정보를 이용해서 해당 언어로 페이지를 보여주는 기능입니다.  


Ajax 지원은 AjaxTags 라이브러리를 이용합니다. Ajax를 이용해 자주 사용되는 기능을 custom tag형태로 제공합니다.  


인증, 권한 같은 일반적인(통상적인) 개념의 Security 서비스는 Spring Security를 활용한 공통기반 레이어에

서 제공합니다. 화면처리 레이어의 Security 서비스는 입력값 유효성 검증 기능을 제공한다. 스프링과 연결되는 자카르타 커먼스 밸리데이터(Jakarta Commons Validator)를 이용합니다.  


UI 어댑터는 표준프레임워크와 RIA(Rich Internet Application) 솔루션을 연결하기 위한 기능입니다. 마이플랫폼 등의 상용 솔루션과 연결을 지원하는 기능입니다.  


저작자표시

전자정부 표준프레임워크를 프로젝트에서 사용했는지 안 했는지 검증하는 방법입니다.


Q: 표준프레임워크를 적용가이드보면 '표준프레임워크 적용여부를 확인하는 간단한 방법 

'이 있습니다. 

1. 저희가 개발한 프로젝트에서 3가지 항목만 준수하여 적용되면 '표준프레임워크가 적용'되었다고 보면 되는건가요 ? 

2. 표준프레임워크 적용여부를 검증해주는 기관 또는 부서가 있는지요 ? 

3. 개발사 측에서 표준준수확인할 수 있는 가이드가 있는지 궁금합니다. 


A: 

보신 가이드는 개발자가 아닌 발주자가 참조하는 가이드 부분에 포함되어 있는 내용입니다. 
즉, 표준프레임워크에 대해 잘 모르시는 분이 대략적으로 표준프레임워크가 적용되어 있는지 확인하기 위한 용도입니다. 

보다 자세하게 기준을 말씀드리면 다음과 같습니다. 
- Annotation 기반의 Spring MVC 적용 
- Layered architecture 준수 (@Controller, @Service, @Repository) 
- Data Access Layer의 경우 iBatis 적용 등 입니다. 

보다 자세한 내용은 다음 링크의 문서를 확인하시면 됩니다. 
http://www.egovframe.org/wiki/lib/exe/fetch.php?media=egovframework:rte2:호환성가이드라인.ppt 

또한 표준 프레임워크 센터에서는 표준프레임워크 적용점검 서비스를 제공하고 있습니다. 

감사합니다. 


from: http://open.egovframe.kr/projects/qna/qna/6393



호환성가이드라인.ppt


저작자표시
온실에서 키운 화초는 약하다고 합니다. 프로그램 개발환경 중에서 가장 온실같다고 할까요, 그런 게 있습니다. 바로 브라우저의 HTML 렌더러입니다. 가장 마음이 넓은 실행기라서 마크업이 깨져도 알아서 대체로 잘 보여주는 편입니다.

때문에 웹 개발자들은 프로그래머 취급도 못받고 허드렛일꾼으로 대하던 시절이 있었습니다.
하지만 그런 유약한 개발습관에서 벗어나 조금 깐깐해질 필요가 있는 것 같습니다.
자바원의 북스토어에서 본 책 중 인상적인 것 하나가 Refactoring HTML이었습니다.

IBM DW에도 비슷한 류의 글이 올라왔군요.

유효성 검사는 여러분의 페이지에 "예측 가능한"이라는 도장을 찍는 방법이다. 태그를 적절히 사용하면, 페이지는 구조적으로 건전하며, 사용과 탐색도 쉽다.

from: http://www.ibm.com/developerworks/kr/library/wa-inherit1/

프로그래머들의 애매한 결과에 대한 삽질은 누구나 겪는 일이지만 HTML 개발자들이 가장 심하다고 말하면 지나친 생각일까요?

유지보수하는 입장에서 HTML을 다루는 자세와 기법에 대해서 도움이 되는 내용이었습니다.

좋아하는 기획자 중 한 부류는 기획서가 깐깐해서 처음에 답답해 보이지만 프로젝트 후반에 말바꾸지 않고 신뢰감있게 독려하는 분들입니다. 웹개발도 깐깐하게 바꿔보는 것이 어떨까요.

한국어를 사용하는 우리에게 불필요한 기능 하나가 있습니다. 대표적인 것이 스펠링(spellig) 체크하는 기능이죠. 이것 외에도 이클립스 WTP를 설치하고 기본적으로 설정을 바꿔주는 것이 좋은 것들이 있는데 소개하려 합니다. 이클립스 유로파(3.3) WTP 버전을 기준으로 합니다.

1. 스펠링 체크 안하기

2. 문법검사 파일 범위 줄이기

3. 공백 비교 안하기

4. 이클립스 최대 메모리 확보하기

5. 패키지 익스플로러 트리계층으로 보기

6. Problems 뷰에서 하위 항목만 보기


일단 이 정도를 뽑아봤습니다. 성능에 관련된 것도 있고, 편한 UI 때문에 적어놓은 것도 있습니다.

제가 이클립스를 설치하고 손대는 설정들입니다.

검사(validation)이라는 녀석은 말이죠, 아무 때나 들이대면 피곤합니다. 3.3에서 추가된 spelling check도 마찬가지죠. 지난 번에는 이 기능을 잠재우는 방법을 소개했었습니다. 이번에도 비슷한 경우를 얘기해봅니다. 툴의 기본 성격은 자동화입니다. 문법 자동 체크, 형식 자동 체크 등이죠. 하지만 느슨한 검사를 하는 HTML 같은 경우, 신경쓰고 싶지 않은 때가 많습니다. 더군다나 기존의 html코드가 저주받은 경우는 더 하죠.
사용자 삽입 이미지

index.jsp 파일에 경고도 아니고, 빨간 딱지가 붙었습니다. 굉장히 신경쓰이죠.
사용자 삽입 이미지

파일을 열어봤습니다. 도대체 무엇을 잘 못 했길래... 쯔업. 주석처리한다는 것이 >/tr<를 낙오시켜 버렸군요.
잘못한 것 많네요. 하지만, 이런 류의 미스는 신경쓰기 싫다 하시는 분들, 언제 저주받은 html을 다 정리하냐 현실적으로 불가능하다 하시는 분들, 그래서 준비했습니다. 음주단속 피하는 방법처럼 이것도 피하는 방법이 있습니다. 음주단속이야 술 안마시면 걸리지 않죠. 양조장에서 일하기 때문에 몸에서 기본적으로 알코올 도수가 나온다면... 음... 지금 삼천포로 가고 있습니다. 일단 Preferences 를 열어서 validation이라고 칩니다. Validation 메뉴 선택하고 세팅을 다음과 같이 맞춰줍니다.
사용자 삽입 이미지


xml 문법체크는 중요하기 때문에, 어긋나면 웹 애플리케이션이 죽어버리니까 체크했습니다.
그리고 프로젝트 다시 빌드하시면 깨끗하게 나옵니다. 그래도 찜찜하죠. 앞으로 짜는 코드는 말끔하게 짜 주세요. 특히나 table 태그 안에서 tr 사이에 있는 기생하는 form 태그, table 밖으로 나오시거나 td 안으로 들어가세요.
한 줄이 붕 뜬다고요? form 태그 속성에 style="margin:0" 주시면 그런 거 없습니다.
웹표준, 그리 나쁘지 않습니다.
w3의 validation을 통과하던 페이지에 JavaScript를 통해서 생성하는 컨텐츠 부분의 코드 때문에 validation이 깨져버렸다.
가이드 문서를 따라가 보니
document.write("</p>");
위와 같이 문자열 안에 있는 마크업 태그 때문에 파서가 인식하지 못한다는 것이다.

document.write("<\/p>");
해답은 위와 같이 닫는 태그 부분을 escape시켜주면 된다고 하는데, 적용해봐야겠다.

웹표준 어렵다.

가이드 대로 수정을 해서 적용하니 다시 통과된다.
okjsp validation passed

okjsp validation passed



related: http://www.htmlhelp.com/tools/validator/problems.html#script

+ Recent posts

티스토리툴바