반응형
블로그 이미지
개발자로서 현장에서 일하면서 새로 접하는 기술들이나 알게된 정보 등을 정리하기 위한 블로그입니다. 운 좋게 미국에서 큰 회사들의 프로젝트에서 컬설턴트로 일하고 있어서 새로운 기술들을 접할 기회가 많이 있습니다. 미국의 IT 프로젝트에서 사용되는 툴들에 대해 많은 분들과 정보를 공유하고 싶습니다.
솔웅

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

글 보관함

카테고리

JQuery Mobile - Footers

2012. 7. 24. 05:52 | Posted by 솔웅


반응형

Footer bar structure


footer bar는 data-role attribute 값에footer를 넣는 다는 것 말고는 header와 기본 구조가 같습니다.


<div data-role="footer"> 
	<h4>Footer content</h4> 
</div> 



footer toolbar는 디폴트로 a swatch를 theme으로 사용할 겁니다. 이것은 여러분이 쉽게 set the theme swatch color를 할 수 있습니다.


page footer는 옵션과 configuration 관련해서는 헤더와 아주 유사합니다. 가장 크게 다른 부분은 footer는 헤더보다 그 기능이 적다는 겁니다. 특히 구조와 관련해서요. 그래서 framework는 헤더에 자동적으로 적용했던 왼쪽 오른쪽의 버튼을 위한 slot을 제공하지 않습니다.

footer는 이렇게 헤더처럼 미리 그 구조가 짜여져 있지 않기 때문에 여러분이 원하는 디자인 구조를 적용하시려면 grids layout과 custom style을 사용할 것을 권합니다.


Adding buttons

footer에 링크나 button markup 을 추가하면 둘 다 모두 자동적으로 button으로 표시 됩니다. 공간을 절약하기 위해 툴바에 있는 버튼들은 자동적으로 inline styling로 세팅됩니다. 그러니까 그 버튼은 그 안의 텍스트나 아이콘의 너비 만큼 공간을 차지하게 됩니다.

디폴트로 툴바는 nav bar 나 다른 위젯 공간을 위한 padding을 가지고 있지 않습니다. bar에 padding을 넣으려면 class="ui-bar" 를 footer에 추가해야 합니다.


<div data-role="footer" class="ui-bar">
	<a href="index.html" data-role="button" data-icon="plus">Add</a>
	<a href="index.html" data-role="button" data-icon="arrow-u">Up</a>
	<a href="index.html" data-role="button" data-icon="arrow-d">Down</a>
</div>


이 예제는 좌우로 버튼을 한줄 정렬해서 표시하게 됩니다.

아래 예제 파일 다운 받으셔서 소스도 고치시면서 직접 눈으로 확인하시면 더 이해가 쉽게 갈겁니다.


footer01.html




.ui-bar는 페이지의 full width로 하기 위해 헤더나 footer에 추가하시면 안됩니다. 추가적인 padding은 parent container의 full-width element를 break 할 겁니다. full-width toolbar 안에 padding을 추가하려면 element 안에 툴바의 contents를 감싸고 이 padding을 그 element에 추가하세요.

버튼들을 하나의 그룹으로 묶으려면 wrapper 안에 있는 링크들을 data-role="controlgroup",data-type="horizontal" attributes 와 함께 감싸세요.


<div data-role="controlgroup" data-type="horizontal">


이렇게 하면 버튼 그룹을 만들 수 있습니다. 위 예제 파일을 확인해 보세요.



Adding form elements

Forms elements 와 다른 content들도 또한 toolbar에 add될 수 있습니다. 위 예제 파일에 footer bar 안의 select menu 예제가 있습니다. data-mini="true" attribute를 추가해서 툴바 안에 mini-sized form elements를 사용할 것을 권장합니다.


Fixed & Persistent footers

footer가 global navigation element인 경우 여러분은 화면이 스크롤 될 때 따라 움직이지 않고 제자리에 표시 되도록  fixed 로 display 하기를 원하실 겁니다.  fixed toolbar persistent도 가능합니다. 이런 경우에는 page transitions이 일어나도 그 툴바는 계속 보일 겁니다. 이 기능은 jQuery Mobile에 포함돼 있는 persistent footer feature를 사용함으로서 구현하실 수 있습니다.


화면전환에도 footer를 계속 보이게 하려면 관계된 모든 페이지의 footer에 data-id attribute를 추가하세요. 물론 id 값은 모두 같아야 합니다. 예를 들어 현재페이지와 다음(target) 페이지에 data-id="myfooter"를 추가하면 framework은 page가 바뀌는 동안에도 같은 지점에 footer를 계속 고정시킬것입니다.

이 기능은 header와 footer가 data-position="fixed"로 세팅돼 있을 때에만 제대로 작동할 겁니다. 그렇게 하면 transition 동안에도 계속 보이게 됩니다.

반응형

'jQuery Mobile > JQM Tutorial' 카테고리의 다른 글

JQuery Mobile - Persistence Toolbars  (0) 2012.07.29
JQuery Mobile - Fixed toolbar Methods/Events  (0) 2012.07.29
JQuery Mobile - Fixed toolbar options  (0) 2012.07.29
Fixed toolbars  (0) 2012.07.28
JQuery Mobile - Navbar  (2) 2012.07.25
JQuery Mobile - Header structure  (0) 2012.07.23
JQuery Mobile - Toolbar types  (0) 2012.07.21
JQuery Mobile - Theming Page  (0) 2012.07.12
JQuery Mobile - touchOverflow 기능  (0) 2012.07.09
JQuery Mobile - PhoneGap apps  (1) 2012.07.09

JQuery Mobile - Header structure

2012. 7. 23. 07:54 | Posted by 솔웅


반응형

Header structure


헤더는 대개 페이지 윗부분에 위치하며 페이지 타이틀이 표시되거나 왼쪽이나 오른쪽에 버튼이 있어 이전 이후 페이지로 가도록 하는 기능을 제공하는 툴 바입니다. 헤더는 선택에 따라 fixed로 포지션 될 수 있으며 일러 경우 페이지가 스크롤링 될 때 같이 되지 않고 항상 top 에 위치해 있게 됩니다.


타이틀 글자는 대기 H2 heading element를 사용하지만 H1에서 H6까지 여러분들 선택에 따라 사용하실 수 있습니다. 예를 들어 모바일 페이지에는 여러 페이지들이 있을 수 있고 그 중 home page에는 H1을 그 다음 secondary page에는 H2 element를 사용하실 수 있겠죠. 모든 헤딩 레벨은 시각적인 일관성을 주기 위해 styled 되면 더 좋습니다.


<div data-role="header"> 
	<h1>Page Title</h1> 
</div> 


header01.html

예제들은 위 파일을 받아 보시면 있습니다.

이 블로그에서는 실행이 안되서 따로 파일을 만들었습니다.

이 파일을 실행시키면 아래와 같은 화면을 보실 수 있습니다.

다운 받아서 직접 실행해 보시고 소스도 이것저것 바꿔보세요.


Default header features


헤더 툴바는 디폴트로 a swatch로 theme 돼 있습니다. 하지만 여러분이 원하시면 쉽게 theme swatch color 를 하실 수 있습니다.


예제는 이 글 맨 밑에 있는 첨부파일을 보시면 있습니다.


Adding buttons


표준 헤더 configuration에서 텍스트 헤딩 양쪽에 button들을 위한 slot이 있습니다. 각 버튼들은 anchor element이구요 어떤 button markup이든지 사용하실 수 있습니다. 공간을 절약하기 위해서 툴바에 있는 버튼들은 inline styling로 세팅하세요. 그러면 버튼 크기가 자동적으로 그 버튼안에 있는 텍스트와 아이콘의 크기에 맞게 세팅될 겁니다.


Default button positioning


헤더 플러그인은 헤더 콘테이너의 직속 children이라고 할 수 있습니다. 첫번째 링크는 자동적으로 왼쪽 버튼 slot에 세팅을 하고 두번째 링크는 오른쪽에 세팅합니다. 아래 예제에서 Cancel 버튼은 왼쪽 slot에 나타날 것이고 Save는 오른쪽 slot에 나타날 겁니다.


<div data-role="header" data-position="inline">
	<a href="index.html" data-icon="delete">Cancel</a>
	<h1>Edit Contact</h1>
	<a href="index.html" data-icon="check">Save</a>
</div>


Making buttons visually stand out


Buttons automatically adopt the swatch color of the bar they sit in, so a link in a header bar with the "a" color will also be styled as "a" colored buttons. It's simple to make a button visually stand out. Here, we add the data-theme attribute and set the color swatch for the button to "b" to make the "Save" button pop.


