토요일에 서울대공원에 다녀왔다. 김밥 세줄, 물 2개, 과자 하나 달랑 들고 지하철 타고~~~
도착해보니 인산인해, 차산차해.. ^^;
점심 즈음에 도착한지라 입구 벚나무 그늘에서 김밥을 해치우고 벚꽃길을 따라 올라갔다.
벚꽃들이 다시 동그랗게 꽃처럼 무리를 이루어서 정말 예뻤다.
미술관 입구쪽 벚나무들
몽알몽알..
정말 눈부시다는 표현밖에는…
열심히 잉어를 그리고 있는 웅휘
평상시 보던 것과는 조금 다른 목련종류
미술관 입구쪽의 목련. 정말 흐드러진다.
두 송이 목련
대공원입구 분수대옆의 벚꽃터널
| navyism |  날 짜 | 09-04-08 14:30 | 조 회 | 100 | |
| Link1 | http://navyism.com (16) | ||||
이름 기억나는거는 할미꽃밖에 없네요. ㅋㅋㅋ
본가 안마당과 바깥마당에 핀 녀석들 웹나들이 시켜주려고 찰칵~
본가에 갈 때 가끔은 주인집 사람인 것을 잊어먹고 짖지만 이내 꼬랑지를 흔드는 녀석입니다.
컹컹 짖는 소리가 무척 크지요. 근엄한 표정(?)을 짓길래 찍었습니다.
착하게 생겼죠?
제목 붙이기가 좀 어렵네요
CI로 CMS를 개발하다보니 CI코어와 플러그인, 위젯, 레이아웃 등을 분리해야할 필요성이 생겼습니다.
그리고 플러그인의 특성상 자기 자신만으로도 웹에서 보일 수 있어야 해서 주소체계를 CI의 주소체계로 동일하게 사용해야 했습니다.(변수 전달도 포함)
application/
plugins/
widgets/
layouts/
system/
http://localhost/plugins/control/board/main <- 이렇게 주소를 쓰는데 플러그인중 게시판(board)의 main.tpl.php(템플릿) 파일을 불러옵니다.
위 주소는 application/controllers/plugins.php 에 연결되어있고 그 내용은 다음과 같습니다.
function control (){
$this->load->model(PLUGPATH.’/’.$this->uri->segment(3).’/Functions’);
// $this->uri->segment(3)=> board 플러그인의 Functions.php 모델을 불러옵니다.
// 플러그인 규칙으로 모델은 Functions.php로 정합니다.
$data=$this->Functions->default_control(); // Functions 모델의 default_control 함수를 호출하는데 그 안에 컨트롤 파일이 들어있습니다.
$this->load->parser(PLUGPATH.’/’.$this->uri->segment(3).’/default/’.$this->uri->segment(4).’tpl.php’, $data);
}
plugins/board/Functions.php
function blist (){
게시판 리스트 가져오는 함수
return $query->result_array(); // result_array()-> CI의 DB함수
}
function default_control (){
$ll = $this->blist(‘test’); //게시판 리스트를 배열로 가져옵니다.
return $ll;
}
└– default_control 부분이 핵심입니다. 컨트롤러에 있어야할 내용이 모델안에 함수로 정의되어 있습니다.
그리고 plusins라는 컨트롤에서 default_control 함수가 처리한 내용을 받아서
CI 템플릿 형태의 파일인 main.tpl.php로 보내줍니다.
위와 같은 작업을 함으로써 application 디렉토리 이외의 외부 디렉토리에서도 MVC 패턴(엄밀히 말하면 아니지만, 모델안에 컨트롤러가 구현되어 있으므로)을
그대로 구현할 수 있습니다. 특히나 다른 개발자가 만든 플러그인 같은 경우 정해진 규약대로만 만들면(Functions.php main.tpl.php 등)
CI의 주소체계를 이용하고 CI 내장함수도 그대로 이용을 할 수가 있습니다.
평상시 개발에서는 구현할 필요가 없지만 외부 개발자들이 만든 플러그인을 사용하는 구조라면 필요합니다.
이 내용을 올리는 가장 큰 목적은 CI의 유연성을 말하고 싶어서 입니다.
이번에 CI로 CMS 작업을 하면서 느낀 것은 CI의 확장성, 유연성입니다. 어느 정도 프레임워크로서의 틀을 가지고 있지만 그 틀을 넘나들 수 있는 유연성을 가지고 있다는 것.
다시 말해 개발자들이 어떻게 구현하느냐에 따라 정말 어떤 구조던지 가능하다는 것입니다.
프레임워크의 편리함(내장함수들의 편리함, 구조화, mvc패턴 등등)을 사용하면서 동시에 개발자의 재량에 따라 얼마든지 기존 구조이외에 것을 이용할 수 있다는 점이 큰 장점이라고 할 수 있겠습니다.