[Info]Tags categorized posts and contents patterns..

[AJAX] Ajax Code E xamples.. [Book] About the book.. [CSS] CSS Code E xamples.. [DB] Sql Code E xamples.. [DEV] All development stor...

2016년 2월 19일 금요일

[JAVA]cos.jar로 파일 업로드 하기..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

파일업로드를 하려면 기본적인 POST방식으로는 안되고 파일업로드를 처리할 수 있는 무언가(?) 있어야 한다.

일단 jsp에서 파일 업로드를 선택하는 form에서 entype이 multipart/form-data로 보내야 한다. 그렇지 않으면  받는쪽에서 파일을 받을 수가 없다. 파일이 없으면 보통의 form은 entype을 바꾸어 주지 않아도 된다.

Html

<form name="writeForm" method="post" action="writeProc.jsp" enctype="multipart/form-data" >
     <input type="file" name="attachFile" size="40" />
</form>

이제 받아야 하는데 이걸 받는 역할을 cos.jar가 한다. 폼전송을 multipart/form-data로 보냈기 때문에 기존에 폼을 받던 request.getParameter()로는 받을 수가 없다. 그래서 cos.jar가 파일도 받고 폼의 다른 값들도 다 받아주는 역할을 한다.

cos는 com.oreilly.servlet의 약자이다. 보면 알겠지만 보통 java에서 package를 정의할 때 쓰는 방식이고 이 팩키지를 jar로 묶어서 cos.jar라고 배포를 하는 것이다. cos.jar의 페이지에서 cos-05Nov2002.zip를 다운로드 가능하다.(파일명에서 보아 알겠지만 2002년 11월이 가장 최신판이다  ㅡ..ㅡ) 다운받은 파일안에 lib에 있는 cos.jar를 WAS쪽에 넣어도 되고 해당 프로젝트의 WEB-INF안에 lib안에 넣어도 된다. cos.jar를 사용한다고 했지만 정확히는 cos.jar의 MultipartRequest를 이용해서 파일을 받는다.

Java

<%@ page import="com.oreilly.servlet.MultipartRequest" %> 
<%
     int maxPostSize = 10 * 1024 * 1024; // 10MB
     saveDirectory = config.getServletContext().getRealPath("/upload");
     MultipartRequest multi = new MultipartRequest(request, saveDirectory, maxPostSize, "utf-8");

     Enumeration formNames=multi.getFileNames();  // 폼의 이름 반환

     String fileInput = "";
     String fileName = "";
     String type = "";
     File fileObj = null;
     String originFileName = "";    
     String fileExtend = "";
     String fileSize = "";

     while(formNames.hasMoreElements()) {
          fileInput = (String)formNames.nextElement();                // 파일인풋 이름
          fileName = multi.getFilesystemName(fileInput);            // 파일명
          if (fileName != null) {
               type = multi.getContentType(fileInput);                   //콘텐트타입    
               fileObj = multi.getFile(fileInput);                             //파일객체
               originFileName = multi.getOriginalFileName(fileInput);           //초기 파일명
               fileExtend = fileName.substring(fileName.lastIndexOf(".")+1); //파일 확장자
               fileSize = String.valueOf(fileObj.length());                    // 파일크기
          }
     }
%>

위의 소스가 MultipartRequest를 이용한 파일 받기 예제이다. 소스가 그렇게 어렵지 않기 때문에 크게 어려운 부분은 없다고 생각한다. MultipartRequest에 파라미터를 넘기기 위해서 최대용량과 저장폴더의 실제경로를 미리 만들어 주고 MultipartRequest의 객체 생성을 할 때 request와 함께 넘겨준다. MultipartRequest는 아주 다양하게 오버라이딩되어 있기 때문에 전달해야하는 파라미터에 대해서는 원하는 대로 사용할 수 있다. MultipartRequest의 정의는 cos.jar쪽 페이지에 자세하게 나와 있다.

파일이 몇개가 넘어오든 간에 MultipartRequest에서는5번라인의 객체생성 부분에서 모두 파일이 업로드 되어 저장되고 그 뒤에 저장한 파일들의 정보를 가져오는 형태로 되어 있다. 이 말은 정보를 얻기 전에 파일 저장이 먼저 되기 때문에 파일의 어떤 정보를 검사해서 저장할지 말지를 결정하는 것이 안된다는 얘기고 저장한 다음에 검사를 해서 삭제해 주는 형태가 되어야 할 것이다.

7번 라인에서는 Enumeration으로 multi객체로 부터 전달받은 폼의 이름을 구해온다. 9~14번에서 while루프 안에서 사용한 변수들을 초기화 하고 16번라인부터 7번에서 구해온 폼이름을 통해서 파일객체를 가져오면서 다 가져올때까지 루프를 돈다. while형태로 되어 있기 때문에 단일 파일이든 여러개의 파일이 올라오든 모두 처리가 가능하다. while문 안에서는 각 파일의 정보를 구해온다. 이렇게 구해온 정보는 보통은 Database에 넣을 목적으로 구해 올 것이며 필요한 것만 가져와서 사용하면 되겠다.

여기서 input=file외에 다른 input에 대한 값들을 가져오려면 request.getParameter()대신에 multi.getParameter()를 사용해주면 된다. (여기서 multi는 위에 예제소스에서 만든 MultipartRequest의 객체이다.) 사용법은 동일하다.

각자 다르겠지만 일반적으로 서버에 파일을 저장할 때는 사용자가 올린 파일명을 그대로 올리지 않는다. 이는 여러가지 이유가 있는데 jsp같은 경우는 올리지 못하게 하는게 일반적이고 올리더라도 실행되지 않도록 확장자를 날리는 등의 조치를 취함으로써 보안처리를 해준다. 또한 같은 파일명이 있을 경우에 이전파일을 덮어쓰면 안되기 때문에 같은 파일명이 있을 경우에 대한 처리를 해야하고 우리같은 경우는 한글로 된 파일명은 서버에 따라서 문제가 생길수도 읽고 띄어쓰기나 특수기호등 파일명에 대한 안정성을 보장할 수 없기 때문에 나같은 경우는 대게 영문이나 숫자의 조합으로 특정파일명을 만들어서 저장한 뒤에 디비에는 서버쪽 파일명과 초기파일명을 둘다 넣어두고 서버쪽 파일명을 이용해서 찾고 다운할때나 보여줄때는 초기파일명을 가지고 처리한다.

이렇게하려면 업로드할때 파일명을 바꾸어 주어야 한다. MultipartRequest객체를 생성할 때 파일명을 수정하도록 파라미터를 하나 더 주면 된다.

MultipartRequest multi = new MultipartRequest(request, saveDirectory, maxPostSize, "utf-8", new DefaultFileRenamePolicy());

4번째 파라미터로 DefaultFileRenamePolicy를 넘겨준다. DefaultFileRenamePolicy는 cos.jar는 안에 존재하는 클래스이다. 파일명을 어떻게 바꾼다라는 규칙이 정해져 있는 클래스를 파라미터로 넘겨주고 파일을 업로드 할때 그 규칙에 따라 파일명이 바뀌어서 올라간다. 여기서 DefaultFileRenamePolicy는 같은 파일명이 있는지를 검사하고 있을 경우에는 파일명뒤에 숫자를 붙혀준다. ex: aaa.zip, aaa1.zip, aaa2.zip 이런 식으로...

이 규칙에 따르면 중복에 대한처리는 할 수 있지만 그 외의 경우에는 대응할 수가 없다. 그래서 DefaultFileRenamePolicy의 규칙을 필요하다면 수정해 주어야 한다. cos.jar안에 src파일도 있으니 직접 수정하고 다시 jar로 만들어도 되고 cos.jar는 그대로 두고 따로 클래스를 만들어서 MultipartRequest객체를 생성할 때 내가 만든 클랙스를 넘겨주어도 된다.

MultipartRequest multi = new MultipartRequest(request, saveDirectory, maxPostSize, "utf-8", new MyFileRenamePolicy());

MyFileRenamePolicy 클래스는 FileRenamePolicy로 부터 상속도 받아야 하고 혹시모를 다른 충돌도 막기 위해서 DefaultFileRenamePolicy와 동일하게 com.oreilly.servlet.multipart라는 팩키지를 만들어서 넣는다.

DefaultFileRenamePolicy.java
Java

package com.oreilly.servlet.multipart;
import java.io.*;

public class DefaultFileRenamePolicy implements FileRenamePolicy {
     public File rename(File f) {
          if (createNewFile(f)) {
               return f;
          }
          String name = f.getName();
          String body = null;
          String ext = null;

          int dot = name.lastIndexOf(".");
          if (dot != -1) {
               body = name.substring(0, dot);
               ext = name.substring(dot);  // includes "."
          }
          else {
               body = name;
               ext = "";
          }

          int count = 0;
          while (!createNewFile(f) && count < 9999) {
               count++;
               String newName = body + count + ext;
               f = new File(f.getParent(), newName);
          }
          return f;
     }

     private boolean createNewFile(File f) {
          try {
                return f.createNewFile();
          }
          catch (IOException ignored) {
               return false;
          }
     }
}

이게 기존에 있는 DefaultFileRenamePolicy.java의 소스이다. 소스는 처음에는 좀 어색하지만 그리 어렵지 않다. rename()이 처음 호출되는데 createNewFile()를 실행해서(5라인) 파일생성이 가능하면 그대로 끝을 내고 생성을 못했으면 파일명의 점(.)을 기준으로 파일명과 확장자를 나누어서 저장한다.(13라인) 그리고 파일생성이 가능할 때까지(중복파일이 없을때까지) 루프를 돌아서 파일명+숫자+확장자형태로 다시 만들어서 리턴한다.(23라인)



MyFileRenamePolicy.java
Java

package com.oreilly.servlet.multipart;
import java.io.*;
import java.util.Date;
import java.text.SimpleDateFormat;

public class AlmapFileRenamePolicy  implements FileRenamePolicy {
     public File rename(File f) {
          long currentTime = System.currentTimeMillis();
          SimpleDateFormat simDf = new SimpleDateFormat("yyyyMMddHHmmss");
          int randomNumber = (int)(Math.random()*100000);
    
          String uniqueFileName = "" + randomNumber + simDf.format(new Date(currentTime));

          String name = f.getName();
          String body = null;
          String ext = null;

          int dot = name.lastIndexOf(".");
          if (dot != -1) {
               body = name.substring(0, dot);
               ext = name.substring(dot);  // includes "."
          }
          else {
               body = name;
               ext = "";
          }
    
          String tempName = uniqueFileName + ext;
          f = new File(f.getParent(), tempName);
          if (createNewFile(f)) {
               return f;
          }

          int count = 0;
          while (!createNewFile(f) && count < 9999) {
               count++;
               String newName = uniqueFileName + "_" + count + ext;
               f = new File(f.getParent(), newName);
          }

          return f;
     }