<div data-role="header" data-position="inline">
  <a href="index.html" data-icon="delete">Cancel</a>
  <h1>Edit Contact</h1>
  <a href="index.html" data-icon="check" data-theme="b">Save</a>
</div>

Controlling button position with classes


버튼의 위치는 버튼 anchor에 class를 add 함으로서 콘트롤 될 수 있습니다. (이 경우에는 소스의 순서가 아니라 설정된 클래스에 따라 위치가 정해지겠죠.) 아래 경우에는 1개의 버튼을 오른쪽에 표시하고 싶을 때 사용하실 수 있을 겁니다. 버튼의 위치를 정하시려면 ui-btn-leftui-btn-right 클래스를 anchor에 넣어 주세요.


<div data-role="header" data-position="inline"> 
	<h1>Page Title</h1>
	<a href="index.html" data-icon="gear" class="ui-btn-right">Options</a>
</div>


Adding buttons to toolbars without heading


헤더바 안의 헤딩은 약간의 margin을 가지고 있습니다. 이 마진은 bar의 height을 나타냅니다. 헤딩을 사용하지 않는다면 class="ui-title" 와 함께 element를 추가하셔야 합니다. 그러면 그 바는 hight를 얻어서 정확하게 display 할 수 있을 겁니다.


<div data-role="header" data-position="inline"> 
	<a href="index.html" data-icon="gear" class="ui-btn-right">Options</a>
	<span class="ui-title" />
</div>


Adding Back buttons


jQuery Mobile은 어떤 헤더에건 자동적으로 back 버튼을 생성하고 추가할 수 있는 기능이 있습니다. 디폴트로는 이 기능이 disabled 돼 있습니다. 이 경우는 chromeless installed application들에서 아주 유용합니다. 예를 들어 native app webview에서 작동할 때 등에서요. jQuery Mobile 프레임워크에서는 페이지 플러그인의 addBackBtn 옵션이 true일 경우 헤더에 자동적으로 back버튼을 추가해 줍니다. 이 기능은 또한 페이지 div 에 data-add-back-btn="true" attribute로 세팅되어져 있으면 적용됩니다.



앵커에 data-rel="back" attribute를 사용하면 앵커에 어느곳을 클릭하던지 back button을 누른 효과가 날 겁니다. history entry의 바로 이전 화면으로 돌아가고 anchor's의 디폴트 href는 무시할 겁니다. 이 기능을 사용할 때 실제로 돌아가는 페이지가 어떤 페이지인지를 알려 줄 수 있는 표시를 해 주세요. href를 걸어달라는 겁니다. 그러면 C-Grade 브라우저를 사용하는 유저에게도 불편함 없이 사용할 수 없도록 할 겁니다.


history 내의 back 화면으로 가는 것이 아니라 reverse transition을 하기를 원하신다면 data-direction="reverse" attribute를 사용하시면 됩니다.


Customizing the back button text


back button text를 configure 하고 싶으시면 페이지 element에 data-back-btn-text="previous" attribute 를 사용하시면 됩니다. 아니면 페이지 플러그인 옵션을 통해서 프로그래밍으로 set 하실 수도 있습니다.


$.mobile.page.prototype.options.backBtnText = "previous";


Default back button style


백 버튼에 role-theme을 설정하고 싶으시면 아래와 같이 하면 됩니다.


$.mobile.page.prototype.options.backBtnTheme = "a";


이 기능을 프로그래밍적으로 하시려면 이 옵션을 mobileinit 이벤트 핸들러에 넣어 주세요.


Custom header configurations


디폴트 세팅이 아닌 헤더를 만들고 싶으면 그냥 콘테이너에 custom styled markup을 씌우시기만 하시면 됩니다. div 같은 걸로요. 플러그인은 헤더 콘테이너 안의 wrapped 콘테이너에 자동 버튼 로직을 적용하지 않을 겁니다. 그러니까 여러분은 여러분 나름대로의 스타일을 넣으실 수 있습니다.


헤더 data-role을 사용하지 않고도 custom bar를 만들 수 있습니다. 예를 들어 ui-bar를 추가해서 스탠다드 바에 apply 하고 ui-bar-b 클래스를 추가해서 여러분의 theme에서 bar swatch styles를 assign 하시면 됩니다.


<div class="ui-bar ui-bar-b">
    <h3>I'm just a div with bar classes and a
       <a href="#" data-role="button">Button</a></h3>
</div>


ui-bar 는 페이지의 full width로 된 헤더나 footer bar에는 추가하지 말아야 합니다. 이렇게 하면 parent container의 full-width element 세팅을 bread out 할 겁니다. full-width 툴바 안에 패딩을 추가하려면 element 안에 툴바의 content를 wrap 하시고 element 대신 padding을 apply 하세요.

하지만 간단하게 style을 적용함으로서 예제 파일의 마지막 바와 같은 메세지 바를 쉽게 만들 수도 있습니다.




반응형

'jQuery Mobile > JQM Tutorial' 카테고리의 다른 글

JQuery Mobile - Fixed toolbar Methods/Events  (0) 2012.07.29
JQuery Mobile - Fixed toolbar options  (0) 2012.07.29
Fixed toolbars  (0) 2012.07.28
JQuery Mobile - Navbar  (2) 2012.07.25
JQuery Mobile - Footers  (0) 2012.07.24
JQuery Mobile - Toolbar types  (0) 2012.07.21
JQuery Mobile - Theming Page  (0) 2012.07.12
JQuery Mobile - touchOverflow 기능  (0) 2012.07.09
JQuery Mobile - PhoneGap apps  (1) 2012.07.09
JQuery Mobile - Scripting pages  (1) 2012.07.05


반응형

요즘은 고국의 소식을 Podcast 를 통해 많이 접합니다.


가끔 이상호 기자의 발뉴스를 보다 보면 뭔가 큰 권력 앞에서 보복을 두려워하면서도 진실을 지키고자하는 언론인의 모습이 너무 안되 보입니다.


그리고 그렇게 어렵게 수십년간 많은 이들의 희생을 댓가로 민주화 운동을 해서 얻은 자유와 권리가 정권이 바뀌었다고 해서 이렇게 쉽게 이렇게도 금방 무너지는 모습에 너무 마음 아프기도 하구요.


그리고 많은 분들의 희생이 다시 헛되이 사라지지 않도록 하기 위해서라도 그리고 내가 제대로 자유를 누리며 살기 위해서라도 어떤 식으로라도 나도 참여해야겠다는 생각을 합니다.


제가 발벗고 나서지는 못하지만 최소한, 용기를 갖고 앞에 나서는 사람들에게 저도 뜻을 같이하고 있고 같이 옆에 있다는 메세지라도 전하고 싶습니다.



그리고......


오지랖일까요?




아루나찰 프라데시(Arunachal Pradesh)라는 곳이 있습니다.

부탄과 티벳과 중국과 미얀마와 국경을 접하고 있는 히말라야 산속에 있는 고장입니다.

현재 인도의 한 주에 속해 있습니다.


이곳에서도 한국에서와 같은 아니 우리가 이전의 독재시대에나 경험했을 법한 무지막지한 언론과 인권탄압이 일어나고 있습니다.


2012년 7월 15일 백주 대낮에 한 언론인이 등 뒤에서 총을 맞았습니다.



(해석:당신들은 단지 등 뒤에서 여자를 쏜 것만이 아니다 아루나찰인들의 자유와 평화를 죽인것이다.)


그리고 그동안 침묵을 강요당했던 사람들이 목소리를 높였습니다.



저는 이 곳의 정치상황을 자세히는 모릅니다.

단지 예전에 몇년간 인도에 있었을 때 알았던 친구가 페북 친구가 됐고 그 친구가 페북에 올린 몇개의 글을 읽은게 전부 입니다.


어떤 정치적인 이유에서건 백주 대낮에 언론인이 등뒤에서 쏜 총에 저격당하는 이런일은 일어나서는 안 되는 겁니다.

어떤 이유에서 행했던지 그건 비판 받아야 할 일입니다.


그 글을 읽고 한국에서도 불의의 큰 권력에 맞서 싸우는 우리의 언론인들이 생각났습니다.

남의 일 갖지가 않았습니다.


그래서 제가 할 수 있는 최소한의 도움을 주고 싶었습니다.

이 백주대낮의 언론인 테러를 규탄한다는 온라인 서명이 있어서 거기 가서 투표(사인)을 했습니다.



여러 인도인 중에 한명의 한국인이 있지만 이 문제는 인도의 문제, 아루나찰 프라데시만의 문제가 아닌 정의의 문제라고 생각합니다.

저는 일부러 이런 일들을 찾아다니면서 세계의 정의를 위해 뛸 열정도 없고 그럴 의지도 없는 사람입니다.

