LuceteMango:)

- 보더(border)의 두께(width) 관련속성

• 속성 : border-top-width, border-right-width, border-bottom-width, border-left-width
• 값 : thin, medium, thick, 길이, inherit
• 기본값 : medium
• 적용대상 : 모든 요소

div{ border-top-width: 4px; border-right-width: 2px; border-bottom-width: 4px; border-left-width: 2px; }
값은 공백문자로 구분하여 복수지정 가능하며 지정하는 값에 따라 적용대상이 달라진다.

• 값이 한 개 : '상하좌우'
• 값이 두 개 : '상하' '좌우'
• 값이 세 개 : '상' '좌우' '하'
• 값이 네 개 : '상' '우' '하' '좌'

div{border-width: 4px;} : div{border-width: 4px 4px;} : div{border-width: 4px 4px 4px;} : div{border-width: 4px 4px 4px 4px;} :

- 보더(border)의 스타일(style) 관련속성

• 속성 : border-top-style, border-right-style, border-bottom-style, border-left-style
• 값 : none, hidden, dotted, dashed, solid, double, groove, ridge, inset, outset, inherit
• 기본값 : none
• 적용대상 : 모든 요소

값은 공백문자로 구분하여 복수지정 가능하며 지정하는 값에 따라 적용대상이 달라진다.

• 값이 한 개 : '상하좌우'
• 값이 두 개 : '상하' '좌우'
• 값이 세 개 : '상' '좌우' '하'
• 값이 네 개 : '상' '우' '하' '좌'

div{border-style: solid;} : div{border-style: solid dotted;} : div{border-style: solid dotted solid;} : div{border-style: solid dotted solid dotted; : }

보더(border)의 색(color) 관련속성

• 속성 : border-top-color, border-right-color, border-bottom-color, border-left-color
• 값 : 색, transparent, inherit
• 기본값 : 색상 속성의 값
• 적용대상 : 모든 요소

div{ border-top-color: red; border-right-color: green; border-bottom-color: red; border-left-color: green; }
값은 공백문자로 구분하여 복수지정 가능하며 지정하는 값에 따라 적용대상이 달라진다.

• 값이 한 개 : '상하좌우'
• 값이 두 개 : '상하' '좌우'
• 값이 세 개 : '상' '좌우' '하'
• 값이 네 개 : '상' '우' '하' '좌'

div{border-color: red;} : div{border-color: red green;} : div{border-color: red green red;} : div{border-color: red green red green;} :

- 보더(border)의 일괄지정

사방 보더(border)의 두께,스타일,색 속성의 일괄 지정이 가능하며 복수지정도 가능하고 순서를 따지지 않으며 생략 가능하다.
div{ border-top: 4px dotted green; border-right: 2px solid red; border-bottom: 4px dotted green; border-left: 2px solid red; } : : div{border:4px solid green;} :
보더 관련 속성은 값을 상속하지 않으므로 값을 생략한 때에는 기본값을 지정한 것으로 인식한다.
사방에 모든 보더를 지정한 뒤 좌우의 보더를 개별적으로 설정이 가능하다. 하지만 우선순위 규칙이 적용되서 중첩될경우 나중에 지정한 스타일이 덮어쓰여진다.

 

플러그인 인스톨

Help - Install New Software 클릭

http://download.aptana.com/studio3/plugin/install 입력




Next

Next

이클리스를 재시작





Install Aptana Features


Install Aptna Features 를 클릭




Ajax Libraries - jQuery Support 를 선택 후 Install 버튼을 클릭




Ajax Frameworks - Aptana Support for jQuery 선택 후 Next 버튼을 클릭




Finish 클릭




플러그인 설치 - 이클립스 재시작 후 WIndow - Preferences 클릭




Aptana - Editors - JavaScript - Code Assist 메뉴에서 jQuery를 선택







만약 편집기가 설치 전의 그냥 보통 편집기일 경우 설정에서 변경해줘야 합니다.

오랜만에 모사이트에 가서 글을 보다가...

 

String과 StringBuffer에 대한 논쟁이 한참 불붙은 것을 보았습니다.

 

글쓴 사람들 보니까 좀 안다는 사람들 모여서 열띤 토론을 벌이더군요.

 

 

간단히 생각하면 될 문제를 복잡하게 생각하니 배가 산으로 갑니다.

 

 

String이나 StringBuffer나 뭘쓰면 어떻습니까... 성능문제는 성능에 문제가 될때만 발생하는 겁니다.

 

물론 성능이 좋을 수록 좋겠지만... 필요이상으로 성능에 집착하는 것은 낭비입니다.

 

 

제 의견을 말씀드리겠습니다.

 

String이나 StringBuffer나 모두 문자 배열입니다.(char[])

 

 

배열의 특징을 잘아시겠지만, 한번 생성하면 크기를 늘일 수 없어서 크기를 늘이려면 새로운 배열을 만들어야 합니다.

 

String은 변경할 수 없으니 문자열 결합이 일어날때마다 항상 새로운 배열을 만들고 복사하는 과정을 거칩니다.

 

이과정은 여유있는 크기의 배열(StringBuffer)의 내용을 변경하는 것과는 큰 성능 차이가 있습니다.

 

 

하지만, 너무 여유있는 크기의 배열을 생성하면, 메모리의 낭비가 있겠죠.(StringBuffer의 단점)

 

또한 아무리 StringBuffer라고 해도 크기를 작게 잡아놓으면 String쓰는거나 별다른게 없을 수도 있습니다.

(새로운 크기의 배열을 생성하고 복사해야하므로... 그래도 String보다는 StringBuffer가 낫습니다.)

 

 

그래도... 대부부의 경우, StringBuffer를 사용하는 것이 String을 쓰는 것보다 훨씬 빠릅니다.(문자열 편집에 관한한)

 

일부 경우에서는 String이 StringBuffer보다 빠를 수는 있지만, 대부분의 경우 당연하게도 StringBuffer가 빠를 수

 

밖에 없습니다. 배열의 특징이 그렇기 때문이죠.

 

 

한가지 알아야할 것은 String에 대한 +연산을 컴파일러가 StringBuffer로 자동변환해준다는 것입니다.

 

그러니 항상 StringBuffer대신 String을 써도 별 문제 없다고 하는 사람이 있지만... 컴파일러의 자동변환에도 한계가 있습니다.

 

String에 +연산을 사용하는 모든 경우를 커버할 수는 없다는 얘기죠.

 

 

그래서... 웬만하면 문자열 결합에 String을 그냥 사용해도 된다.(컴파일러가 자동변환해서 최적화 해주니까.)

 

성능상의 문제가 되는 경우에만 StringBuffer를 이용해서 최적화한다.

 

모든 곳에 String대신 StringBuffer를 사용하면 가독성이 떨어지니까...(코드를 읽기 힘들어지니까.)

 

출처 : 남궁성 자바카페