     private boolean createNewFile(File f) {
          try {
               return f.createNewFile();
          }
          catch (IOException ignored) {
               return false;
          }
     }
}

새로 만든 파일 명명규칙인 MyFileRenamePolicy이다. 기존에 있던 것에서 파일명명하는 방식만 약간 바꾼 것이다. 앞에것보다는 약간 길어졌지만 간단하다. 파일중복을 줄이기 위해서 5자리짜리 랜덤수와 현재날짜시간의 조합으로 유니크한파일명을 만든다(12라인) 앞에것과 동일하게 점(.)을 기준으로 파일명과 확장자를 분리하고(18라인) 분리한파일명대신 유니크한 파일명과 확장자를 조합해서 임시로 파일명을 만든 다음에 파일생성을 시도한다.(28라인) 성공하면 그대로 끝내고 실패하면 루프를 돌면서 파일생성가능할때까지 카운트를 올려서 유니크한 파일명_카운트.확장자형태가 되도록 만든다.

이렇게 모든 파일은 랜덤수+현재시간.확장자의 형태로 만든다.여기서는 파일명으로 수자만 사용했지만 원하는 규칙대로 만들어서 클래스를 구성해 주면 그에 맞게 리네임을 할 수 있다.

[Book] RIA 개발을 위한 실버라이트 입문..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

실버라이트 입문 : RIA 개발을 위한 - 8점
애덤 내이썬 지음, 이정웅 옮김/에이콘출판

이번에 실버라이트 교육을 받으면서 교재로 쓰인 책이다. 이책을 중심으로 해서 진도를 나가진 않았지만... ㅎㅎㅎㅎ 어쨌든 현재 한국에 나와 있는 실버라이트 책으로는 이 책과 "HOONS 닷넷과 함게하는 실버라이트" 딱 2권 뿐인데 훈스닷넷에서 만든 책은 실버라이트 1.1 기반으로 만들어 졌는데 MS가 올해로 넘어오면서 1.1에 대한 플랜을 변경하고 대대적인 변화를 주어 2.0으로 방향을 바꿈으로 해서 현재로써 이책은 큰 의미가 없어진 듯 하다(샀는데.. ㅠ..ㅠ 공도님이 올리신 글 참고)

그래서 애덤 네이썬이 쓴 이 책이 현재 국내에서 유일한 책이나 마찬가지이다. 지금 실버라이트가 2.0 RC0까지 나왔지만 이 책은 1.0중심으로 되어 있다. 1.0 중심으로 되어 있다는 것은 자바스크립트로 실버라이트를 컨트롤 한다는 이야기이다. 1.0과 2.0은 그 기능에서 엄청난 차이가 있고 (내가 2.0 개발은 거의 손대지 못했지만) 전체적으로 아주 대대적인 변화가 있다고 보기 때문에 2.0을 하기 위해서 반드시 1.0을 보아야 하는 것은 아니라고 본다.

하지만 양쪽을 다 할 수 있다면 좋은 거고.... 하다보면 자바스크립트로 컨트롤 해야할 필요성이 있다고 생각한다.어쨌든 1.0과 2.0은 아예 다른걸로 보아야 한다는 것인데 이책은 2.0이 등장하기 전에 작성된 책이다. (출시일은 올해 3월이긴 하지만 번역서이고 하니...)

국내에서 유일한 1.0에 대한 책이라고는 하지만 내용은 상당히 충실하다고 생각한다. 한권만 있으면 허접한 경우도 꽤 많지만 이 책은 상당히 충실한 편이다. 아무래도 실버라이트 1.0을 하려면 XAML에 대한 이해도 필요하고 자바스크립트로 접근할 수 있는 영역과 자바스크립트의 활용능력 등등이 필요할 것인데 내 느낌으로는 이 책은 XAML에 좀 치중되어 있다. 그도 그럴것이 자바스크립트 자체가 하나의 언어이기 때문에 그 자바스크립트를 설명하기 위해서 많은 지면을 할애하기 보다는 대부분의 설명이 XAML이 어떻게 구성되어 있고 어떤 동작을 하기 위해서 XAML이 어떻게 구성되는 지를 보여주고 그에 대한 속성들을 자바스크립트 쪽에서 어떻게 접근하는지 정도만 간단하게 보여주고 있다.

자바스크립트를 복잡하게 써서 화려한 실버라이트를 다루는 것은 보여주지 않는다는 얘기다. 그건 자바스크립트의 활용능력에 달려 있으니까 능력껏 하라는 것이고 어떤걸 다룰수 있고 어떻게 접근하는지만 설명하고 있다. 하지만 그렇다고 부실하게 느껴지지는 않는다. 말그대로 그 이상은 개인 능력이니까...

이 책이 고급 사용자를 위한 타겟팅이라고는 보이지 않고 제목대로 입문용이다. 각 객체의 특성과 기능들에 대해서 기본적인 부분에 대해 자세히 설명을 하고 있다. 그 이상은 각자 노력하는 수밖에.... 중간중간 현재 1.0이 가진 버그라던지 불가능한 점, 주의해야할 점들까지도 자세하게 짚어주고 있기 때문에 1.0에 대한 입문용으로는 손색이 없다고 생각한다.(비교 대상이 없긴 하지만...) 지은이가 많은 테스트와 이해를 가지고 책을 썼다는 것을 느낄 수 없다.

1.0이기 때문에 비쥬얼 스튜디오가 필요 없어서 툴에대한 얘기는 전혀 나오지 않는다. XAML도 익스프레션 블랜드를 사용해서 대부분 만들겠지만 여기서는 툴에 대한 언급만 잠깐 있을뿐 툴을 사용하는 것에 대한 설명은 전혀 나와있지 않다.

2.0으로 대세가 넘어가긴 했지만 1.0에 관심이 있다면 입문용으로 볼만하다고 본다. 물론 많은 활용을 위해서는 인터넷에 올라와 있는 많은 포스팅들이 더 큰 도움이 될꺼라고 생각한다.

[Book] 프로토타입과 스크립타큘러스..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

프로토타입과 스크립타큘러스 - 10점
크리스토피 포트누브 지음, 박영록 옮김/인사이트

자바스크립트 프레임워크의 시초라고도 할 수 있는 prototype.js와 그 기반으로 만들어진 라이브러리인 script.aculo.us에 대한 책이다. 나는 자바스크립트를 시작하면서 부터 프로토타입 프레임워크를 사용했기 때문에 개인적으로 애착도 있고 꽤 좋아하는 편이다. 요즘은 추세가 jQuery쪽으로 가고 있는 듯하지만 지금 수많은 자바스크립트 프레임워크의 포문을 연 프로토타입 프레임워크의 위상을 무시할 수 없다고 생각하고 있다. 아직 jQuery를 접하지는 못했지만 prototype.js가 내가 자바스크립트를 좋아하게 된데 큰 역할을 했기 때문에 난 아직 prototype.js의 펜으로 남아있다. ㅎ

계속 프로토타입을 쓰고 있다고 했지만 그 활용성에 대해선 미약한 편이었다. 초기에는 그냥 $만 쓰는 정도였고 조금씩 조금씩 늘려나갔지만 프로토타입이 지원하는 양은 엄청났다. 그리고 프로토타입을 익히기 위한 리소스는 상당히 부족했다. 작년까지는...............

올해부터는 상당히 달라졌다. 국내에 출간된 프로토타입관련 책으로는 "Ajax prototype.js : 프로토타입 완전분석", "Prototype & Scriptaculous 인 액션" 이렇게 총 3권뿐이고 작년에는 "Ajax prototype.js : 프로토타입 완전분석"만이 있었다. "Ajax prototype.js : 프로토타입 완전분석"은 작년에 읽고 포스팅하기는 했지만 레퍼런스처럼 처음부터끝까지 각 함수의 정의와 사용법만 나열한 책이라서 활용하기에 제한이 좀 있었다. 그리고 프로토타입.js스크립타큘러스사이트도 올해다 개편이 되어서 API문서가 상당히 충실하게 지원되고 있다.(아~ 행복해...)

이 책은 프로토타입과 스크립타큘러스를 어떻게 활용해야 하는지에 집중한 책이다. 프로토타입 프레임워크자체가 상당히 고급 자바스크립트이고 이걸 이해하기 위해서는 알아야 될 사항들이 너무나도 많다. 때문에 이 책에서는 이런 부분에 대한 설명은 집중하지 않고 의도인지는 모르겠지만 내가 느끼기에는 어느정도 프로토타입 프레임워크를 약간은 아는 사람을 기준으로 설명하는 것으로 느껴졌다. 어차피 모든걸 다 설명할 수는 없으니 기본적이 사항들은 패스하고 넘어간다.

이런 부분이 설명을 대충한다는 얘기가 아니다. 오직 프로토타입에만 집중했다는 이야기이다. 각 클래스들의 기능들과 어떤 함수들이 있는지를 설명하고 간단한 예제를 통해서 어떤식으로 활용해야 하는지를 잘 풀어설명하고 있다. 내가 느끼기에는 나같이 프로토타입을 알고 사용하고자 하는데 고급활용으로는 하고있지 못하고 있는 사람들한테 딱 맞는 책이라고 생각된다. 최근에 나온 책답게 프로토타입 1.6을 기준으로 설명이 되어 있으며 중간중간 성능에 대한 부분이나 1.5와는 달라진 부분까지 설명하고 있으며, 책 전체적으로 저자와 역자가 모두 프로토타입 프레임워크의 개발 사상을 이해하고 있는 느낌을 받았다. 단순히 메서드의 사용방법만 논한 것이 아니라 전체적인 개발방향에 대해서 제시해 주고 있다.

예제들은 그냥 보기에는 간단한듯 하면서 막상 소스를 보면 꽤나 어렵다. 프로토타입의 활용방식 자체가 좀 덜 일숙한 것도 있고 예제자체가 좀 고급적인 부분도 있다. 이책의 전부를 이해한것은 아니다. 오히려 이해를 못한 것이 많다. 한 3번정도나 봐야 어떤식으로 활용할지를 잡을수 있을것 같은 느낌인데 내가 아쉬워하는 부분들이 꽤나 해소되었다. 이벤트리스너의 사용방식이라든지 이뉴머레이블 사용방법등.... 한번만 읽었어도 느낌바가 많다. 심지어 $가 그냥 document.getElementById의 축약형태에 불과한게 아니라는 것 등... 또한 책이 소제목들만 봐도 약간은 유머스럽게 지어서 전체적으로 너무 딱딱하지 않게 되어 있어서 코드에 대한 어려움을 좀 적게 느껴지게 만든다.