어떤 인연이 작용해서 저에게 이런 소식이 들렸고 제가 동참할 수 있는 방법이 주어졌기에 그냥 한 겁니다.


그리고 여러분도 마음이 이끌리시면 같이 참여해 주세요.



여기로 가시면 온라인 서명을 받는 곳이 나옵니다.


저기 First Time Here 밑에 이름과 이메일과 나라와 우편번호를 넣으신 후 SIGN 버튼을 누르시면 됩니다.

실력은 안 되지만 저 위에 써 있는 문구를 해석해 봤습니다.


To bring justice to Miss Tongam Rina who was shot by an unidentified person near her office premise in broad day light on 15th July 2012.And to pressurize the Govt. of Arunachal to nab the culprit at earliest and to constitute the SIT(Special Investigation Team) or to Hand over the case to C.B.I for fast and fair investigation. Rina deserve Justice and we deserve to know the truth behind such heinous crime .

2012년 7월 15일 백주 대낮에 사무실 근처에서 신원불명의 사람에게 저격을 당한 Tongal Rina 에 대한 정의를 가져오기 위해. 그리고 아루나찰 주정부에게 특별수사본부를 구성하고 범인을 하루속히 잡도록 촉구하기 위해. 아니면 빨리 C.B.I 에게 이 사건을 인계해서 공정한 수사가 이루어지도록 하기위해 이 서명을 합니다. 우리는 이러한 극악무도한 범행 뒤에 있는 진실을 알 권리가 있습니다.


우리가 지난 4년간 경험했듯이 암만 민주주의를 얻었어도 이를 지켜보고 있지 않으면 잠시 한눈을 팔면 누군가가 이 민주주의를 이렇게 쉽게 짓밟게 됩니다.


그리고 이 민주주의는 그리고 정의는 거게에 속한 사람들만의 문제가 아닙니다.

우리가 관심을 가져주지 않으면 옆에 있는 정의는 죽을 것입니다.

그러면 우리에게도 그 정의는 오지 않을겁니다.


제 친구의 페북에 있는 글을 하나 전해 드릴께요.


Why this is important


For the past few years the Media House in Arunachal Pradesh has been under attack from miscreants. Every time the State Govt. used to give an assurance to nab the culprit and book under the law but still nothing concrete has been done by Govt. in this regards, this lack side attitude of Govt. encourage the unknown miscreant to shot Miss Tongam Rina an associate editor with local media house "Arunachal Times" on fateful day of 15th July 2012 near her office premise in broad day light. The reason behind attack is unknown and the truth will resurface only when the culprit gets arrest. The moot question is When Govt. fails to ensure the security of media persons and media house in spite of several attacks and threat calls from miscreants. It's make us wonder are we really safe in such environment? shall we raise our voice now or shall we wait for another blood shed to happen.Enough is Enough!! I cant remain silent anymore, are you going to remain silent? Today its Tongam Rina tomorrow it might be you. In past we were silent it doesn't mean we are dumb.let's make our voice to heard,lets make Govt. feel our sentiment, lets act today for better tomorrow. Justice to Rina is justice to us!!!!!!!!!!!!!!

왜 이것이 중요할까요

지난 수년간 아루나찰 프라데시에 있는 미디어 하우스는 나쁜놈들한테 공격당해 왔습니다. 주정부는 매번 범인을 붙잡겠다고 하지만 실제로 아무 일도 하지 않고 있습니다. 주정부가 이렇게 방치하는 바람에 이 범인은 Arunachal Times 라는 지역 언론사의 부주필인 Tongam Rina 를 2012년 7월 15일 백주대낮에 그녀의 사무실 근처에서 등 뒤에서 저격하는데에까지 이르렀습니다. 등 뒤에서 왜 공격했는지는 아직 알려지지 않았습니다. 진실은 그 범인을 잡은 이후에나 알 수 있을 겁니다. 주정부에 묻고 싶은것은 범인이 수차례 협박 전화를 걸었고 여러번 이 언론사와 그 안의 언론인들을 공격했음에도 불구하고 어떻게 이 언론인과 언론사에 대한 보안을 유지하지 못했느냐는 겁니다. 우리는 진정 안전한 곳에 사는지에 대해 의문을 가질 수 밖에 없습니다. 우리는 지금 목소리를 높여야 할까요 아니면 다른 희생이 나오도록 침묵을 지켜야 할까요. 이제 충분합니다. 이제 저는 더 이상 침묵을 지킬 수가 없습니다. 여러분은 침묵의 편에 서시겠습니까? 오늘은 Tongam Rina 이지만 내일은 바로 당신 일 수 있습니다. 지금까지 우리는 침묵을 지켜왔지만 벙어리는 아닙니다. 저들에게 들리도록 우리의 목소리를 냅시다. 주정부에게 우리의 주장을 확실히 알립니다. 좀 더 나은 내일을 위하여 오늘 행동에 나섭시다. Rina에 대한 정의는 곧 우리에게 올 정의 입니다. !!!!!!!!!


다시 한번 링크를 걸겠습니다. 동참하고 싶으시면 여기로 가셔서 온라인 서명을 해 주시면 됩니다. (밑에 페북 트위터 count도 올려 주세요.)

반응형

JQuery Mobile - Toolbar types

2012. 7. 21. 01:58 | Posted by 솔웅


반응형


이제 jQuery Mobile Tutorial 의 Component 부분 Page & dialog 를 끝마치고 두번째 주제인 Toolbars 로 들어갑니다.


생각보다 시간이 많이 걸리네요. 어쨌든 조금씩 조금씩 공부해 나가다 보면 조만근 끝까지 돌파 하겠죠?

오늘은 Toolbars 의 첫 시간입니다.



Toolbar types


jQuery Mobile에는 두가지 표준 툴바 종류가 있습니다. : Headers and Footers.

  • Header bar는 페이지 title로 사용됩니다. 대부분의 경우 각 mobile page내의 첫번째 엘리먼트가 되죠. 특히 페이지 title이 포함되고 또 두 개의 버튼까지 포함할 수 있습니다.
  • Footer bar는 대개 각 모바일 페이지의 마지막 element 입니다. 그리고 그 내용과 기능면에서 header 보다 더 자유로운 경향이 있죠. 여기에는 text와 버튼들의 조합이 들어가게 됩니다.


header나 footer 안에는 대개 horizontal navigation이나 tab bar 가 들어가는 것이 일반적입니다. jQuery Mobile에는 이런 경우 hirizontal button bar 안에 들어가는 링크들의 리스트 보여줄 수 있는 navbar widget 를 제공하고 있습니다.

이 툴바들에 추가 할 수 있는 attribute들을 모두 보려면 data- attribute reference를 참조하세요.



Toolbar positioning options


header와 footer들은 여러 방법으로 페이지에 위치 지워질 수 있습니다. 디폴트로 툴바들은 inline 포지셔닝 모드를 사용합니다. 이 모드에서는 헤더와 푸터들이 일반적인 문서 flow(default HTML behavior)에 맞게 자리 잡습니다. 이 경우는 JavaScript와 CSS 포지셔닝 지원 여부에 관계 없이 모든 device들에서 작동을 합니다. (visible)


"fixed" positioning mode 는 툴바들을 CSS fixed positioning 을 지원하는 브라우저의 viewport 안에 있는 top 이나 bottom에 툴바들을 위치시킵니다. CSS fixed positioning은 대부분의 데스크탑 브라우저와 iOS5+, 안드로이드 2.2+, 블랙베리 6 등에서 지원합니다. 이 기능을 지원하지 않는 브라우저들에서는 이 툴바들은 페이지내의 inline position으로 지정이 될 겁니다.


tap-togglingl이 가능하면 스크린을 tapping 하면 fixed toolbar의 visibility가 toggle 될 겁니다. 툴바가 보이지 않을 때 페이지를 tap하면 보이게 될 겁니다. 다시한번 tap 하면 사라지구요. 이 기능은 유저에게 필요하기 전에는 툴바를 보이지 않음으로서 컨텐츠가 좀 더 넓은 화면에서 표시될 수 있게 해 줍니다. 기억해 두셔야 될 것은 fixed toolbar는 실제로는 hide 된게 아니라는 겁니다. fixed와 static positioning 사이에서 왔다 갔다 하는 겁니다. 이 의미는 만약 여러분이 페이지 top 에 있다면 그 헤더 툴바를 안 보이도록 tap-toggle 할 수 없다는겁니다. 문서의 아주 밑으로 scroll 됐을 경우 fixed footer에도 이러한 경우는 마찬가지로 적용됩니다.


