다른 템플릿을 쓰다가 템플릿언더바로 옮겨오려니 자꾸 옜날에 하던 방식으로 프로그램하려는 습관이 남은거같아요.
다름이 아니라.. define_string() 개념이 있으면 좋지 않을까 하는 생각입니다.
{# area} 라는 영역이 있었는데, 경우에 따라 area.htm을 그 자리에 define 해서 사용할 경우도 있고, 그냥 "{area}가 없습니다"; 라는 글자로 대체하기도 하고 싶을 경우, 일부러 {content} 라는 내용을 가진 blank.htm 템플릿을 만들어 쓰기도 하고 개인적으로 소스를 조금 고쳐보기도 했는데요.. 원하는대로 잘 고쳐지지 않네요 ^^
고쳐진다 하더라도 메인소스에 적용되도록 로비를 해놔야 지속적인 업그레이드 혜택을 받을 수 있을꺼같아서요 ^^
문법은 $tpl->define('#area','내용'); 이정도면 좋을꺼같기도 하구요
이렇게 define 했을때 '내용'이 그 자리에 출력되도록 하는것은 쉽게 고쳤는데요
define 인만큼, '내용'에 해당하는것 자체도 템플릿 태그가 파싱되어야 할꺼같아서
단순히 글자로 대치시키는것이 아닌, 템플릿 코드로 파싱되는 과정도 있어야 할거같습니다.
영역과 변수를 혼용하도록 하는것은 혼란을 일으킬 수도 있지만, 사용 방법에 따라 템플릿을 크게 확장시킬 수도 있습니다.
이미 내부 로직에서 define이 끝나고 출력 준비가 된 상태에서
$tpl->setLayout() 같은 메소드를 만들어서
내용 전체를 둘러싸는 다른 템플릿을 덮어씌운다던가 하는 액션이 가능해지면, 재사용성도 높아지고 훨씬 유연하게 사용할 수 있을꺼같습니다.
===
prefilter.ssi.php
전에 말씀드렸던 <!--#include file='' --> 형태를 사용할수 있도록 만드는 prefilter를 만들어봤는데요
정규식을 대충써서 만들어서 띄어쓰기나 따옴표등에 선택권은 거의 없구요..
<!-- #include file='test.php?arg1=aaa&arg2=bbb' -->
형태를 받았을때, 물음표 뒤의 내용이 변수로 파싱이 되긴 하지만, 독립적이지 않고, 현재 실행되는 php에 병합됩니다.
<!-- #include file='test.php?tpl=null' -->
뭐 이런식의 입력이 들어오면 곤란하겠죠 ^^
그리고 include 되는 내용은 php가 아니라도 상관없지만, 템플릿으로 사용되지는 못합니다.
===
파일이름 변경, 디렉토리 변경
전부터 해오던 프로그램 라이브러리들에서 출력부분을 담당하는 템플릿을 뜯어 고치다보니, 부득이하게 네이밍을 변경하는 일이 생겼습니다.
php 클래스파일들은 항상 lib/class.클래스명.php 형태로 저장했기에
Template_.class.php => class.Template_.php 로 변경해서 사용하고 있습니다.
또, 어떤 클래스파일에 종속되는 파일들의 경우 그 클래스 이름과 동일한 디렉토리명을 만들어 그 아래 넣다보니 tpl_include 라는 디렉토리도 lib/Template_ 로 이름을 변경했습니다.
그에 따른 소스도 약간 변경했구요
원래 원본소스에는 잘 손 안대고 확장 클래스 형태로 만들어 사용하곤 하는데,
인클루드 패스가 하드코딩되어 어쩔수 없었습니다
다음번 업 하실때 인클루드 디렉토리도 환경설정 부분에 포함되면 좋을꺼같습니다.
이거 보면볼수록 맘에드는군요 : )
관리자
답변이 늦었네요.
직접인클루드는 현재 소극적?으로 지원되고 있고.. 템플릿 구문이 포함된 문자열을 define하는 것은 좋게 말하면 유연한 것이겠지만 템플릿엔진이 적극적으로 권할 수 있는 방법으로 보기는 어렵지 않나 싶네요.
변수충돌은.. include_php 같은 함수를 만들어서
function include_php($path, $str) {
parse_str($str);
include $path;
return '';
}
{=include_php(..., ...)}
이렇게 하시면 될 거 같고..
필터경로등.. 사용자정의 부분은.. 꽤 사소한 문제들 때문에 놔두었었는데 요청이 있으니 반영해 보아야 겠네요.
직접인클루드 지원이 빈약한 이유는.. 아직까지 제 경험상 그다지 필요성을 못느꼈다는게 답변일거 같습니다.
암튼 여러 가지 의견, 좋은 말씀 감사합니다.
04-08-03 14:25
파란
관리자 // 안녕하세요 ^^ 더운 여름 어떻게 지내시는지..
옥탑에 에어콘을 달아놔도 덮긴 마찬가지네요 ㅋ
tpl 을 화일로 저장한것이 아니라 디비에 넣었다면...
문자열 define도 유용하게 사용될거 같은데요...
04-08-03 14:47
관리자
두 가지 이유인데요..
컨트롤러(index.php) 내에 뷰에 해당하는 내용이 마구 돌아다닐 위험이 있고.. 현재 변환방식을 적용했을 때 문자열템플릿코드는 실시간으로 변환한 후 eval 로 처리해서 출력하게 될텐데.. 느려지게 됩니다.
디비에 넣을 때도.. 디비 사용 체제를 마련해서 변환디렉토리를 지정하고 변환파일을 이용하도록 하는게 적절한 거 같습니다. 혹시 템플릿을 디비에 넣어 쓰실 계획이 있으신가요..
04-08-03 15:06
파란
넵 그럴 계획이 있습니다 ^^
지금은 디비에 넣은후 파일을 생성해서 하고있긴한데...
04-08-03 15:19
관리자
디비하고 비교해서 변환파일이 유효한지 체크하게 하려면 작업을 좀 하셨을 거 같네요. 더위 땜에 주말에도 사무실에 나오긴 하지만.. 일거리 자꾸 생기네요ㅎㅎ 여름 잘 보내세요^^
04-08-03 15:32
거친마루
그렇겠네요.. 하긴 define_string() 할 목적의 내용이라면 계속 변하는 내용일꺼고, 변환파일을 한번 만들어 빠르게 쓴다는 컴파일형 템플릿의 장점이 사라져버리는거겠군요..
그냥 영역을 정적인 스트링으로 치환하는 정도로 만족해야겠습니다 : )
_define() 메소드에
case '#': $this->tpl_[substr($fid,1)]=array('str', $path); break;
를 추가하고..
print_() 메소드에
$tpl[0] === txt보다 먼저
if ($tpl[0]==='str') {
echo $tpl[1];
return;
}
를 추가하면 됩니다
04-08-03 15:51
거친마루
컨트롤러 내에 뷰에 해당하는 내용이 돌아다니는것을 위험하다고 하셨는데.. 컨트롤러에 의해 만들어진 결과물이 다시 다른(상위 또는 동등한)컨트롤러에서 사용될 '뷰'가 될수 있는 '프레임웍'으로 동작할 기회를 열어주면 좋을꺼같다는 생각에서였습니다. : )