프로토타입과 스크립타큘러스에 대해서는 오랫동안은 이책이 필수도서가 될것 같은 느낌이다. 이 둘에 대해서 알고 싶다면 일단 이책을 보라고 하고 싶다. (인액션은 구입하고 아직 읽지는 못했는데 평은 좀 그닥인 느낌이다.) 그동안 프로토타입을 사용한다고 말하기가 좀 창피했었는데(ㅡ..ㅡ) 이제는 여기 나온것들을 내 것으로 만드는 일만 남았다. 마침 관련해서 할일도 생겼고... ㅎ

사족으로... 요즘 인사이트 책 참 좋은것 같다. 내가 가려운 부분과 잘 맞아떨어져서 그런것도 있지만.. ㅎㅎㅎㅎ (결코 인사이트 관련자 아님.. ㅋ)

[JSP]JSP 템플릿 사용하기..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

개발을 할 때 어찌됐든 가장 신경써야 하는 것중 하나는 DRY(Don't Repeat Yourself)이다. 실용주의 프로그래밍같은 쪽에서 항상 강조하는거고... 유지보수 해보면 코드를 모듈화해서 재사용성이 얼마나 중요한지 피부로 느낄수 있다.(메뉴 글자 하나 바꾸는거 똑같은거 열몇개씩 계속 해보면... ㅋ 꼭 한번에 말안하고 다 바꾸면 변경사항 또 얘기해주고.. ㅋ )

JSP에서도 forword기능을 사용해서 페이지의 공통부분을 템플릿으로 뽑아내서 공통으로 사용할 수 있다. 예를 들어 모든페이지에 똑같은 로고, 상단메뉴, 사이드메뉴, 푸터 등등 어느 페이지나 공통으로 들어가는 틀을 가지고 있는 템플릿을 사용해서 코드작성을 줄일수 있다. 참고로 말하자면 이건 MVC Model 1정도에서 쓰일 방법이라고 생각한다. 고급으로 갈수록 이런 걸 대체할 수 있는 용도의 것들이 많이 존재하고 있으니까...(나두 Model 2에 JSTL하고 싶다규 ㅠ..ㅠ)

Java Jsp
[햄한테서 가져올 때는 Java 였지만, 아무래도 Jsp 가 맞는듯 해서 바꿨다..
물론, 전체적으로 봤을 때 Java 가 될 수도 있지만, 현재 저 소스만 봐선.. Jsp 내에서..
다른 Jsp 로 forward 하는 듯하기 때문에..]

<jsp:forward page="template.jsp">
    <jsp:param name="CONTENT" value="introView.jsp" />
</jsp:forward>


예를 들어 사이트 소개페이지인 intro.jsp를 위처럼 만든다. 아무것도 하는 일이 없다. 페이지를 받자마자 template.jsp로 요청을 포워딩해준다. forward는 요청을 그대로 포워딩하는 것이기 때문에 포워딩된 후에도 주소창에는 그냥 intro.jsp가 있다. 페이지를 템플릿으로 포워딩하면서 introView.jsp라는 파일명을 파라미터로 넘겨준다.

그럼 template.jsp를 보자.

Html

<%
    String content = request.getParameter("CONTENT");
%>
<html>
    <head></head>
    <body>
        <jsp:include page="/template/header.jsp" flush="false" />

        <jsp:include page="/template/mainMenu.jsp" flush="false" />

        <jsp:include page="<%= content %>" flush="false" />

        <jsp:include page="/template/footer.jsp" flush="false" />
    </body>
</html>



html코드는 별로 중요하지 않으니 간략화 했다. 탬플릿페이지를 가지고 있고 템플릿이 각 부분(위에서는 헤더, 메인메뉴, 푸터)의 공통파일을 불러들이고 바뀌어야 하는 부분만 content변수를 이용해서 다른 파일을 불러온다. 이렇게 하면 공통적인 곳의 코드는 한파일에서 관리하고 상황에 따라 어느정도 유연하게 템플릿파일을 구성해서 사용할 수 있다. 그리고 위의 예제에서는 3번째 include에서 파라미터로 받은 introView.jsp를 인클루드 한다. 바뀌는 부분의 파일명만 변수로 설정하여 원하는대로 바꾸어서 출력할 수 있다.

flush는 true일 경우 인클루드 전에 현재 있는 버퍼를 출력한다. 보통 false를 사용하는 듯한대 상황에 따라 선택할 나름이다. 인클루드에도 파라미터를 forwoard사용시와 동일하게 넘겨줄 수 있지만 이런식에 구성에서는 intro.jsp가 받은 파라미터를 템플릿이나 include되는 파일내에서 모두 getParameter로 받을수 있기 때문에 아주 특이한 경우 아니면 템플릿에서 파라미터를 넘겨줄 필요는 없을 듯 하다.(너무 믿지는 마시길.. ㅎㅎ) 이제 introView.jsp에 원하는 내용부분을 작성하면 된다.





여기서 인클루드를 사용할 때 동적으로 할지 정적으로 할지는 약간 생각해 보아야 할 문제이다. 파일 인클루드는 <jsp:include>액션태그(동적)와 include 디렉티브(정적) 2가지 방식이 있다.

<jsp:include page="introView.jsp" flush="false" />
<%@ include file="introView.jsp" %>

위 두 코드는 보이는 면 동일하게 동작을 한다. 하지만 동작방식 자체는 완전히 다른데 동적과 정적이라는 말에서도 느낄 수 있듯이 액션태그로 사용하면 페이지가 요청할 때마다 인클루드 페이지를 실행하고 결과를 가져와서 인클루드 하는 방식이고 디렉티브 방식으로 하면 jsp를 처음 컴파일 할 때부터 인클루드 할 페이지의 소스를 가져와서 해당위치에 넣은 후에 컴파일을 한다. 컴파일된 입장에서 본다면 디렉티브를 사용하면 하나의 파일이나 마찬가지란 얘기다.

이 방식을 이해하면 몇가지 더 생각해야 할 부분이 있다. 액션태그로 하면 모든 jsp가 다른 파일이나 마찬가지기 때문에 모든 변수를 새로 정의해 주어야 한다. 파라미터도 파일마다 따로 받고.... 보여주고자 하는 intro.jsp의 입장에서는 같은 변수나 파라미터를 여러번 정의하고 받아오는 것이다. 반면 디렉티브 방식은 결국은 하나의 파일이 된다고 했다. 그래서 template이나 다른 인클루드 파일에서 정의한 변수를 또다른 인클루드에서 정의할 경우는 변수가 중복되기 때문에 에러가 난다.

또한 디렉티브 방식은 소스가 바뀔때 반드시 재컴파일 되는것을 보장해주지 않는다고 한다. 그리고 완전히까지는 분석되지 않았는데 액션태그 방식을 사용하던 중 특정 인클루드된 파일이 갱신되지 않고 계속해서 임시인터넷 파일에서 나와서 캐시사용을 막아주어야 했었다.. ㅜ..ㅜ  물론 속도면에서는 디렉티브 방식이 당연히 빠르다. 그리고 또한유지보수 할 때 자신이 만든 소스가 아니면 변수추적을 해야 되는데 이렇게 파일이 쪼개져 있을 경우 상당히 쉽지 않다. 액션태그 방식은 그나마 괜찮지만 디렉티브 방식을 사용하면 변수선언이나 할당등이 다른 파일에 있을 경우가 많기 때문에 추적하기가 만만치 않다. 어느쪽이 좋을지는 자신이 상황에 맞게 선택할 일이다.

[Info]Tags categorized posts and contents patterns..


  • [AJAX] Ajax Code Examples..
  • [Book] About the book..
  • [CSS] CSS Code Examples..
  • [DB] Sql Code Examples..
  • [DEV] All development story..
  • [EP] Epilogue..
  • [HTML] Html Code Examples..
  • [JAVA] Java Code Examples..
  • [jQuery] jQuery Code Examples..
  • [JS] JavaScript Code Examples..
  • [JSP] Jsp Code Examples..
  • [Talk] Free Talk..
  • [Tool] About tools..
  • [.NET] .Net Code Examples..
  • [NEWS] IT News..
  • [Hobby] All My hobbies..
  • [Linux] Linux Instruction word..
  • [UFC] Ultimate Fighting Championship News..

  • 태그 작성시 글의 성격에 따른 카테고리 기본적으로 추가..
  • [Book] 내용에 대한 내 생각은 [블라블라..] 로 문장 뒤에 작성..
  • 내용 중 취소를 해야될 내용은 취소선 표시 후 [취소이유..] 로 문장 뒤에 취소 이유 작성..
  • 내용에 추가 작성시 맨 하단에 2016.01.01 수정 & 추가.. [굵게/먼저한 순서대로 작성..]
  • 한 해 마지막 및 시작은 매년 1월1일에 "Started in 2017 & Terminated in 2016" 의 제목으로 작성..

[TOOL]OKJSP 세미나 : 이클립스 기본..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

토요일(20일)에 OKJSP에서 주최하는 "이클립스 기본"에 대한 세미나가 있었다. 나는 툴 사용을 상당히 좋아하기 때문에 이클립스에 대해서 좀더 알기 위해서 갔다왔다.(계획에 없이 목요일에 무리하게 달린 관계로 당일날 아침에 갈까말까를 좀 고민하긴 했지만... ㅋㅋㅋ)

세미나의 제목대로 세미나는 이클립스의 기본에 대한 부분이었다. 이클립스는 IDE이기 때문에 수많은 기능들과 플러그인들로 인하여 막상한 기능을 가지고 있지만 이날 강좌에서는 처음 이클립스를 접하는 사람을 대상으로 기본적인 내용을 설명했다. 물론 내가 모르는 것들도 많았고 애매한 부분이 정리된 것들도 있었지만 약간은 난이도가 높았으면 하는 바램도 약간 있었다. (강의자료는 아니지만 강의목차(?)에 대한 부분은 kenu님의 블로그에 있다.)




보통은 세마나의 내용 전부를 정리하는 편이지만 이번에는 툴에 대한 사용법이었기 때문에 정리를 해서 요약을 한다는 것이 쉽지 않았다. 그래서 그냥 나중에 내가 참고할 필요가 있는 내용 정도로만 정리를 한다.

줄이동 : alt + 위아래 화살표
            줄을 블록설정해서 cut&paste할 필요가 없이 원하는 줄에서 위 단축키를 사용하면 바로 줄 이동 가능
줄복사 : ctrl + alt + 위아래 화살표
           현재 라인과 같은 라인이 위/아래에 복사되어 생김

단축명령어 설정 : [Preferences] - [Java] - [Editor] - [Templates]에 단축명려이어에 대한 설정이 있다. 이곳에 있는 명령어를 입력하고 ctrl + space를 입력하면 해당 코드로 자동으로 바뀐다. sysout을 입력하면 System.out.println()이 입력되는 식

단축키 리스트 : ctrl + shift + L 을 입력하면 바로 단축키 리스트를 볼 수 있다. 여기서 단축키를 한번 더 입력하면 Preferences로 들어간다.

Cheet Sheet : [Help] - [Cheat Sheet]에 들어가면 이클립스나 플러그인들의 간단한 튜토리얼을 볼 수 있다. (초기에 참고하면 좋을 듯...)

이클립스는 기본적으로 JRE만 있으면 실행할 수 있다. JDK나 클래스패스 설정은 없더도 되면 1.5이상을 권장한다.

Project Explorer 뷰에서 오른쪽 그림의 Link....아이콘을 활성화 시키면 Editor뷰에서 다루고 있는 파일이 자동으로 Project Explorer 뷰에 표시가 된다. Tree가 닫혀 있을 경우에는 열리면서 표시가 된다.

Quick Access : 이클립스 3.3 유로파부터는 ctrl + 3 으로 실행하는 퀵엑세스라는 기능이 추가되었다. Editors, Views, Perspectives, Commands, Menus, New, Preferences, Properties등에서 원하는 기능 및 파일을 바로 찾을수 있다. 퀵엑세스 레이어에 원하는 단어를 입력만 하면 된다.

[Preferences] - [General] - [Editors] - [Text Editors] - [Spelling]에서 Enable spell checking의 체크를 풀어주면 이클립스에 약간의 성능향상을 꾀할 수 있다. 영어권이 아니라면 사실상 거의 필요가 없다.(더 자세한 내용은 kenu님의 이클립스 WTP 기본 최적화 참고)

Project Explorer뷰에서는 파일 복사등을 할때 약간의 제약들이 있는데 Navagator뷰에서는 탐색기처럼 자유롭게 복사등을 할 수 있다.

Open Resource : ctrl + shift + R 을 통해서 원하는 파일을 바로 찾을 수 있다.

eclipse Live에서 영어이긴 하지만 웨비나(Webinar -> Web Seminar)나 팟캐스트 영상을 많이 볼수 있다. 좋은 강좌들이 많기 때문에 참고할 만하다.





대충 정리는 이정도로 되고 추가 얘기중에 ECF(Eclipse Communication Framework)가 흥미로웠다. 특히 Cola: Real-Time Shared Editing이라는 데모영상은 아주 흥미로웠다. 곧 시간내서 처음부터 다시 봐야겠다. 간단히 얘기하자면 온라인에 있는 사람과 ECF를 통해서 연결한 다음 한파일을 열어놓고 동시에 코딩을 한다. 한명은 윗쪽에서 한명은 아랫쪽에서....


나는 이클립스를 메인 IDE로 사용하고 있다. 툴의 통일성(?)을 위해서 클라이언트 사이드는 Aptana를 사용하고 있다. 툴의 바탕이 같기 때문에 손에 익기가 훨씬 쉽기 때문에.... 아주 기본적인 부분만 사용하고 있었기에 다른 사람들은 어떻게 어떤 기능들을 더 사용하나 하는 것이 이번 세미나에 참가한 목적이었다. 그런면에서는 기본에 충실하게 잘 들은것 같다.

앞쪽에서 약간의 아쉬움을 말했지만 다른 이클립스 관련 강좌에서는 너무 몰라서 좌절감을 느끼곤 했었으니까.... ㅋ 역시 툴은 자기 손에 얼마나 익숙하냐가 가장 중요한것 같다. 그리고 손에 익을수록 효율도 올라가니까... 근데 자꾸만 쓰던 방식으로만 쓰게 되니까.. ㅠ..ㅠ 괜찮아 보이는 단축키는 실제 개발할 때도 계속 사용할 수 있도록 신경써야겠다. ㅋ

[Talk]Google Blog Error..

The combined length of all the labels must be at most 200 characters..

두둥.. 햄의 글들을 퍼오고 있는데..
갑자기 생긴 에러..

처음에는 저 글 자체를 읽지도 않고서..
걍 IE 에서 일시적으로 발생한 에러로 생각하고서..
'게시' 만 계속해서 눌렀다.. 그런데 아무래도 이상하단 말이지.. [믕챙하긴.. ㅡㅡ..]

그래서 결국에는 새로고침을 눌러서 새로 저장을 눌러서..
똑같은 상황을 만들고, 그제서야.. 에러를 확인했다.. [개발도 아닌데.. 왠 똑같은 상황..]

무튼 그렇게 하고서 다시 저 오류를 보니..
결론은.. 직역하면 "레이블 길이가 200자이어야 된다.." 으잉..??..

구글 블로그 관리자 모드에서 글을 올릴 때 작성하는.. 오른쪽 태그 작성 공간..
그 공간에 tag.length < 200 이어야 된다는 것.. [ㅋㅋ.. 저렇게 적으니 왠지 개발자 스럽지..??]

머 그렇다는 것.. 햄 블로그는 그런게 없나보다..
그렇게 길게 태그가 작성된 것 보니.. 근데 도움말이나 아무것도 없었는데..
구글 이것들.. 은근히 이런 UI 내에서의 설명이나 그런건 좀 약한 듯..

방명록이 없는것도.. 카테고리 추가 안되는 것도.. [편법으로 하면 있지만..]
다 이해는 하지만, 그래도 설명은 친절하게 해주지..
꼭 뻘겅색으로 그렇게 에러 표시를 해야되것니..

에잇.. 드러버서.. 태그 확 줄이고서.. 글 올린다..
영어 조금만.. 아주 조금만 하면 아는 오류.. 설마 나처럼..
무작정 글 저장 버튼 누르고서 "어라.. 왜 안되지.. ??.. ㅡ..ㅡ+.." 이러는 사람은 없긋지..

[EP]Internet Explorer 8 Beta2 기술세미나 후기..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

한국 Microsoft에서 IE8 Beta2 한글판 출시에 맞춰서 기술세미나를 열어서 갔다왔다. IE8의 달라진 모습에 대해서 소개하는 자리였다. 보통은 세션별로 정리를 하고는 하는데 이번에는 앞에서 소개하고 뒤에서 설명하는 방식이었기 때문에 그냥 정리한다.

사용자 삽입 이미지

핵심적인 새 기능은 뒤로하고 달라진 새 기능에 대해서 설명하자면....

  • 빨라진 속도 : 이전까지는 HTML파싱을 하다가 Javascript 파싱을 할때는 HTML파싱이 멈추었지만 이제는 동시에 진행이 되어 속도가 빨라졌다. JS엔진도 6,7에 대해서 비약적으로 빨라졌다.
  • 호환모드의 빠른 전환 : 주소창 옆의 작은 아이콘을 통해서 IE7의 렌더링 엔진으로 빠르게 전환할 수 있다.
  • 탭 컬러링 : 관련 탭이 쉽게 구분되도록 관련 탭끼리 다른 색으로 표현해 준다.
  • 새로운 탭의 추가기능 : 새로운 탭을 열었을 때 최근에 닫은 탭리스트를 볼수 있으면 닫은 탭을 다시 띄웠을 때 해당 탭의 히스토리 영역까지 함께 복구된다.
  • 새로운 탭의 추가기능 :새로운 탭을 열었을 때 클립보드에 있는 단어를 바로 검색어로 검색할 수 있도록 하는 기능을 제공한다.
  • 쿠키, 임시 인터넷 파일을 삭제할 때 자주 방문하는 사이트에 대한 것들은 삭제하지 않도록 하는 기능 제공
  • InPrivate : 인프라이빗 기능을 사용하여 인터넷을 사용하면 해당 탭의 내용은 히스토리, 쿠키등이 전혀 남지 않아서 프라이버시를 보호할 수 있다.
  • 강화된 보안 : SmartScreen 필터와 XSS 필터를 통해서 피싱 및 크로스사이트스크립팅에 대해서 안전하게 보호한다.
  • 강화된 웹표준 지원 : (정확히 표기하지는 않았지만 시연상으로는 Acid2를 통과하는 것을 보여주었다. 스마일 마크 제대로 잘 나옴)
  • LCIE(Loosely Coupled IE) : IE8의 새로운 아키텍쳐로 구글 크롬처럼 각 탭이 별도로 분리된 프로세스로 동작되기 때문에 한 탭의 문제가 다른 탭에 영향을 끼치는 것을 최소화한다.


IE8에서는 위의 내용 외에 다음과 같은 3가지 큰 기능이 추가되었다.

Accelerator

사용자 삽입 이미지
엑셀레이터는 말그대로 인터넷 사용에 가속도를 붙히기 위한 기능이다. MS의 설명에 따르면 인터넷 사용자가 한 페이지에서 단어를 복사해서 다른 페이지에서 사용하는 경우가 상당히 많은데 엑셀레이터는 이러한 부분에 대해서 편의성을 제공하기 위한 기능이다.

오른쪽의 사진처럼 원하는 단어를 블럭설정하면 그 옆에 엑셀레이터사용을 위한 아이콘이 나타나고 아이콘을 선택해서 프로바이더를 고르면 선택한 단어를 사용하여 프로바이더가 제공하는 화면을 바로 보여주는 기능이다. 단어를 복사해서 새탭을 열고 검색사이트에 가서 다시 검색하는 것과 같은 패턴을 빠르게 할 수 있도록 해주는 것이다.

위의 설명처럼 프로바이더가 있듯이 IE7의 오른쪽상단의 빠른 검색의 프로바이더를 설정해 주듯이 엑셀레이터를 위한 프로바이더도 사용자가 따로 설치를 해주어야 한다.  그리고 프로바이더는 엑셀레이터를 위한 페이지를 따로 호출하고 이 페이지를 요청하는 자바스크립트를 따로 만들어서 제공하여야 한다.

구현에 대한 부분도 시연을 하였지만 후기에서는 굳이 다루지는 않을 것인데 엑셀레이터에 대한 기능을 제공 하는 것은 별로 어렵지 않다.


Instant search

사용자 삽입 이미지
인스턴트 서치는 IE7에서 오른쪽 상단에서 바로 원하는 검색엔진을 통해서 검색을 할 수 있도록 하는 기능이다. IE8에서 이 인스턴트 서치가 강화되었는데 Search suggestions과 Visual search를 제공하고 있다.

선택된 프로바이더를 통해서 단어를 한글자씩 입력할 때마다 요즘 대부분의 검색사이트가 제공하는 자동완성 기능처럼 인스턴트 서치창을 통해서 해당 검색사이트로 이동하지 않고도 Search suggestions를 통해서 자동완성과 같은 기능을 제공 받을 수 있다.

또한 마찬가지로 Visual search 기능은 오른쪽 사진처럼 단순히 자동완성 외에도 해당 단어와 연관되는 프로바이더가 제공하는 정보를 사진과 함께 제공받을 수 있더서 검색할 때 상당한 편의성을 제공하고 있다.(이정도면 이기능만 잘 지원되면 왠만한 경우에는 검색사이트를 가지도 않고 원하는 사이트로 이동하는 경우도 많을 꺼라는 생각도 든다. ㅋ)

인스턴트서치도 엑셀레이터와 마찬가지로 프로바이더가 인스턴트서치를 위한 페에지를 따로 만들어 주어야 한다. 이 기능에 대한 부분은 아마존의 A9.com에서 처음 만든 OpenSearch를 그대로 이용하고 있다. html페이지와 XML, 자바스크립트로 구성되어 있고 자세한 내용은 오픈서치의 스펙을 확인하면 된다. (간단한 시연으로는 상당히 쉽게 구현해서 만들수 있다.) 엑셀레이터와 마찬가지로 프로바이더를 제공하고 등록은 사용자가 직접 등록을 해주어야 한다.





Web Slices

웹슬라이스는 그 이름그대로 웹페이지의 일부를 잘라내서 볼 수 있게 하는 기능이다.

사용자 삽입 이미지

위 화면처럼 웹슬라이스가 제공되는 곳에 가면 웹슬라이스 아이콘이 나타난다. 아이콘을 클릭하면 해당 부분에서 제공하는 웹슬라이스가 즐겨찾기에 저장이 된다.

사용자 삽입 이미지

즐겨찾기에 저장된 웹슬라이스를 클릭하면 사이트로 이동하지 않고 바로 작은 창을 통해서 해당 페이지를 볼 수 있다. 수시로 확인해야 하는 부분의 경우 보고 싶을때마다 사이트로 이동하지 않고 이렇게 웹슬라이스를 통해서 바로바로 볼 수 있다. 예를 들어 경매중인 상품이나 수시로 조회해야하는 배송조회 등이 있다.

웹슬라이스 기능은 위의 다른 두기능처럼 별도의 페이지가 아닌 실제 서비스하는 웹페이지 상에 넣어야 한다.(당연한 얘기다. 그래야 슬라이스를 하지...) 웹슬라이스를 제공할 div부분에 class로 hslice라고 주면 해당부분을 웹슬라이스로 제공할 수 있고 그 아래 엘리먼트에 class="entry-title"이라고 주면 그부분에 넣은 텍스트가 웹슬라이스의 제목이 된다. 내용 부분은 class="entry-content" 부분을 통해서 제공할수 있고 ttl을 통해서 웹슬라이스의 갱신 주기(분단위)도 정해줄 수 있다.

배송조회등 개인적인 로그인이 필요한 웹슬라이스도 있는데 이런 부분에 대해서 개인적으로 문의해 본 결과는 웹슬라이스를 제공하는 쪽에서 슬라이스 부분에 로그인창이 뜨도록 만들 수도 있으면 웹슬라이스쪽에 보안을 약간 낮추어서 쿠키나 세션등을 통해서 로그인을 유지하게 할 수도 있다고 한다. 어쨌든 이부분은 서비스 제공자쪽에서 책임지고 고민해 보아야 할 부분같다.


위의 3가지 대표기능들은 MS 에반젤리스트 블로그에 잘 정리되어 올라와있다.


개발자를 위한 IE8

이것은 일반사용자가 필요한 IE8의 새 기능은 아니지만 IE8에는 개발자를 위한 도구가 추가되었다. 실제 써봐야 알겠지만 시연을 볼때의 느낌으로는 firebug수준의 개발툴이 IE8에 내장되었다.

F12를 통해서 실행할 수 있고 CSS가 각 블럭마다 체크박스가 있어서 블럭별로 CSS적용을 on/off할 수 있는 부분은 상당히 인상적이었다. 당연히 DOM을 분석해 볼수 있는 기능을 제공하고 있으면 렌더링 엔진 교체라든지 창크기변경등의 기본적이 기능들도 포함되어 있다.

사용자 삽입 이미지

골치아픈 문제중의 하나인 자바스크립트 디버거도 제공하고 있으며, Break Point나 라인단위로 실행하면서 현재 라인의 각 변수의 정보등을 확인할 수 있다. 그동안 IE는 쓸만한 웹개발툴이 없다는게 항상 단점으로 지적되었는 데 IE8에서는 그 부분이 해소될 듯 하다. IE에서 웹개발을 하려면 많은 툴을 조합해서 쓰고 있었는데 개인적으로 이건 많은 기대감을 가지고 있다.


이날 발표된 발표자료는 MSDN POPCONIE8 세미나 후기 및 발표자료 다운로드라는 글로 포스팅되어 올라와있다. 소스에 대한 부분도 많이 나와있어서 참고할만하다.

이날 세션에서는 실제 구현사례로 옥션이 나왔다. IE8 베타를 깔았다면 옥션에서 제공하는 IE8 서비스페이지에서 각 기능을 사용해 볼 수 있다. 비슷하게 ebay에도 IE8을 위한 서비스를 하고 있다.

난 아직 약간 고민중.. 흠... IE8을 깔면 이게 따로 안깔리고 IE7을 잡아먹어버리기 때문에 베타는 말그대로 베타인데 주요브라우저를 사용못하게 되니까 IE7의 렌더링엔진이 있다고 하더라도 약간 고민하고 있는건 사실이다. 그래도 곧 깔게 되겠지만.. ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

약간의 개인적인 생각을 추가하자면 엑셀레이터나 인스턴트 서치는 크게 문제가 안된다고 생각하는데 웹슬라이스의 경우는 고민을 좀 해보아야 하지 않나 생각한다. 위에 언급했던 보안문제는 이렇든 저렇든 좋은 방향으로 해결될 것 같은데 내가 얘기하고자 하는 것은 웹표준에 대한 부분이다. 다른 2기능은 어차피 페이지가 별도로 제공되니까 IE사용자가 더 펀하게 사용할 수 있도록 해주는 것은 도움이 분명 된다고 생각한다.

하지만 웹슬라이스의 경우는 웹슬라이스를 구현하기 위해서 모두가 보는 페이지에 웹슬라이스에 대한 설정을 해주어야 한다. (MSDN을 보면 위방법외에도 웹슬라이스를 위한 페이지를 따로 구성하는 방법에 대해서도 나와있다. 2008.9.22 joongs님의 덧글로 수정함) 물론 웹슬라이스를 위한 설정이라고 해봤자 위에서 본대로 class를 사용하기 때문에 웹표준에서 크게 벗어나지는 않지만 우리가 웹표준을 얘기할때는 하나의 소스로 모든 접근에 대처하고자 하는 것인데 오직 IE8 사용자만을 위한 웹슬라이스는 약간 꺼름칙하다.(문제라고 할정도는 아니라고 생각하기에 이런 단어를 선택했다.) 돌아가는데 문제는 없지만 오직 웹슬라이스만을 위해서 div를 하나더 span을 하나더 사용해야 할지도 모를일이고 CSS상속이 꼬일지도 모를일이다. 물론 크로스 브라우징을 위해서 브라우저별로 인식할 수 있게 하고 있기는 하지만 같은 기능을 모든곳에서 제공하기 위해서 추가 코드가 들어가는 것과 한 브라우저를 위한 추가코드가 들어가는 것은 좀 다른 얘기가 아닌가 싶다.

시도가 있어야 발전이 있지만 웹표준을 지원한다고 표명하고 나오면서 약간 IE만의 독자적인 부분을 가지고 가는 것은 약간은 아쉬운 부분이다.

My Comment..
IE8 버전.. 지금은 어차피 IE11 을 쓰고 있당..
그런데도 이 글을 가져온 이유는.. 아니 이 글 뿐 아니라.. 때 지난 글들도..
가져오는 이유는.. 그 글을 읽으면서 몰랐던 것을 느꼈거나..
혹은 나도 똑같은 실수를.. 범한적이 있었던 글들이거나..

비록 지금은 쓰더라도.. 개념이나 기능들을 제대로 모르고 막연하게 쓴다거나..
머 기타 이유들로 인해서다..

꼭, 지금 현재의 근래 기술과 글들이 아니더라도..
내가 느끼는 바가 있다면, 읽어보고 가져와서 올리고..[오탈자도 수정하고.. 후훗..]

머 그런거지..

[Book] 자바스크립트 완벽 가이드..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/


자바스크립트 완벽 가이드 - 전2권 - 10점
데이비드 플래너건 지음, 송인철 외 옮김/인사이트

이 책은 원래도 엄청 유명한 책이다. 이번에는 인사이트에서 나왔지만 그전에는 한빛에서 나왔었다. 아마 3판인가 그랬을껀데 수년전에 나오고는 절판되어서 현재로써는 구할 수 없는 책이 되어버렸었다. 내가 처음 자바스크립트를 공부할 때 책이 필요해서 찾고 있었는데 작년에는 그 책을 구할 수 없었는데 너무나 반갑게도 인사이트에서 이번 5판의 번역서를 출간해 주었아. (작년에 WROX책으로 하나 샀었는데 내용도 너무 오래됐고 이젠 진짜 볼일 없을듯... ㅋ 올해는 자바스크립트 좋은 책이 너무 많이 나와서 행복할 정도다.. ㅋ 작년에 그렇게 고를만한 책이 없더니만...)

어쨌든 자바스크립트 완벽가이드....  마케팅적인 측면에서 책 제목을 거창하게 짓는 경우가 참 많지만 이 책은 진짜로 완벽가이드라는 제목이 어울린다. 이해하지 못한 부분도 많지만 이 책은 자바스크립트의 모든 것을 다 다루고 있다. 너무 한쪽에만 치우치지도 않고 너무 부실하지도 않고 전체적으로 필요한 부분을 제대로 잘 설명한 느낌이다.

나는 자바스크립트를 아예 처음부터 prototype.js를 가지고 시작했기 때문에 좀 하다보니 자바스크립트 자체의 기능과 프로토타입 프레임워크에서 제공하는 부분이 혼동이 생겼기 때문에 자바스크립트 자체에 대해서 좀 알아야 될 필요성을 느껴서 이 책을 잡았다.






이 책에서는 자바스크립트 그 자체에 집중하고 있다. 자바스크립트가 어떻게 구성되어 있고 어떻게 돌아가는부터 아주 기본적인 부분을 설명하고 있고 이런 것들을 어떻게 사용하는 것이 정확하고 요즘 추세가 어떤식으로 흘러가는 지에 대해서도 잘 나와있다. 무엇보다 너무 이론에만 치우치지 않고 그래도 돌려볼 수 있는 다양한 예제가 설명과 함께 잘 어우러져 있어서 이해하기가 좋다.

이 책을 지은 데이비드 플래너건이 얼마나 자바스크립트를 깊게 이해하고 있는지를 책을 읽는 내내 느낄 수 있었다. 자바스크립트는 그 기본인 ECMAScript에 대한 부분도 있고 브라우저마다 지원하고 안하는 부분에도 상당히 차이가 있기 때문에 헷갈리고 어려운 부분이 있는 것이 사실이다. 하지만 이 책에서는 자바스크립트의 모든 것을 다 다루고 있다. 단순히 기능 하나를 구현하기 위해서가 아닌 자바스크립트라는 것 자체를 이해하고 활용할 수 있도록 원리에 대한 설명을 아주 충실히 하고 있다.

자바스크립트를 하면서 최소한 3번정도는 봐야할 것 같다고 느낀 책... 이 책 한권만으로도 평생 옆에두고 참고해야할 레퍼런스로써 부족함이 없다. 이 책은 2권으로 되어 있는데 한권을 말그대로 자바스크립트를 설명하는 책이고 나머지 한권은 자바스크립트 API에 설명에 대한 책이라고 할 수 있다. 공부는 앞의 책으로 하지만 실제적인 활용에서는 두번째 책이 더 도움이 될것 같다. 자그마치 300페이지에 자바스크립트의 모든 함수에 대해서 설명해 놓았다.



자바스크립트계의 요다 스승 더글러스 크록포드가 자바스크립트 책으로는 "Javascript: The Definitive Guide(5/E)"만을 추천한다 라는 말이 무슨 말인지 읽고나서 알 수 있었다.

[CSS]CSS에서 font-size 사용에 대해서..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

html작업을 할 때 항상 신경쓰이는 것이 폰트이다. 별거 아닌것 같지만 작아졌다 커졌다. 가독성도 신경써야 하고 브라우저마다 다르게 보이고 CSS꼬이면 복잡해 지고 신경쓸 게 은근히 많다. 폰트도 중요하긴 하지만 여기선 일단 생략... 폰트가 어떻게 보이나를 좀 테스트 해 보았다. 나중에 일일이 테스트 해보지 않기 위해서..

Html

<head>
<style type="text/css">
        #size1 {font-size:10px;}
        #size2 {font-size:12px;}
        #size3 {font-size:14px;}
        #size4 {font-size:0.8em;}
        #size5 {font-size:1em;}
        #size6 {font-size:1.2em;}
        #size7 {font-size:x-small;}
        #size8 {font-size:small;}
        #size9 {font-size:medium;}
        #size10 {font-size:large;}
 </style>
</head>
<body>
    <div id="size1">This is a Test!! 테스트 중입니다. 10px</div>
    <div id="size2">This is a Test!! 테스트 중입니다. 12px</div>
    <div id="size3">This is a Test!! 테스트 중입니다. 14px</div>
    <div id="size4">This is a Test!! 테스트 중입니다. 0.8em</div>
    <div id="size5">This is a Test!! 테스트 중입니다. 1em</div>
    <div id="size6">This is a Test!! 테스트 중입니다. 1.2em</div>
    <div id="size7">This is a Test!! 테스트 중입니다. x-small</div>
    <div id="size8">This is a Test!! 테스트 중입니다. small</div>
    <div id="size9">This is a Test!! 테스트 중입니다. medium</div>
    <div id="size10">This is a Test!! 테스트 중입니다. large</div>
</body>


테스트를 위해 만든 소스이다. 예전에는 폰트 하면 다 px를 위주로 썼지만 웹표준 얘기가 거론되기 시작한 다음 부터는 em방식이 더 추천되는 것으로 느껴진다.

IE7에서의 폰트 사이즈 테스트

위 화면은 IE7에서의 화면인데 폰트 크기 설정에 맞게 적절하게 잘 보인다. 캡쳐는 IE7에서 했지만 대부분에 브라우저에서 특성에 따라 크기가 약간 차이가 있을뿐 거의 화면처럼 잘 보인다.(테스트한 브라우저는 IE6, IE7, Firefox2, Firefox3, Safari, Opera, Chrome이다. 물론 윈도우 환경에서...)




CSS는 특성상 상속을 받는다. 부모 엘리먼트에 지정된 속성은 하위 엘리먼트가 상속을 받는다. 그래서 전체적으로 먹이려는 스타일일수록 상위에서만 선언해 주면 된다. 여기서 폰트 단위의 설정이 중요한데 px의 경우 말그래로 절대값과 같다.(브라우저마다 똑같다는 얘기가 아니다.) 어디서 선언하든 10px는 10px의 크기이다. keyword의 경우도 해당 크기에 설정된 크기로 보여진다. 대신 em단위의 경우는 비율이다. 1em이 무조건 현재설정된 폰트의 크기이다. 0.8이면 80%작고 1.2면 현재보다 120%크게 나타난다. 다양한 상황에서 적절하게 크기차이를 줄수 있다는 것이다. 다만 em의 경우는 상속과적이 겹칠 경우에는 의도한 것과 다르게 중첩효과가 나서(0.8em에 또 0,8em이 된다는지 하는...) 크기가 아주 작아지거나 커질 수 있다.

위에서 말한대로 em을 많이 추천하는 데 사용하기가 좀 까다로운 em을 추천하는 이유는 크기 조절 때문이다. 브라우저에는 폰트 사이즈 조절 기능이 있다.(모르는 사람이 대부분인것 같지만...) 웹사이트는 인쇄물이 아니기 때문에 사용자가 편한대로 사용할 수 있어야 한다. 사용자가 눈이 나빠서 폰트를 좀 크게 설정해서 사용한다고 해서 문제가 되는 것도 아니고 이것 때문에 레이아웃이 약간 깨져도 잘못 된것도 아니다.  여기서 em을 추천할 때 px를 쓰면 IE에서 크기조절이 안된다는 이유를 꽤 많이 들어왔고 나도 em을 주로 사용했었는데 좀 테스트의 필요성을 느꼈다.

IE6에서의 폰트 사이즈 테스트

IE6에서의 화면이다. IE7에서 보다 좀 크게 보이는 이유는 폰트사이즈를 크게 했기 때문이다. 키워드 방식과 em방식은 폰트 조절에 맞추어서 크기가 좀더 커졌지만 px방식은 폰트 사이즈가 그대로인 것을 볼 수 있다. 폰트 사이즈는 당연하 사용자가 조절할 수 있어야 하는 기능이기 때문에 이부분은 상당히 중요하다. 테스트한 브라우저에서는 IE6을 제외한 모든 브라우저에서는 px방식 까지도 폰트사이즈 조절이 브라우저쪽에서 가능했다. 결론적으로 말하면 IE6의 유저가 상당히 있는 아직까지든 이부분을 고려해야 한다는 것이다.(XP의 서비스팩3에 IE7이 기본으로 들어가지 않은건 정말 아쉽다. ㅠ..ㅠ)

브라우저마다 약간의 특성 차이는 있었다. 확대/축소 단계가 아주 많은 브라우저도 있고 그보다는 약간 적은 단계를 가진 브라우저도 있었지만 사용하는데 큰 문제가 없을 정도의 단계는 다들 제공하고 있었다.

폰트 사이즈를 많이 줄인

대부분의 브라우저는 위 화면처럼 폰트가 읽지 못할 수준까지도 줄어들었다.

사용자 삽입 이미지

다만 사파리에서는 위 화면처럼 특정 크기 이하로는 더이상 줄어들지 않았다. 이런 부분은 브라우저 개발의 의도에 따른 부분이고 이보다 더 작게 할수 있냐 없냐는 크게 중요한 부분이 아니기 때문에 전혀 신경을 쓸 것은 없다고 생각한다.



덧) 웹표준 책을 읽었더니만 갑자가 퍼블리싱에 대한 포스팅이 많아져버렸네.. ㅋㅋㅋㅋ