이 기능을 헤더와 풋터에 세팅하려면 data-position="fixed" attribute를 헤더나 풋터 element에 추가하세요.


"fullscreen" position mode는  fixed mode가 아닐 때 문서의 한 지점을 점유툴바가 페이지 콘텐츠를 덮는것을 제외하고는 fixed mode와 같습니다. 이 기능은 컨텐츠가 전체 스크린을 차지하고 툴바는 숨고 스크린을 탭 했을 때만 나타나도록 하는 포토나 비디오 뷰어 같은 immersive app일 경우에 아주 유용할 겁니다. 이 경우의 툴바들은 페이지 콘텐츠의 위에 자리잡을 것입니다. 그러니까 특정 상황에서 유용하게 사용될 수 있고 어떤 상황에서는 그렇지 않을 수도 있습니다.



반응형

'jQuery Mobile > JQM Tutorial' 카테고리의 다른 글

JQuery Mobile - Fixed toolbar options  (0) 2012.07.29
Fixed toolbars  (0) 2012.07.28
JQuery Mobile - Navbar  (2) 2012.07.25
JQuery Mobile - Footers  (0) 2012.07.24
JQuery Mobile - Header structure  (0) 2012.07.23
JQuery Mobile - Theming Page  (0) 2012.07.12
JQuery Mobile - touchOverflow 기능  (0) 2012.07.09
JQuery Mobile - PhoneGap apps  (1) 2012.07.09
JQuery Mobile - Scripting pages  (1) 2012.07.05
JQuery Mobile - Dynamically Injecting Pages  (0) 2012.06.28


반응형
Posted on . Written by


요즘 점점 관심을 모으고 있는 것 중에 "놓고 간 곳에서 pick up" 하는 기능이나 멈추고 다시 시작하는 과정에서 매끄럽게 동작이 이뤄지는 것이 있습니다. 점점 앱이 이전에 stop 했던 곳에서 다시 시작하는 기능이 많아 졌습니다.

유저가 마지막에 있었던 곳에서 다시 앱을 시작하도록 하는것은 state saving 로 불리기도 하고 이 주제가 오늘 제가 다룰 주제입니다. 이곳에 포스트된 튜토리얼들은 여러분이 앱을 개발하면서 필요로 하는 부분에 대해 어떻게 해야 하는지를 알려주는 튜토리얼이 되도록 구성하고 있습니다.





Resuming Suspended Apps


디폴트로 앱이 suspended 됐을 때 (예를 들어 유저가 폰의 홈버튼을 눌렀을 때 등) 여러분 앱은 실제로 중지된것이 아닙니다. 그 앱은 suspended state로 됩니다. 그리고 유저가 간 곳에서 떠날 때 (left off) 그 앱은 다시 실행됩니다. 이렇게 suspended 상태에서 앱이 끝나는 경우는 너무 많은 앱을 띄워서 메모리가 부족할 때 device의 operating system이 suspended 상태의 앱을 quit 시킬 때 입니다.

이런 default로 설정된 상황을 바꾸려면 iOS 앱의 경우는 build.settings에서 UIApplicationExitsOnSuspend 를 true로 놓으면 됩니다. 디폴트는 fault 인데요. 그 의미는 이 앱이 left off 상황일 때 자동적으로 재시작 되도록 한다는 의미입니다. (OS가 이 앱을 quit 하는 경우는 해당이 안 되겠죠.)


iphone = {
  plist = {
    UIApplicationExitsOnSuspend = true
  }
}


대부분 유저는 본인의 의지로 앱을 떠납니다. 하지만 가끔 그렇지 않을 때도 있습니다. (전화가 걸려 온다던지 하는 경우) 그래서 그런 경우 user's experience를 깨지 않도록 재시작(resume) 상황에서 뭔가를 작동하도록 만드는 것은 개발자의 판단에 달려있습니다. 이 상황에 딱 맞는 예는 게임하는 상황입니다.
예를 들어 두들 점프 (Doodle Jump)를 하고 있는 중간에 앱을 닫았고 나중에 다시 돌아올 때 이 게임을 pause screen으로 할 수 있습니다. 만약 전화통화가 끝났는데 바로 character가 점프 해 있는 상황이 된다면 그 판은 여러분의 high score를 깨기 힘든 상황이 될 겁니다. pause screen으로 재시작하는 것은 user-experience 관점에서 훨씬 좋은 흐름일 것입니다.

다행히도 코로나 (Corona)는 여러분의 앱이 suspend 됐거나 resume 될 때 system events를 사용할 수 있도록 합니다. 아래에 앱이 suspend 됐을 때 어떻게 게임을 pause 시키는지를 보여주는 예제가 있습니다.


local function onSystemEvent( event )
    if (event.type == "applicationSuspend") then
        pause_game()
    end
end
Runtime:addEventListener( "system", onSystemEvent )


pause_game() 함수가 무슨일을 하는지는 여러분이 구현하기 나름이지만 대략 어떤 일을 해야 될지는 알겠죠? 일단 global Runtime객체에 리스너를 추가했습니다. 그리고 이 이벤트가 call 됐을 때 실행 될 특정 함수를 지정했습니다.

그 함수안에서는 event.type 이 "applicationSuspend" 인 것을 체크해서 그럴 경우 실행할 함수를 명시했습니다.


Resuming from a “cold” start


지금 다룰 시나리오는 조금 어렵습니다. 여러분 앱이 cold로 시작 됐을 때 (예를 들어 suspended가 아니라 closed나 quit 상태에서 시작됐을 때) 디폴트 behavior는 처음 (main.lua) 부터 새로 시작하는 것일 겁니다.

첫번째로 하셔야 될 일은 현재 상태를 save 하셔야 되는 겁니다. 어떤 방법으로 저장할지는 여러분 마음이지만 table 형태로 데이터를 저장하고 이것을 JSON 스트링으로 converting 하고 file로 저장한 다음에 나중에 로드하시기를 권고 드립니다. (이런 경우 코로나에서 file 읽고 쓰기 부분을 참조하세요.)

다음으로 파일을 파일을 로드하고 앱에게 시작됐을 때 이 데이터를 근거로 어떤 일을 하라고 알려 주어야 합니다. 이럴 경우 suspended 상태이건 cold 상태이건 앱이 새로 시작할 때 이전 상황과 이어지는 상황에서 앱을 다시 시작할 수 있을 겁니다.

데이터를 저장하는 시기는 조금 전에 셋업한 시스템 이벤트 리스너에서 event.type이 applicationExit 일 경우를 체크해서 수행하시면 도비니다. 그리고 나서 event.type이 applicationOpen일 경우 저장해 뒀던 데이터를 로드하고 그것을 근거로 어떤 일들을 수행하면 됩니다.


local function onSystemEvent( event )
    if (event.type == "applicationExit") then

        save_state()    

    elseif (event.type == "applicationOpen") then

        load_saved_state()

    elseif (event.type == "applicationSuspend") then

        pause_game()

    end
end
Runtime:addEventListener( "system", onSystemEvent )


예제를 보니 그렇게 복잡해 보이지 않죠?

save_state()나 load_saved_state() 함수와 관련해서는 더이상 자세한 내용을 언급하지는 않겠ㅅ브니다. 왜냐하면 이것은 앱마다 다 다를 테니까요. 적어도 특히 게임에서는 객체들이 화면상에 있는 정보인 프로퍼티들과 위치들 같은 데이터들을 저장해야 할 겁니다. (그래야지 load_saved_state() 함수에서 그 객체들을 이전에 있던 위치에 display 할 수 있으니까요.)

유저들은 마음대로 그 앱을 열었다 닫았다 할 겁니다. 그리고 그러한 상황에서 유저들에게 자연스러운 앱의 진행상황을 제공하려면 여러분은 그 앱이 suspended나 cold state에서 다시 재시작할 때 유저들이 아무런 끊김없는 혹은 뭔가 당황스러운 상황이 없는 화면 전개를 보여주는데 신경을 쓰셔야 될겁니다.

반응형


반응형

지금 회사에서 사용하고 있는 Kurogo 가 PHP 로 돼 있거든요.


그래서 그 시스템을 커스터마이징을 하려면 PHP 코딩을 해야되서...

거의 10여년만에 PHP를 다시 보고 있습니다.


중간 중간 기억하고 싶은 팁들이 생기면 여기다 저장해 놓으려구요.


일단 지금은 원격 서버의 이미지 파일을 저희 팀 웹페이지에 display 하는 로직을 만들고 있는데요.


우선 그 이미지가 있는지 없는지부터 확인해서 있으면 표시하고 없으면 다른 메세지나 디폴트 이미지를 하기로 했습니다.