[HTML]XHTML 사용에 대한 정리..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

나는 XHTML을 사용하기를 즐겨한다. 물론 난 퍼블리셔는 아니고 개발자이다. 큰 회사라면 퍼블리셔를 따로 두겠지만 작은 회사에서는 개발자가 이것저것 다 해야 한다. 그리고 나는 웹표준 옹호론자이다. 그리고 웹표준을 하는 것이 전체 웹에 도움이 된다고 믿고 있기 때문에 내가 참여하는 사이트라도 웹표준화에 일조하고자 한다.(현실은 머 만만치 않지만....)

퍼블리셔라는 영역이 생기면서 약간 애매해 진것은 사실이지만 퍼블리셔를 따로 두고 있는 회사는 그렇게 많아보이지 않는다. 일단 웹표준을 지키려고 하는 회사도 그리 많지 않지만...  어쨌든 이전의 방식과 호환성을 가지기 위해 사용하던 HTML 4.01이 지나 이제는 XHTML 1.0으로 가는게 맞다고 생각하고 있다. 논쟁을 하고자 하는 건 아니고 새기술이 좋다고 생각하는 전제를 깔고 있고 더 엄격한 규칙을 가지고 더 좋은 웹을 만들수 있는 것은 확실하다.





XHTML을 사용하기 위한 문서의 기본 구조는 전에 올린 XHTML 1.0 Transitional 문서 템플릿 포스트를 참고하고 여기에 적용되는 몇가지 XHTML의 규칙을 설명하고자 한다. 이 규칙들은 이전 HTML에서는 유효했지만 XHTML에서는 유효하지 않은 규칙들이다. 정의된 문서를 먼저 설명하면(위 템플릿 참고)