이미지 파일이 있는지 없는지를 확인할 수 있는 방법으로는 첫번째로 이미지의 크기를 구하는 함수를 사용할 수 있습니다.


//// check Image size       
        function checkIMG($IMGPath) {
            $fileCheck = getImagesize($IMGPath);
            if($fileCheck) { $isExist = "OK"; } else { $isExist = "NO"; }
            return $isExist;
        }


함수에 원격 이미지 파일의 경로와 파일이름을 담은 $IMGPath 를 넘겨주면 됩니다.





두번째로는 이미지이외에도 다른 경우에도 사용할 수 있는 건데요. 헤더 정보를 얻는 겁니다.

//// get header info
        function checkHeader($filePath) {
            $AgetHeaders = get_headers($filePath);
            if(!$AgetHeaders) {
                echo "Network Problem. Too slow or No Network.<p>";
                $isExist = "Net";
            } else {
                if (preg_match("|200|", $AgetHeaders[0])) {
                        // file exists
                    $isExiset = "OK";
                } else {
                        // file doesn't exists
                    $isExiset = "NO";
                }
            }
            return $isExiset;
        }


여기선 중간에 살짝 정보를 얻어오지 못할 경우 Network 문제가 있다고 뿌려주는 로직도 있습니다.


그 다음으로는 cURL을 사용하는 건데 이건 정확히 get_headers()와 뭐가 다른지 모르겠네요.

cURL로는 파라미터 정보를 넘길수도 있다고 하는데...

하여간 사용법은 아래와 같습니다.


////////
        function curl1($filePath) {
            $curl = curl_init();
            curl_setopt_array( $curl, array(
                CURLOPT_RETURNTRANSFER => true,
                CURLOPT_URL => $filePath ) );
            curl_exec( $curl );
            $response_code = curl_getinfo( $curl, CURLINFO_HTTP_CODE );
            curl_close( $curl );
            return $response_code;
        }       
       
        function curl2($filePath){
            //To get the whole header you can issue a HEAD request, like this:

            $curl = curl_init();
            curl_setopt_array( $curl, array(
                CURLOPT_HEADER => true,
                CURLOPT_NOBODY => true,
                CURLOPT_RETURNTRANSFER => true,
                CURLOPT_URL => $filePath ) );
            $headers = explode( "\n", curl_exec( $curl ) );
            curl_close( $curl );
           
            return $headers[0];
        }


그런데 위 4가지 방법 모두 다 문제가 있었습니다.

왜냐하면 회사 서버에 Proxy 가 있는데 이걸 통해서는 아무 값도 못 받아오더라구요.


회사 내부 서버끼리 테스트 할 때는 잘 됐는데 회사 네트워크 밖에 있는 이미지(파일)을 가지고 하려니까 안되더라구요.


이럴 경우 Proxy 를 거쳐서 정보를 가져오도록 해야 되는데요.

stream_context_create() 함수와 file_get_contents() 함수를 사용했습니다.


/////// get contents via proxy               
        function getViaProxy($filePath){
                                // Define a context for HTTP.
                    $aContext = array(
                        'http' => array(
                        'proxy' => '프락시 정보', // This needs to be the server and the port of the NTLM Authentication Proxy Server.
                        'request_fulluri' => True,
                    ),
                    );
                    $cxContext = stream_context_create($aContext);

                    // Now all file stream functions can use this context.
                    $sFile = file_get_contents($filePath, False, $cxContext);
                    if($sFile){
                        $result = "Y";
                    }else{   
                        $result = "N";
                    }
                    return $result;
        }


이렇게 해서 어렵게 어렵게 문제를 해결했습니다.


반응형


반응형

인터넷 서핑을 하다가 기사를 읽게 됐어요.

한국 교육과정 평가원에서 교과서에 실린 신영복 선생의 약력이 너무 길다고 줄이라고 했다죠? -> 여기

보니까 별로 길지도 않더만...

기사보니까 다른 사람들 약력과 비슷하다고 그러고...


얼마전엔 도종환 시인의 시를 교과서에서 빼려고 하더니만...


MB 정권은 하는 꼬라지가 너무 유치하군요.


신영복 선생의 책은 내가 대학 다닐 때 나온 '감옥으로부터의 사색'이나 '나무야 나무야' 정도만 알고 있어요.

그것도 읽은건 아니고 그냥 서점가서 띄엄띄엄 눈에 띄는 부분만 읽었었죠.

(그땐 서점가서 잠깐 쉬면서 몇장 읽고 덮어버린 책들이 참 많았어요.)


오늘 이 기사 덕분에 교과서에 실린 신영복 선생의 '어리석은 자의 우직함이 세상을 조금씩 바꿔 갑니다.'를 읽을 수 있었습니다. (이 글이 있는지도 몰랐거든요.)


잠시 잔잔한 감동과 삶에 대한 성찰을 느낄 수 있어서 좋았어요.


이 글을 복사해 넣고 기회 되면 때때로 읽고 되새겨야 겠어요.





어리석은 자의 우직함이 세상을 조금씩 바꿔 갑니다.  


오늘은 충청북도 단양군 영춘면에 있는 온달 산성에서 엽서를 띄웁니다.

이 곳 온달 산성은 둘레가 683미터에 불과한 작은 산성입니다. 그러나 이 산성은 사면이 깎아지른 산봉우리를 테를 메우듯 두르고 있어서, 멀리서 바라보면 흡사 머리에 수건을 동여맨 투사와 같습니다. 결연한 의지가 풍겨 오는 책성(柵城)입니다. 그래서 쉽게 접근을 허락하지 않는 성이었습니다. 다만, 마을 쪽으로 앞섶을 조심스레 열어 산성에 이르는 길을 내주고 있었습니다. 산 중턱에 이르면 사모정(思慕亭)이라는 작은 정자가 있었습니다. 전사한 온달 장군의 관이 땅에서 떨어지지 않자, 평강 공주가 달려와 눈물로 달래어 모셔 간 자리라고 전해지고 있습니다. 이 산성을 찾아오는 사람들이 평강 공주를 만나는 자리입니다. 나는 사모정에서 나머지 산성까지의 길을 평강 공주와 함께 올라갔습니다.

아래로는 남한강을 배수의 진으로 하고, 멀리 소백 산맥을 호시(虎視)하고 있는 온달 산성은 유사시에 백성을 보호해 주는 성이 아니라, 신라에 빼앗긴 땅을 회복하기 위한 전초 기지였음을 단번에 알 수 있습니다. 망루가 없어도 적병의 움직임이 한눈에 내려다보였습니다. 조령과 죽령 서쪽 땅을 되찾기 전에는 다시 고국에 돌아오지 않겠다고 한 온달의 결의가 지금도 느껴집니다. 나는 소백 산맥을 바라보다 문득 신라의 삼국 통일을 못마땅해하던 당신의 말이 생각났습니다. 하나가 되는 것은 더 커지는 것이라는 당신의 말을 생각하면, 대동강 이북의 땅을 당나라에 내주기로 하고 이룩한 통일은 더 작아진 것이라는 점에서, 통일이 아니라 광활한 요동 벌판의 상실에 불과한 것인지도 모릅니다. 이러한 상실감은 온달과 평강 공주의 애절한 사랑의 이야기와 더불어 이 산성을 찾은 나를 매우 씁쓸하게 합니다.

온달과 평강 공주의 이야기는, 당시의 사회적, 경제적 변화의 과정에서 부유해진 평민 계층이 신분 상승을 할 수 있었던 사회 변동기였다는 사료(史料)로 거론되기도 합니다. 그리고 ‘바보 온달’이라는 별명도 사실은 온달의 미천한 출신에 대한 지배 계층의 경멸과 경계심이 만들어 낸 이름이라고 분석되기도 합니다.

나는 수많은 사람이 오랜 세월에 걸쳐서 함께 만들어 전해 온 온달 장군과 평강 공주의 이야기를 믿습니다. 이 이야기는 다른 어떠한 실증적 사실(史實)보다도 당시의 정서를 더 정확하게 담아 내고 있다고 생각하기 때문입니다. 그리고 완고한 신분의 벽을 뛰어넘어 미천한 출신의 바보 온달을 선택한 평강 공주의 결단과, 드디어 용맹한 장수로 일어서게 한 평강 공주의 주체적 삶에는 민중의 소망과 언어가 담겨 있다고 생각하기 때문입니다. 이것이 바로 온달 설화가 당대 사회의 이념에 매몰된 한 농촌 청년의 이야기로 끝나지 않는 까닭이라고 생각합니다. 인간의 가장 위대한 가능성은 이처럼 과거를 뛰어넘고, 사회의 벽을 뛰어넘고, 드디어 자기를 뛰어넘는 비약에 있습니다.