XHTML은 DOCTYPE을 무조건 선언해 준다. 이 문서가 어떤 문서인지를 정의 하는 것은 반드시 해야하는 것이고 DOCTYPE없으면 XHTML 유효성 검사를 할 수 없다.(HTML 4.01에서도 반드시 쓰라) 브라우저는 DOCTYPE이 있으면 표준모드로 없으면 호환모드로 돌아간다. XHTML은 Transitional, Strict, Frameset 3가지 DTD가 있는데 유연한 Transitional이 과도기인 현재로써는 가장 맞다고 생각한다. Strict는 상당히 쓰기가 어렵고 Frameset은 써본적도 없고 써보려고 해본적도 없다. 그리고 DOCTYPE은 HTML문서의 최상단에 있어야 한다.

XHTML 1.0 Strict
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

XHTML 1.0 Transitional
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

XHTML 1.0 Frameset
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

XHTML 1.1 Strict
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
(DTD는 w3c의 Recommended list of DTDs 참고)

그 다음에는 네임스페이스를 선언해 주는데 그냥 위 템플릿이라는 포스팅에 써진대로 복사해서 쓰면 된다.





XHTML에서 지켜야 할 몇가지 규칙을 정리해보자.(W3C 문서 참고)

모든 태그는 소문자로 적는다. 과거에는 대문자로 쓰는게 일반적이었지만 XHTML에서는 반드시 소문자로만 작성해야 한다. 단 속성값이나 내용은 대소문자에 상관없다.
<BODY></BODY> - (X)
<body><body>     - (O)


모든 속성값은 인용부호 안에 사용하고 속성들 사이에는 띄어쓰기를 해야한다.
<img src="banner.gif" alt=배너 />   - (X)
<img src="banner.gif" alt="배너" /> - (O)


모든 속성에는 값이 있어야 한다. 값을 지정안하고 선언하는 속성들이 있었지만 XHTML에서는 보기에는 어색하더라도 모두 속성을 지정해 주어야 한다.
<input type="text" readonly>                   - (X)
<input type="text" readonly="readonly" /> - (O)


모든 태그는 닫아준다. 이전에는 안닫아주었지만 모든 태극는 닫혀햐 한다. 여는 태그가 있으면 닫는 태그가 있어야 하고 단독적으로 쓰이는 태그(img, input, br 등등)도 반드시 닫아준다. 보통 단독태그에 닫아주는 표시를 할때는 슬래시(/)앞에 한칸을 띄워준다.
<p>내용        - (X)
<p>내용</p> - (O)
<br>   - (X)
<br /> - (O)


주석안에는 더블대시를 사용하지 않는다.
<!------------------------> - (X)
<!--====================--> - (O)


모든 <와 &는 변환을 해주어야 한다. 내용중에 <, &는 &lt; 와 &amp; 로 바꾸어 주어야 한다.
<div>you & me < test</div>           - (X)
<div>you &amp; me &lt; test</div> - (O)