나는 평강 공주와 함께 온달 산성을 걷는 동안 내내 ‘능력 있고 편하게 해 줄 사람’을 찾는 당신이 생각났습니다.

‘신데렐라의 꿈’을 버리지 못하고 있는 당신이 안타까웠습니다. 
현대 사회에서 평가되는 능력이란 인간적 품성이 도외시된 ‘경제적 능력’입니다. 그것은 다른 사람들의 낙오와 좌절 이후에 얻을 수 있는 것으로, 한 마디로 말해 숨겨진 칼처럼 매우 비정한 것입니다. 그러한 능력의 품 속에 안주하려는 우리의 소망이 과연 어떤 실상을 가지는 것인지 고민해야 할 것입니다.

당신은 기억할 것입니다. 세상 사람을 현명한 사람과 어리석은 사람으로 분류할 수 있다고 당신이 먼저 말했습니다. 현명한 사람은 자기를 세상에 잘 맞추는 사람인 반면에, 어리석은 사람은 그야말로 어리석게도 세상을 자기에게 맞추려고 하는 사람이라고 했습니다.
그러나 역설적이게도 세상은 이런 어리석은 사람들의 우직함 때문에 조금씩 더 나은 것으로 변화해 간다는 사실을 잊지 말아야 한다고 생각합니다. 우직한 어리석음, 그것이 곧 지혜와 현명함의 바탕이고 내용입니다.

‘편안함’, 그것도 경계해야 할 대상이기는 마찬가지입니다. 편안함은 흐르지 않는 강물이기 때문입니다. ‘불편함’은 흐르는 강물입니다. 흐르는 강물은 수많은 소리와 풍경을 그 속에 담고 있는 추억의 물이며, 어딘가를 희망하는 잠들지 않는 물입니다.

당신은 평강 공주와 삶이 남편의 입신(立身)이라는 가부장적 한계를 뛰어넘지 못한 것이라고 하였습니다만, 산다는 것은 살리는 것입니다. 살림(生)입니다. 그리고 당신은 자신이 공주가 아니기 때문에 평강 공주가 될 수 없다고 하지만, 살림이란 ‘뜻의 살림’입니다. 세속적 성취와는 상관 없는 것이기도 합니다. 그런 점에서, 나는 평강 공주의 이야기는 한 여인의 사랑의 메시지가 아니라, 그것을 뛰어넘은 ‘삶의 메시지’라고 생각합니다. 

나는 당신의 언젠가 산성에 오기를 바랍니다. 남한강 푸른 물굽이가 천 년 세월을 변함없이 감돌아 흐르는 이 산성에서 평강 공주와 만나기를 바랍니다.


반응형


반응형

How do I unset the clean URLs?

Last updated March 18, 2011. Created by dman on February 2, 2004.
Edited by mr.baileys, jonhattan, jwuk, greggles. Log in to edit this page.


clean URLs를 하지 않고 두루팔을 옮긴 경우가 발생할 수 있습니다. 그러면 모든 링크는 제대로 작동하지 않을 겁니다. 왜냐하면 이미 생성된 path는 hosting platform에 의해 지원되지 않기 때문이죠.


This occasionally happens아래의 경우도 발생할 수 있습니다.

  • 호스트 간 데이터베이스를 transfer 한 이후
  • local copy를 한 이후
  • 백업에서 restoring 한 이후 (.htaccess 가 없을 경우)
  • .htaccess 가 지워진 경우
  • 혹은 여러분 호스트에서 원하지 않은 security change가 있는 경우


문제는 여러분은 세팅을 할 수 없게 됐다는 겁니다. 왜냐하면 configuration page를 더이상 링크해서 들어갈 수 없기 때문이죠.

드루팔 (Drupal)은 여러분이 해당 링크에 접근하도록 하기 전에 먼저 clean URLs 가 지원되는지 부터 체크 하고 계속 작업이 이루어 질 수 있는지 여부를 체크합니다.




이 문제를 해결의 가장 간단한 방법은 unclean 시스템 path를 직접 entering 하는 겁니다.

여러분 스스로 lock 됐다면 아래 경로를 통해서 접근하세요.
http://example.com/?q=user

그 페이지에서 여러분은 로그인을 할 수 있습니다. 그러면 admin 권한을 받을 수 있겠죠. 아직까지 모든 링크는 작동하지 않을 겁니다.

다음으로는 아래 url로 접근하세요. (Drupal 5와 Drupal 6 의 경우). 그러면 여러분이 unset clean URLs를 할 수 있는 페이지를 보실 수 있을 겁니다.
http://example.com/?q=admin/settings/clean-urls

이제 여러분은 사이트를 제대로 이용할 수 있을 겁니다. 링크가 제대로 걸릴 테니까요.

Other options that should get the same result include:

다른 방법도 있습니다.

  • Drush command를 실행하세요.

    drush vset clean_url 0 --yes

  • mysql command를 실행하세요.

    UPDATE variable SET value = 's:1:"0";' WHERE name = 'clean_url';
    DELETE FROM cache;
  • 혹은 settings.php를 수정하셔도 됩니다.
    $conf['clean_url'] = 0;


반응형

'etc. > Drupal' 카테고리의 다른 글

두루팔 옮기기 2 - 체크 리스트 -  (0) 2012.07.18
두루팔 옮기기 1 - Drupal Migrating a site -  (0) 2012.07.17

두루팔 옮기기 2 - 체크 리스트 -

2012. 7. 18. 21:43 | Posted by 솔웅


반응형

Checklist for migrating to a new server

Last updated October 31, 2011. Created by dman on November 13, 2008.
Edited by xamount, Kami Petersen. Log in to edit this page.




두루팔을 새로운 호스트로 옮기고 사이트를 활성화 할 때 살펴봐야할 것들이 있습니다.

이 체크리스트는 이미 로컬이건  호스트된 서버이건 사이트가 돌아가도록 하는데 성공했지만 다른 host나 architecture에 이 사이트를 옮겨야 할 필요가 있는 사람들을 위해 쓴 글입니다. 서버별로 그리고 버전별로 조금 다를 수가 있습니다. 그러니까 옮기고 난 이후에 겉으로 잘 돌아가는 것 처럼 보여도 여러 테스트를 해야 합니다. 

아래 체크 리스트들이 많은 것 처럼 보이지만 이 리스트 들 중 대부분인 이미 제대로 세팅 돼 있을 겁니다. 하지만 옮긴 이후에 체크를 해서 문제 없다는 것을 확인 해야 이후에 발생될 여러 문제점을 예방할 수 있습니다. 여러분들 중 대부분은 아래 작업을을 해 보셨겠지만 사이트를 옮긴 후에 이 작업을 반복해서 해야 합니다. 이 체크리스트대로 하지 않고 이미 업로드를 해 버렸고 제대로 작동하지가 않는다면 unset clean-urls 를 manually 해야 합니다.



Server basics


Drupal UI

  • TEST an upload.
  • TEST an image derivative rebuild.
  • Review access control settings for admin/editor/authenticated/anonymous users.
    각 role 별로 로그인을 한 후 체크하세요. big file을 업로드 할 수 있는지 input filter 등을 사용할 수 있는지 등등.


Permissions checks

  • Adjust write-access to sites/${SITENAME} (if installing) and sites/${SITENAME}/files
    • Check at admin/settings/file-system, it'll warn you if there's a problem.
    • What you need to do and what you CAN do to adjust permissions on the server will vary between systems.
  • check write-access to /tmp . Change it to sites/${SITENAME}/files/tmp (no leading slash) if needed.


Security tweaks

  • 셋업을 하고 난 후 모든 코드가 security 때문에 read-only  되 있는지 체크해 보세요.
    See more at File Permissions and Ownership For Security.
  • 새롭게 생성된 파일과 폴더의 owner와 group을 확인하세요. Check the owner and group of any newly created files and folders
    ls -la files/
    If the owner of web-process created files is the same as your login username (not www-data), that means it's theoretically possible for web scripts to modify themselves. This is a hack vector, and could be a concern.
  • settings.php 를 체크하세요. 여기에 database 암호가 text로 돼 있습니다. 이 파일의 접근 권한을 보고 모두에게 readable 돼 있지 않나 살펴 보세요. 만약에 그렇게 돼 있으면 웹을 통해서 여러분 디비의 암호가 노출 될 수 있습니다.
    For this reason, it would be good to have your :
    - Admin-control panel-ssh login password different from your
    - database password different from your
    - Drupal user #1 password.
    ...even though that's a pain.
  • If you have enough rights, consider shifting htaccess directives into apache configuration files for performance.
  • Remove phpinfo.php if you had one.