id 사용 - 링크태그의 타겟으로 사용되던  name을 대체한다.(하위호환을 위해 name도 동시 사용)

모든 img태그에는 alt태그를 반드시 사용해 준다. alt는 이미지를 보여주지 못할때 이미지를 대체해서 보여줄 대체택스트로 이미지에 대한 설명을 뜻한다. 브라우저가 툴팁으로 보여주어서 잘못 사용하고 있기는 하지만 툴팁은 title속성을 사용하여야 한다.





좀 다른 얘기로 스크립트 얘기를 하자면 한 문서에는 여러 스트립트가 가능하므로 기본적인 사용 스크립트를 메타태그를 이용해서 지정할 수 있다.
<meta http-equiv="Content-Script-Type" content="text/javascript">
라고 작성하면 된다  보통 이 메타태그가 없으면 브라우저는 자바스크립트가 기본이라고 생각한다.
<script type="text/javascript"></script> 가 정상적이다. MIME타입으로 text/script가 많이 사용된다는 이유로 RFC 4329가 승인했다. application/javascript를 더 권장하고 있지만 실제 브라우저에서 잘 지원되지 않고 있다. 또한 스크립트 코드에 language="javascript"로 작성된 것을 많이 볼 수 있는데 이것은 type이 지원되지 않을 때의 잔재인데 하위 호환성을 위해서 사용할 수도 있다.

참고로 CSS의 경우는
<meta http-equiv="Content-Style-Type" content="text/css" />
코드를 통해서 문서의 CSS스타일을 정의할 수 있다.





아래 부분은 XHTML에 해당되는 내용은 아니지만 XHTML을 사용할 때 구조적인 HTML을 구성하려는 의도가 더 강하다고 생각했을 때나 웹접근성을 생각했을 때 고려해야 할 부분

  • <b>보다는 <strong>를, <i>보다는 <em>을 사용한다.
  • 텍스트의 경우는 div가 아닌 <p> 태그를 사용한다.
  • 해드라인의 경우 div에 적당한 클래스를 주는 것이 아니라 <h1>, <h2>태그 등을 사용한다.
  • table태그에는 summary 속성을 지정할 수 있다. 대부분의 브라우저는 summary를 보여주지 않지만 시각장애인용 스크린리더등에서는 summary를 읽어준다.
  • 태그에 accesskey 속성을 주면(ex: accesskey="1") 사용자가 단축키로 사용할 수 있게 해준다.(하지만 대부분의 브라우저는 이를 사용자에게 보여주지 않기 때문에 사용법에 대한 것을 따로 알려주어야 한다.)
  • tabindex를 사용하면(ex: tabindex="1", tabindex="2") 사용자가 탭을 눌렀을 때 옮겨지는 form 컨트롤를 지정할 수 있다. tabindex가 없으면 소스에 나와있는 순서로 옮겨진다.

[Book] 제프리 젤드만의 웹표준 가이드..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

제프리 젤드만의 웹표준 가이드 - 10점
제프리 젤드만 지음, 이준.남덕현 옮김/위키북스




나는 퍼블리셔는 아니고 개발자이지만 웹표준을 준수한 HTML코딩에 대해서 관심이 많기 때문에 이 책을 빼들었다. 아주 큰 회사라면 모르겠지만 작은 회사들은 개발자가 많은 영역을 손대야하기 때문에 퍼블리싱 부분에도 전여 관여 안할 수도 없고 오히려 웹표준을 준수하는 부분에 대한 책임이 없다고 하기는 어렵다고 생각한다. 또한 포털등에 있다는 퍼블리셔들 말고는 대부분의 내가 겪은 웹디자이너들은 웹표준의 개념은 커녕 CSS에 대한 지식조차 전무하다고 느낄 정도였다.

어쨌든 관심이 있다 보니 좀 만져봤고 지금은 웹표준에 대한 내가 가진 생각도 어느정도 잡힌 상태이고 CSS를 이용해서 어느정도의 페이지는 만들어 낼 수 있는 정도는 되었다. 팁이나 인터넷 아티클로는 웹표준에 대한 생각을 정립하기가 쉽지 않았기 때문에 책을 통해서 좀더 정확한 걸 알고 있었던 것이 이책을 본 주 이유이다.





웹표준에 대한 책은 여러가지가 있지만 책으로 보는 것은 이 책이 처음이다. 그래서 다른 책과 비교하기는 어렵지만 그냥 내가 이책을 본 느낌을 말하겠다.

이책은 표준으로 HTML 코딩을 할 수 있게 하는 HTML태그나 CSS의 사용법에 대해서 집중해서 설명하는 책은 아니다. 무슨 말이냐 하면 웹표준을 설명하면서 <i>태그는 어떤 용도이고 <br>태그는 어떤 태그인지에 대한 설명은 거의 하지 않는다. 주요 맥락을 짚으면서 간간히 설명하기는 하지만 그부분에 대해서 초점을 맞추고 있는 것이 아니기 때문에 html이나 css의 사용법에 대해서 다 설명하지 않는다. 다는 아니더라도 어느정도는 이해 할 수 있었지만 기본적인 html + css에 대한 지식이 없으면 책을 읽는데 약간 어려움이 있을 지도 모르겠다.

전반적으로 계속 팁에 대해서 설명하기는 하지만 실제 책의 한 챕터를 할당해서 CSS를 이용해서 사이트를 만드는 법에 대해서 설명하는 부분은 마지막 장 한장에 불과하다. 물론 책 내내 부분부분적으로 잘못 사용된 예라든가 어떻게 해결해야 하는 가에 대해서 설명하면서 CSS의 많은 사용방법을 얘기하고 있기는 한다.

이 책을 보면 저자인 제프리 젤드만이 얼마나 웹표준에 대해서 연구하고 지식을 가지고 있는지를 알고 있다. 이 책은 단순한 사용법 이상에 왜 웹표준을 해야하고 웹표준을 하면 어떤 장점이 있고 어떻게 웹표준에 접근해야 하는 지를 설명하고 있는 책이라는 것이 더 맞다고 생각한다. 물론 웹접근성도 포함해서....

직접적은 아니라고 하더라도 웹표준에 역사에 대해서 자세한 설명을 하는 것도 나에겐 상당히 도움이 되었다. 넷스케이프 시절부터 각 버전의 브라우저가 만들때 어떤 문제가 있었는지 어떤 특징이 있었는지 그래서 웹디자이너들이 웹표준에 대한 오해가 어떤식으로 자세하게 설명하고 있기 때문에 뭐가 잘못되었는지 확실하게 이해할 수 있고 어떻게 접근해야 하는 지도 이해하기가 쉬웠다. 단순히 해결방법만 얘기하는 것이 아니라 그 과정까지 설명하기에 이해하기도 쉬웠고 기억하기도 쉬웠다.(한번에 다 외워지는 것은 아니지만...)


대부분의 웹표준 옹호론자들이 그렇듯이(나도 포함해서) 웹표준으로 되지 않는 부분에 대해 극렬히 반대하고 있는데 이 책은 철저하게 웹표준 옹호론자이면서도 전환형이란 방법으로 테이블레이아웃과 CSS의 조합도 권장하고 있다. 과도기적인 상황을 감안해서.... 다른 사람들은 반대할지도 모르겠지만 나는 이런식의 방법으로 접근하는 열린 마인드에 더 흥미로움을 가졌다.(닫혀진 마음가짐의 지식은 왜곡될 우려가 있기 때문에.....) 표준태그 사용법을 제대로 배우려면 다른 책이 더 필요할지도 모르겠지만 약간의 지식이 있다면 이책은 분명히 큰 도움이 될 것이라고 생각한다.(책의 마지막 부분에서도 그렇지만 중요팁을 제외하고는 책에 나온 CSS방법에 의해서 웹디자이너들의 창조적인 CSS 사용을 방해하지 않으려는 의도도 있어보인다.)







우리는 1등을 하기위해 정확한 XHTML을 배우는 것이 아니다. 우리는 오늘, 내일 그리고 10년 후에도 데스크탑 브라우저, 텍스트 브라우저, 스크린리더 등에서 우리가 제작한 사이트가 제대로 작동하기 위해 XHTML을 배우는 것이다.
 

[Book] Ruby on Rails 초고속 웹 개발의 시작..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

Ruby on Rails - 8점
브루스 테이트 외 지음, 김경준 옮김, 박상길 감수/한빛미디어



실제로 얼마냐 쓰이냐라는 논란도 있기는 하지만 그래도 작년에 웹개발에서 가장 큰 이슈중의 하나는 루비온레일즈가 아니었나 싶다. 개발이라는 것이 맘에든다고 개발자 맘대로 언어바꾸고 그러는게 쉽지 않으니까.... 형이랑 루비온레일즈로 프로젝트 하나 해보자 하는 얘기가 나와서 이책을 집어들었다. 처음 루비온 레일즈의 개념을 잡기에는 제일 낫다고 해서.... 아무래도 두께도 얇고 하니... (이책을 붙잡고 몇달씩 있었을 정도로 중간중간 프로젝트 때문에 연속적으로 보지 못했고 현실은 쉽지 않았지만...)



입문서로는 상당히 괜찮은 것 같다. 너무 자세하게 API설명하느라고 지루하게 하지도 않고 말그대로써 입문서로의 역할을 충실히 하면서 루비온레일즈의 특징을 간단히 설명하고 갤러릴 형식의 웹 어플리케이션을 예제로 만들면서 한회전을 돌며 루비온레일즈의 특징이라고 할 수 있는 액티브 레코드, 스캐폴딩, 뷰 다루기, 테스트까지 다 설명하고 있다.

이 책을 다 보고 이제 루비온레일즈로 개발해 보자 하기는 좀 어렵다는 생각은 들지만 아~ 루비온레일즈가 이런거구나. 이렇게 돌아가구나 할 정도로 맛을 볼 정도의 역할을 충분히 한다고 생각한다.


현실적인 것은 실제 먼가를 만들어보고 다양한 현실적 요구사항에 부딪혀 봐야 하겠지만 지루하고 피곤한 데이터베이스 연결작업을 액티브레코드를 통해서 코딩하듯이 다 해결하고 루비온레일즈의 가장 큰 특징중의 하나라고 생각하는 스캐폴딩을 통해 게시판의 기본인 리스트, 등록, 수정, 삭제를 명령어 하나로 다 만들어 낼 수 있다는 것은 분명히 획기적인 부분이라고 생각한다.

다만 책이 그렇게 오래되지는 않았지만 레일즈의 버전이 올라간 것인지 인스턴트루비로 예제소스를 따라할 때 제대로 안되는 부분이 약간 있다. 이런 부분은 책이라는 매체로서는 어쩔수 없으니 여기저기 찾아가면서 하는 수밖에...



덧) 현재 공부하는 것 중에는 우선순위가 최하위이다 보니 일정이 계속 늦쳐지고 있다. 올해내에는 머 하나라도 만들어봐야할텐데.... ㅎ

[JS]팝업 또는 새창에 관한 정리..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

어렵지 않은 거라고 안적어놨더니만 맨날 할때마다 책꺼내봐야하고.... 아놔~

window.open(URL, 윈도우명, 옵션);

이라고 하면 팝업을 띄울 수 있다. 네번재 파라미터도 있는데 네번째 파라미터는 이미 존재하는 창의 이름을 지정할때만 사용하며 브라우저 열어본 페이지 목록에 덮어씌울 것인지 새로 추가할 것인지를 지정한다. 기본값인 false는 새로 추가하는 것이다.

ex) window.open("http://blog.outsider.ne.kr", "" , "width=800,height=600,toolba=no");

dependent   부모의 종속된 윈도우를 연다(부모 닫으면 같이 닫힌다.)(no)
directories   개인북마크 or 링크바를 표시(yes)
height          높이(Min 100px)
width            넓이(Min 100px)
top               팝업의 위쪽 위치
left                팝업의 왼쪽 위치
menubar      메뉴바 표시 여부
toolbar         툴바 표시여부
location       주소표시줄 표시 여부
status          하단 상태표시줄 표시여부
resizable     크기변경 여부
scrollbars    스크롤바 표시 여부(내용이 창보다 클 경우)
modal           모달윈도우를 연다
minimizable  윈도 최소화 버튼 추가


window.open()은 해당 윈도우 객체를 리턴한다. 그러므로 팝업을 열고 팝업창을 제어하려면 객체로 받아서 핸들링 해주면 된다.

var popup = window.open("http://blog.outsider.ne.kr", "" , "width=800,height=600,toolba=no");
popup.moveTo(0,0);

moveTo()    창의 좌측 상단 모서리를 지정된 좌표로 이동
moveBy()    창을 지정된 픽셀 수만큼 상하좌우로 이동
resizeTo()  창의 크기를 절대적인 크기로 조절
resizeBy()  창의 크기를 상대적인 크기로 조절
focus()       창을 활성화한다
blur()          포커를스를 잃게 한다.
close()        창을 닫는다.


자신을 닫을 때는 window.close()나 self.close()를 사용하면 된다. 팝업에서 부모창에 접근하려면 opener를 이용하면 된다. 또한 name프로퍼티를 이용해서 target으로 사용할 수 있다.

popup에 관련해서 몇가지 보안관련 사항들이 있는데 자바스크립트는 자신이 연 창만 다시 닫을수 있고 다른 창을 닫으려면 사용자의 승인이 필요하다. 보이지 않는 팝업을 띄워서 악의적인 사용을 막기 위해서 너무 작은 크기(보통은 100px미만)로 축소할 수 없고 화면밖으로 이동시킬 수 없다.

팝업에 대한 자세한 정보는 모질라의 Dom Reference에 자세히 나와있다.

My Comment..
팝업창은 빈도가 아주 높게 쓰는것은 아니라서.. 쓴다고 해도.. 단순하게..
열어재끼는..?? 정도가 좀 많은편이다.. 머 경우에 따라서 틀리긴 하지만.. 우선 난..
그런 케이스가 많았다.. 지금도 그런 케이스가 좀 많은편이고..

그런데 과거에.. 부모창에서 팝업창을 열고서.. 팝업 제어를 해야되는데..
내가 당췌 멀 알아야지.. 그래서 그 때 당시[2007년 ~ 2008년]에.. 동기한테..
물어봤는데.. 이거 머.. opner 가 어쩌고.. 부모창이 어쩌고.. 이러는데..
알수가 없었다.. 이해 자체도 안되고.. 무엇보다 문제는 찾아보려고 해야되는데..
그 때는 찾을 생각 조차도 않했으니.. 먼 말이 더 필요하랴.. ㅋㅋㅋㅋ..

지금도 원페이지 말고.. 팝업 포함 다른 페이지에서의 제어 또는 연동은..
어렵긴 하다.. 머리가 팽팽.. 안돌아가기도 하고.. 난 이상하게 1차원 넘어가면..
살짝 멍.. 하는듯.. 핵심이 사라져버렸넹.. ㅎㅎ..

과거에 머 그랬었다 이거지.. 그리고 이렇게 정리해둔 햄한테 고맙단 거고.. ㅡ;;ㅡ..

[Talk]그냥 문득.. 생각이..

지금은 09시 02분..
회사에 출근해서.. 차한잔하면서 아웃백 빵[어제가 와이프 생신]을 무것당..

먹다보니.. 갑지가 먼지 모르겠는데..
문득 생각이 들게되는.. 잡 생각이 머리에서 지워지질 않았다..
그래서 그냥 계속 생각하느니..
여기다 글을 남기고서 잊어버리건.. 머 어찌하건.. 그러고서 일 해야것당..
근데 내가 잊을 성격은 아니긴 하지만.. 그래도 우선은 떠들어야.. 풀릴듯한..

원래는 카카오톡에 적었었는뎅.. 블로그라는 것이 있는 이상..
이런 좀 장문의 주절 거림은 이곳에 적는것이 더 좋을 듯 하다..
머 이런 잡솔은 때려치우시고.. 참.. 개발에 대한 내용은 아니라는 점..

우리 나라는 참.. 다른 사람에게 관심이 많다..
과거에는 몰랐지만, 결혼해서 시간이 좀 흐르면서.. 어른도 더 많이 뵙고..
애들도 더 많이 보고, 애기들도 많이 보면서.. 생각이 들더라.. 관심병.. ㅡㅡ..

어릴 때는.. "공부는 잘 하니..??.." [내가 공부 잘하건 말건.. 지가 알아서 머하려고..]
좀 고학년이 되니.. "대학교는 어디 갈거니..??.." [대학교는 내가 알아서 선택한다고..]
대학생이 되니.. "여자친구 있니..??.." [여자 소개나 시켜줬나..있으면, 있다고 지랄함서..]
대학교 4학년 되니.. "취업준비 잘 되니..??.." [가뜩이나 머리 아프고만..취업..취업..]
직장인이 되니.. "회사 괜찮니..??..결혼은 언제 하니..??.." [취업 했음 됬잖아..]
연인이 되니.. "결혼 언제하세요..??.." [내가 애랑 결혼할지 안할지도 모르는데..]
유부남 되니.. "결혼 생활은 행복하세요..??.." [내 행복을 왜 니가 신경쓰냐..]
유부남 된지 좀 오래 되니.. "애는 있니..??.." [내 프라이버시라고..내 애를 왜 니가 신경써..]

언제인가 애 낳으면, "애는 이쁘니..", "애는 공부 잘하니..", "결혼은 언제 한데.."..
"손주는 잘커..",  "손주는 공부 잘해..".. 니미럴..

이 관심병들아.. 언제부터 그렇게 나에게.. 내 인생에.. 관심이 많았었냐..
아효 진짜.. 지들 인생이나 잘 설계하고, 잘 살지 진짜..
이 자리를 빌어서.. 위와 같은 질문을 했던 형과 누님들.. 동생들.. 죄송합니다.. (__)..

위와 같은 상황을 깨닫게 된 이후로 의식을 하게 된다..
조카를 만나도.. 처남을 만나도.. 누군가를 만나도.. 구태여 그 사람의 사생활..
공부.. 취업.. 결혼.. 여자친구.. 남자친구.. 애기.. 등등..

안물어본다.. 걍 보편적인 근황을 물어보거나 일반 얘기를 한다..
왜냐공..??.. 그게 스트레스라는 걸 알기 때문에..
난 상대에게 한 번 물어보는 것이지만, 그 사람은 수십 명에게 똑같은.. 비슷한..
질문들을 받고.. 썩소를 지으면서.. 뻔한 대답을 했을테니까..

이 세상 모든 사람들아.. 기성세대들아.. 혹은 내 세대들아..
상대에게 실례가 되는 질문은 하지 말자.. 그건 진짜 외국 사람들 말처럼..

"My personal business..", "My business.." 라규..

좀 지켜줍시다.. 본인이 같은 말을 들었을 때..
받는 스트레스를 구태여.. 남한테 해주지 맙시다..

Ok..??..