Testing

  • TEST directory browsing is disabled for files/ (by attempting to access it in a browser)
  • TEST that www.example.com and example.com perform the same, preferably by redirecting one to the other. See .htaccess [handbook doc needed?]
  • TEST email sending. Email setup is different for different hosts, but should be configured already by the sysadmin.
  • Check the email:from headers and see what you can do to avoid system emails going into a spam bucket
  • More testing ideas.


Best Practice Extras

  • Run a links checker. Xenu is simple for windows. linklint is adequate for commandline.
  • Visit your admin/reports after running a link checker and see what shows up. Other errors, not just 404s may appear there and need attention.
  • Consider benchmarking Drupal Performance. apachebench (ab) is OK, but needs root and just whacks one page. siege is better (can script a session), but needs installing.
  • If you have a high level of control on the server, Consider other tuning issues like PHP accelerators.
  • Consider your backup plan.
  • TEST your backup recovery.
  • Remember to configure and test any non-Drupal logging tool you may want to use. eg, Webalizer, Google Analytics or something provided by your host.
    Now is a good time to locate your server logs, and make sure you have access to them from your host. When you need them to troubleshoot problems it's too late to find that they don't exist.
  • Document every password, path and IP you can find. Domain registration, Control Panel login, User account info, FTP server, MySQL connection string, location of the config files for your backups, contact details for key parties etc. Put it all in a document with a DATE in it. Print that off and save it in three SAFE places.
  • Review your hosts policies on overages. It's much better if your host provides a warning & throttle service when/if you overrun your bandwidth or storage allocation than if they let it run then charge and penalize you (or just shut you down). Some hosts also punish 'excessive' use of the database or processor - which Drupal can be guilty of. Read the fine print.


반응형

두루팔 옮기기 1 - Drupal Migrating a site -

2012. 7. 17. 22:34 | Posted by 솔웅


반응형

지금 사용하던 Drupal 을 다른 곳으로 옮겨야 됩니다.
두루팔 사용경험이 하나도 없어서 부랴부랴 정보 researching 하고 있습니다.

혹시 두루팔을 A 서버에서 B 서버로 Migration 하는 방법 아시는 분 있으면 정보 부탁드립니다.



Last updated April 13, 2012. Created by LeeHunter on April 20, 2010.
Edited by John_B, sebastianSue, vj_pdx, ajspadial. Log in to edit this page.


만약 host를 바꾼다던가 개발서버와 실제 서버를 분리해서 관리를 할 경우에는 Drupal site를 migrate 할 필요가 있을 겁니다. 이 글은 이 일에 대한 outline 입니다. (아마 체크리스트라고 해야 할 것 같습니다.) 하지만 다른 곳에서는 제대로 묘사되지 못한 몇가지 스텝들도 포함돼 있습니다. 여러분들은 여러분들이 사용하는 모듈과 여러분 서버의 환경에 따라 이 스텝들을 약간씩 수정할 필요가 있습니다.

아래 과정은 한개의 site에 대한 과정을 담고 있습니다. Multi-site migration (Windows/Apache와 Linux) 은 다른 곳에서 다뤄지고 있습니다.


Before You Start


두개의 서버에 있는 PHP installation의 차이점을 정리해 두세요. (버그들이나 기능, 모듈, configurations, version 등등). 그리고 MySQL과 Apache 에 대해서두요.

파일을 업로드하고 다운로드하고 압축된 파일들을 다루고 퍼미션과 ownership을 수정하고 MySQL을 다루고 하는데 필요한 적절한 툴들을 준비하세요. 이런 스텝들을 다루는 Drupal tools들이 몇개 있습니다. 예를 들어 데이터를 백업하고 restoring 하는 것들 같은거요. 그렇다고 모든 과정을 다 처리해 주지는 않습니다. 여러분들이 아래 과정을 진행하는데 도움을 주는 툴이 있으면 사용하시고 아니면 그냥 직접 다 하셔도 됩니다.

새로운 사이트로 migrating 하기 위한 체크 리스트 - target site에서 두루팔이 필요로 하는 모든 기능 (mod_rewrite, AllowOverride) 등을 모두 지원하고 있어야 합니다. 전부 지원해 주는 호스트에서 조금 지원해주는 호스트로 옮기면 제대로 작동하지 않을 겁니다. 이건 migration에서 뭔가 잘못되지 않아도 target host의 세팅에 문제가 있으면 제대로 작동하지 않을 수 도 있다는 것을 말합니다.



On the old site

  1. 사용된 모듈과 버전 그리고 path 같은 것들을 정리해 두세요. contributed module site documentation이 이런 작업을 쉽게 할 수 있도록 할 겁니다.
  2.  admin/settings/file-system에서 사용될 수 있도록 temporary directory folder를 정리해 두세요. 그리고 database를 restoring 하고나서 수정할 수 있도록 준비해 두세요. 두 site 무도에 same path 가 존재하고 있어야 합니다.
  3. site maintenance mode를 세팅하세요 : Administer -> Site maintenance, Off line 선택
  4. 두루팔 core와 모듈을 최신버전으로 업데이트 할것인가에 대해 migration 하기 전에 결정하세요.
  5. Clean URLs를 Turn off 하세요. (Administer -> "Clean URLs") . 이제부터 www.example.com/?q=user 를 통해 administrator 부분으로 들어가게 될 거라는 것을 기억해 두세요. ("user"는 다른 유저 이름에 의해 replace 되지 말아야 합니다.)
  6. cache tables로부터 데이터를 clear 해 주세요. 이 데이터들은 transfer 에 필요하지 않은 데이터들입니다. 그리고 데이터를 정리할 때 혼란을 야기시킵니다. devel 모듈과 admin menu module 에는 이것을 쉽게 할 수 있는 link를 포함하고 있습니다. 다른 방법으로는 www.example.com/admin/settings/performance 로 가서 페이지 아랫쪽에 있는 Clear cached data 버튼을 누르세요.
  7. database를 Export 하세요. MySQL Administrator나 phpMyAdmin 을 사용해서 export 할 수 있습니다. 이렇게 해서 .sql 확장자를 가지는 text 파일로 된 데이터베이스 정보를 가질 수 있습니다.


    • MySQL Administrator 에서 우선 패스워드를 사용해서 접속하시고 왼쪽의 Backup 버튼을 누르세요. Databases 리스트에서 save하기를 원하는 데이터베이스를 선택하세요. 큰 화살표를 누르세요. 그러면 데이터베이스 이름을 오른쪽에 있는 네모칸인 Backup content 로 옮길 겁니다. 그 다음엔 오른쪽 아래에 있는 Start backup 버튼을 누르세요. 저장할 폴더를 선택하시고 이 때 윗쪽의 path par와 왼쪽의 Folders 리스트를 사용하시면 됩니다. 그리고 OK 버튼을 누르세요.
  8. 이전의 site 가 public (web에서) 이면 여러분 site를 on line으로 하는 것을 고려해 보세요. :  Administer -> Site maintenance 에서 on Line을 선택하시면 됩니다. 이제 예전 서버에서 만들어진 모든 modification은 잃어버릴 겁니다. (readers' comments, forums posts 등 등). 그러므로 여러분의 old website를 on line으로 set back 하시고 웹에서 public이라면 새로운 유저가 입력한 새로운 comments 등이 유실되지 않도록 new comments를 block 하면 좋을 겁니다 Administer -> Permissions.
  9. 모든 Drupal code를 copy 하세요. core, modules,themes 등을 copy 하고나서 필요하면 다운로드를 받으세요. 아니면 곧바로 새로운 서버로 transfer 하셔도 됩니다.
  10. files 디렉토리와 비슷한 다른 directory (image galleries 등)들도 copy 히세요. 그리고 다운로드 하시던가 새로운 서버에 곧바로 transfer 하세요.


In between

이 과정들은 old/new server와는 다른 여러분의 컴퓨터에서 수행 되어 질 겁니다. 만약 old 나 new 서버에서 작업하는 것이 더 쉽다면 그렇게 하셔도 됩니다. 쓸데 없이 다른 컴퓨터에 파일들을 복사해 넣을 필요는 없으니까요.

데이터베이스의 데이터들은 hard code 된 링크들을 가지고 있을 겁니다. 이런 링크들은 새로운 사이트에서는 필요가 없겠죠. 이것들을 수정하기 위해서 새로운 데이터베이스에서 SQL query를 사용하실 수 있습니다. 혹은 .sql 파일에서 직접 수정을 하실 수도 있겠죠. 이 작업을 하시면서 아래 내용들을 고려하세요.

  1. files table 에 있는 filepath field 의 files list.
  2. 사이트 URL - 많은 node 링크들과 reference들이 full site URL을 참조합니다. 그리고 많은 log file들을 참조하기도 하죠. 그렇기 때문에 new site의  name으로 바꾸는 것이 항상 적당한 것은 아닙니다. 그러니까 이 작업을 각각의 테이블단위로 하시고 고민하세요.
  3. 위 내용들을 variation 하세요. 예를 들어 messaging module은 messaging store에 각각의 message에 대한 site URL을 저장합니다. 그리고 imagefield 모듈은 filelist 같은 리스트가 있지요.
  4. 새 데이터베이스를 create 하기 위한 facility들 (아래의 Import Your SQL data를 보세요.)
  5.  데이터베이스 이름. 호스팅 회사에서는 모든 데이터베이스 이름 앞에 yourName_ 를 붙이도록 할수도 있습니다. 그리고 데이터베이스 이름에 들어가는 text 갯수를 제한할 수 도 있습니다.
  6. 아래 command는 두루팔을 A site에서 B site로 옮길 때 옮겨질 필요가 없는 데이터베이스의 데이터를 strip 하게 할 수 있습니다.
    sed -E -e "/^INSERT INTO \`(cache|watchdog|sessions)/d" < /path/to/dump.sql > /path/to/dump-stripped.sql
    만약 여러분의 database가 table prefix를 사용한다면 이 명령어를 약간 수정하실 필요가 있을 수도 있습니다.

만약에 실제 운행되고 있는 live site 에서 move 하거나 또는 live site로 move 한다면 여러분은 DNS 세팅을 수정해서 새 서버에 pointing 할 수 있도록 해야 할 필요가 있습니다.


On the new site


이제 new site에서 위의 과정을 거꾸로 진행하셔야 합니다.

  1. 전체 Drupal code (core,modules,themes) 를 new site로업로드 혹은 copy 합니다. 여러분이 원하시면 구조를 약간 바꾸셔도 되죠. 어떤 분들은 새 버전의 drupal core를 먼저 install 해서 새로운 server 환경을 테스트 하는 분도 계실겁니다.
  2. files directory나 비슷한 디렉토리들(image galleries 같은)를 업로드 혹은 copy 합니다. 업로드 혹은 copy 장소는 .sql 파일을 수정할 때 사용하게 될 위치가 되겠죠.
  3. 두루팔이 사용할 데이터베이스 유저를 생성합니다. 호스팅 회사에서는 여러분의 모든 데이트베이스 유저 이름 앞에 yourName_을 붙일 수도 있고 그 이름의 text 숫자에 제한을 둘 수도 있습니다. 여러분 호스팅 회사에서 create 쿼리를 허용한다면 .sql 파일 에 유저 생성 쿼리를 넣고 이 과정을 건너 뛰셔도 되겠죠.
  4. SQL data를 업로드하고 import 하세요. 데이터베이스를 직접 생성할 수 없다면 호스팅 회사가 제공하는 툴을 사용하실 수 있을겁니다. 이런 경우는 .sql 파일 안에 create database 라인을 지워주세요. (create database if not exist 라인은 상관없습니다.) phpMyAdmin으로 데이터베이스를 업로드하기엔 사이즈가 너무 클 수도 있습니다. 어떤 호스팅 회사는 MySQL Administrator로 접근할 수 있는 권한을 주기도 합니다. 그런 경우 용량이 큰 파일을 사용할 수 있습니다. SSH 접근을 가지고 있다면 text  console에서 MySQL을 사용하실 수 있을 겁니다. "mysql --user=user_name --password=your_password database_name" 그리고 sourch command도 사용하실 수 있겠죠. source database_backup.sql
  5. settings.php의 Database setting 섹션부분을 바꾸세요. 이 부분에서 new database로 경로가 설정 돼 있어야 합니다. 예전 서버와 다른 유저가 세팅 됐다면 유저도 제대로 설정해야 하구요.  패스워드도 마찬가지 입니다. 그리고 sub-domain과 domain level을 옮기셨다면 base URL을 수정하셔야 합니다.  그리고 $cookie_domain이 예전 도메인으로 설정돼 있지 않은지 체크하세요.
  6. 그리고 .htaccess 파일의 rewrite rule을 수정할 필요도 있습니다.
  7. new site로 log on 을 시도해 보세요. 아마 site maintenance mode와 non clean URLs의 combination에 의해 lock 돼 있을 겁니다. 이 경우에는 newsite/?q=user로 로그인을 하세요. 그리고 clean URLs를 turn on 하세요.
  8. site information부분을 수정하실 필요가 있습니다. (Administer → Site configuration → Site information). 여기에는 모든 email address 가 있습니다. 그리고 filedirectory를 (www.example.com/admin/settings/file-system) 파일이 새로 옮겨진 곳으로 바꿔 주세요. 또한 temp folder 도 다르다면 새로운 서버의 정확한 location으로 수정하세요. 
  9. 필요하다면 새로운 버전에 맞게 모듈들을 수정해 주세요. 예를 들어 PHP 5.2.8에서 5.3.0 으로 업그레이드 됐다면 어떤 모듈들은 제대로 작동하지 않을 수도 있습니다. 이럴 경우 여러곳에서 에러메세지를 보실 수 있을 겁니다. 아래 제가 search 한 에러의 내용들 입니다.

    • Set date.timezone = php.ini file안의 UTC  (아마 이 파일이 두개 있을 수 있는데요. 하나는 command line 용이고 다른 하나는 Apache 용인데 여러분의 경우엔 아파치용을 수정하셔야 할 겁니다.)
    • Apply patch 6.x-2.x-549884-30.patch to the date module
    • Use 6.x-3.x-dev instead of 6.x-3.0-alpha3 for the admin_menu module
    • Drush 와 함께 작동하지 않는 coder module을 delete 하세요. (하지만 이 부분이 항상 이 문제 때문인지는 확실하지 않습니다.)
  10. Check the status report: Administer → Reports → Status report. Drupal 에서 suggest 한다면 Cron을 Manually 작동시키세요.
  11. 이제 여러분의 new site는 예전 사이트 처럼 작동할 겁니다. 예전것과 구분하기 위해서 theme 이나 theme color를 바꾸고 싶을 수도 있을 겁니다.
  12. 필요에 따라 performance 파라미터도 수정하세요. Administer → Site configuration → Performance.
  13. 모든것을 다 체크했다면 site-maintenance mode를 turn off 하실 수 있습니다. : in Administer → Site configuration → Site maintenance, choose "On line".
  14. 여기서 설명한 대로 cron job을 셋업하세요. 이 크론은 어떤 컴퓨터에서든 온라인으로 run 할 수 있습니다. 여러분 PC에서도 가능합니다. 반드시 Drupal이 돌아가고 있는 서버여야 할 필요는 없습니다. 원하는 컴퓨터를 선택하세요. (항상 turn on돼 있고 on line  돼 있는 컴퓨터야 겠죠.) 만약 호스팅 컴퓨터가 크론 사용을 허용하지 않고 여러분에게 이 작업을 할 만한 컴퓨터가 없으면 Poormanscron 모듈을 사용하세요.
  15. 여러분의 새 두루팔 서버가 public으로 되기를 원하신다면 (예를 들어 WEB에 개방한다던지) 지금 DNS를 세팅해야 합니다. 여러분의 새로운 서버의 IP에 DNS를 세팅하세요. 이 작업을 하려면 domain name register를 contact 해야겠죠. 만약에 두루팔 사이트가 이미 웹에 있다면 그리고 여러분의 migrating이 public server에서 다른 곳으로 이뤄졌다면 이 register를 바꿀 필요가 있습니다. 이 경우에는  new registrar의 contract를 잘 읽어 보세요. 그리고 registrar를 바꾸기 전에 예전 registrar의 데이터베이스에 있는 DNS를 업데이트 하기를 추천합니다. TLD(top level domain)에 따라 (아마 EPP code, authorization code, Auth code라고 불리는 코드가 필요할 겁니다. 예전 registrar에 물어보세요. 그 다음에 이 코드를 새로운 registrar에 할당하세요. (아마 새로운 호스팅 회사를 통해서 가능할 겁니다.) 그 다음에는 기다리셔야 됩니다. 대가 5일 정도 시간이 걸립니다. 만약 이 작업에 아주 익숙하시다면 migration 작업 하기 전에 시간에 맞춰서 작업하셔도 되겠죠. 단지 여러분 작업이 완료되기도 전에 DNS transfer가 끝났다면 그 동안은 페이지 접근이 안되겠죠.



반응형

'etc. > Drupal' 카테고리의 다른 글

두루팔 옮기기 3 - Manual로 clean URLs 하기 -  (0) 2012.07.18
두루팔 옮기기 2 - 체크 리스트 -  (0) 2012.07.18