| PHP]Smarty 설명문서와 그 MVC 방법론에 대한 논란~ ^^; | 재미없는거 | 2004/11/06 04:27 |
|
| http://blog.naver.com/prosun76/20007137265 |
|
| | 글쓴이:최근한 | Smarty 설명 문서 | 조회수:7984 |
/classroom/SmartyDocument.pdf
안녕하세요. 저는 최근한이라고 합니다.
공부삼아 Smarty 문서를 정리하던중에 혹시나 도움이 될까해서 올립니다. ---------- I. Introduction
1.들어가기 전에
어젯밤 밤을 새서 디자인에 프로그램을 입히고 서버에 올려놓고 퇴근했는데 오늘 디자이 “ , 너가 와서 배경색 바꾼다고 파일을 덮어쓰기 했어요 어제 다 해놓고 갔는데 오늘 안 되어 . 있다고 오자마자 팀장한테 욕 무척 먹었어요.“ 언제인지는 모르지만 어떤 사이트의 자유 게시판에서 본 게시물의 내용이다 조금 더 과격 . 한 표현을 썼던 원문을 잠깐 참고하면 멍청한 디자이너가 파일의 날짜로 안보고 그냥 덮어 “ 썼다 란다 자기는 일 해놓고 갔는데 안해놨다고 욕먹었으니 화날만도 하고 뭐 원문 그대 ” . , , 로를 살펴보면 프로그래머가 잘못한 것은 하나도 없는 피해자 같다 하지만 이 일이 왜 생 . 겼을까 미리 막을 수 있는 방법은 없었을까 ? ? . . .
|
|
|
헤헤
pear db와 smarty를 이용한 sample application 어디 있나요?
관심은 있었지만 마땅히 어찌 적용해야 할 지, 어떻게 적용해야 할 지 몰라서 못 쓰고 있어서... 소
스가 공개된 좋은 sample application이라도 있으면 공부좀 하고 싶군요.
05/27
23:24:32
CF
아직도 템플릿 사용하시는 분이 계시군요. 쩝
PHP 자체가 템플릿 구조인데...
05/28 9:45:22
오잉
뭐가 맞는 말인지 모르겠네요...
05/28
15:18:10
토시
CF// 그렇게 말씀하신다면 아직 템플릿의 개념을 이해 못하고 계신 겁니다. html소스 안에 php코
드가 삽입되어 있는 형태라고 해서 아마 그런 말씀 하신 모양이죠?
05/28
17:07:06
아주작은새
문서가 좋은데 처음 부분에서 멈춘것이 아쉽군요
좀더 깊이 들어 가면 정말 좋을것 같습니다.
05/28
21:10:07
공간
좋은 문서 감사드립니다.. ^^
05/29 6:17:01
CF
토시// 괜찮다는 템플릿을 전부 사용해 보았습니다.
나름대로 결론을 내렸는데 템플릿 문법을 또 배워서
PHP만으로도 충분히 할 수 있는 부분을 굳이 템플릿을
사용해서 작업하는 것 자체가 비효율적이라는 겁니다.
템플릿을 사랑하시는 분(?)들은 협업 말씀을 많이 하시는데요.
PHP만으로도 충분히 협업 가능합니다.
말로만 하면 이해를 못 絿프?모르니 몇 가지 예를 들겠습니다.
템플릿을 사용할 때 흔히 HTML과 구분되는 구분자(separate)
를 사용합니다.
우선 그 구분자의 역활을 PHP가 할 수 없느냐?
할 수 있습니다.
{$var} 하고 =$var;?>사이에 차이점이 뭘까요?
그리고 주로 사용하는 header, footer 와
include_once() 문법과 뭐가 다를까요?
마지막으로
처럼
반복을 요구하는 부분과
foreach(): endforeach; 구문과 무슨 차이가 있죠?
고로 PHP만을 가지고 응용하여도 충분히 템플릿 효과를
낼 수 있다는 것입니다.
05/29
10:10:59
홍길동
cf 님에게 한마디.
물론 php만으로 충분히 할수있습니다. 그러나...
smarty만의 강력한 기능과 편리함이 있습니다.
템플릿 프로그램을 사용해서 시간과 정력을 아끼는 것도 좋은 방법 같은데요.
cf 님 처럼 템플릿 안쓰고 php만 쓰겠다면 그렇게 하십시요.
그렇지만 템플릿 쓰는사람들에게 왜 사용하느냐는 식의 말은
맞지 않는것 같습니다.
05/29
10:34:50
CF
홍길동// 왜 사용하느냐는 식으로 들리셨다면 오해시고요.
뭐 각자의 개발방법의 차이겠지요.
하지만, 저의 요점은 굳이 Smarty라는 거대한 템플릿을
배우면서까지 개발을 할 필요가 없다는 것입니다.
다시 말씀드리면 템플릿 구조를 만들기 위해 Smarty 문법을
배우고 PHP도 배우고... 오류가 나면 템플릿 오류인지
PHP 오류인지 헷갈리고...뭐 그럴 필요가 없다는 것이죠.
템플릿 개념만을 가지고 코딩하면 됩니다.
위에 Smarty는 예를 든 것입니다.
그래도 나는 PHP만으로는 템플릿 구조로 코딩을 못 하겠다 하시면
어쩔 수 없습니다. 그렇게 코딩하십시오.
05/29
10:52:01
홍길동
제가 하고자 하는말을 cf님이 하시네요.
각자의 개발방법의 차이가 있으니깐 서로 좋은것을 사용하자는 이야기 입니다.
그러니깐 구지 왜 smarty을 사용하느냐의 말은 맞지 않습니다.
님처럼 php만 쓰는것이 좋은지 smarty를 이용하는것이 좋은지는
각자의 능력과 좋아하는 스타일로 결정된다고 봅니다.
05/29
11:03:27
홍길동
한마디 더하자면
프로그래머 입장(웹프로그램)에서 디자이너와 서로 의논하면서
해야하기 때문에 각자 개발하기 편한쪽으로 해야한다고 생각하는데
그런점에서 smarty는 매우 훌륭한 tool이라고 생각됩니다.
저도 여러방법으로 개발을 시도했고 그때마다 디자이너에게 답변을 들었는데 smarty를 썼을때가
서로에게 좋은 점수를 얻었습니다.
05/29
11:11:01
CF
홍길동// ^^;
아무튼, 저의 말뜻을 이해하시는 분이 계실 거라고 믿습니다.
05/29
11:12:09
CF
홍길동// ㅎㅎ 디자이너입장에서 템플릿이 젤 짜증나는 작업입니다.
제가 사용하는 방법으로 개발하면 디자이너가 굳이 템플릿을
알 필요도 없습니다.
그만큼 PHP가 강력하다는 것이죠.
05/29
11:14:20
CF
덧붙여서 디자이너와의 협업에서 서로의 영역을 침범하지 않는다고
템플릿의 장점으로 많이 말씀하시는데
제가 볼때 디자이너는 디자인만 잘하면 됩니다.
나머지는 프로그래머의 몫이죠.
05/29
11:16:10
홍길동
cf 님
저는 논쟁을 하자는 이야기가 아닙니다.
다만 서로 좋아하는 스타일이 있는데..
왜 그걸 사용하느냐의 식은 옳지 않다는 말입니다.
이상 이걸로 끝내겠습니다. 좋은하루 되세요.
05/29
11:22:43
CF
홍길동// ok. 좋은 주말 보내세요.
05/29
11:28:48
-.-
템플릿이 필요할 때가 있습니다. (저 같은 경우 거의 모든 경우...)
1. 출력폼을 화면으로 그리고 프린터 출력으로 그리고 이메일 발송으로 보내고자 할 때...
2. 헤더값을 써야 할 때...
3. 코드의 간결함을 유지하고자 할 때(데이터 파싱 등 디자인 독립적인 코드는 PHP에서, 가격에
컴마를 찍는 등의 100% 디자인 때문인 코드는 템플릿의 플러그인에서 처리)
4. 캐쉬를 사용해서 퍼포먼스를 높이고자 할 때...(여러가지 캐슁 레이어가 있지만, 템플릿에서 제
공하는 캐쉬도 상당히 쓸만 합니다.)
개인적으로 템플릿을 쓸 때의 장점은 출력이 가장 하단에서 이루어지고, 객체로 이루어 짐으로 코
드 자체가 객체화 또는 함수화 되고, 그로 인해서 메인페이지의 코드는 상당히 줄어들었습니다.
이것은 PHP만 사용할 때에도 가능하지만 템플릿을 쓰면 거의 반강제적으로 그렇게 되더군요.
하여튼 머가 좋고 머가 싫고 간에 전 템플릿 쓰는게 재밌습니다. :-)
05/29
12:27:08
나그네
딴지 가 서로의 발전을 위한 좋은 걸음마죠.
CF/홍길도/토시님 세분이 서로 대화를 좀더 깊숙히 나누시면
더 좋은 문서가 나오겠내요.. :)
05/29
16:04:50
전영규
=$k?>식으로 해도 템플릿 효과는 충분히 납니다.
오히려 표준적인 방식이라고 할 수 있지요.. PHP 프로그래머나 구경만 해본 디자이너나 다 아는
표현이니까요.
그것을 템플릿이라고 해도 전혀 무리는 없다고 봅니다...
단, 이것은 소스코드를 감출 필요가 없을 때의 방법이되구요.
소스코드를 감출 필요가 있을 때는 절대로 하고 싶지 않은 방법이죠...
제가 생각하는 템플릿의 필요성은 이게 가장 크네요.
-- jeon.
05/29
19:15:32
챠트맨
이미 오래전부터 스마티 적용해서 웹사이트 개발중..편리하긴 한데 약간 복잡..^^
05/31 2:51:46
아주작은새
템플릿을 사용하면 장점이 디자인이 분리되서 좋은거 아닌가요?
=$val?>과 같이 사용하는 경우
반복문을 디자인 파일에 직접 적어줘야 하는 불편함이 있잖아요?
아니면 제로보드 처럼 너무 많은 디자인 파일이 생성 해야하는......
smarty 의 경우 {$val[loop].key} 와 같이 사용하면 간단하기 때문에 더욱 디자인을 분리하기 좋
더군요
그리고 자체의 기능이 워낙 많아서 세세한 설정을 하고 싶을때도 좋고요
하지만 단점은 역시 기능이 너무 많다는데 있습니다;;
쓸데 없는 것도 있다고 생각합니다.
number_format html_options 같은 경우 php 에서 처리 해도 될것인데 굳이 템플리에서 까지 만들
어 둔다는거
그리고 include 를 하게 만들었다는거 등은 정말 쓸데 없다고 생각이 됩니다.
05/31 4:10:08
미나리청년
저는 smarty 쓰다가 너무 방대한 기능때문에 template_로 바꿨습니다. smarty는 쓰잘데없는게 너
무 많아요. template_는 심플,간단, 꼭 필요한거만 있네요.
헌데 CF님 말도 일리가 있네요..
처음에 저도 스크립팅언어에서 굳이 클래스, 템플릿까지쓸 필요가있을까하는 생각..
개발자가 편해질것이냐 최대의 성능을 낼것이냐.
05/31
10:41:38
토시
무슨 말씀들을 하시는지 알겠습니다. 다만 =$test?>방식의 코딩만으로는 디자이너에게 전달하
기 곤란한 경우가 적지 않기 때문에 템플릿을 쓴다고 봅니다. 가령.. 루프문 처리 같은거지요.
템플릿으로 디자인을 잘 분리했을 경우 디자이너가 얼마든지 자기 쓰던 툴로 php를 안 깨고 디자
인 수정이 가능하게 되기 때문에 편리한것이죠. (물론 스마티의 복잡한 기능까지 다 쓰게 되면 디
자인 형태를 유지하는것도 힘들어지기 때문에 이러한 주장에 힘이 떨어지게 되기는 합니다만...)
암튼 제가 한말씀 드린것은 "아직도 템플릿 사용하시는 분이 계시군요"라는 말씀이 주는 느낌은
웬지 템플릿을 쓰는 분들이 쓸데없는 것에 시간낭비하는 것처럼 생각하시는 듯 해 말씀드린것입
니다. 템플릿이 그렇게까지 무용한 것이라면 php개발진에서 pear db에 템플릿클래스를 등록하지
도 않았겠죠.
05/31
11:10:55
.ㅡㅡ.
http://smarty.php.net/docs.php 에 가보니 한국어 링크는 없군요.
문서를 읽다보니 번역 도움인력을 구하시는 듯 한데..
kldp쪽에서 공동 번역을 시도해 보시는건 어떨지요?
05/31
16:37:45
정념,정행
스마티를 사용하다가 느낀점입니다.
변수의 종류가 많지 않은 간단한 구조를 사용할때 스마티가 편리하다고 느겼습니다만,
변수 종류가 많아지지 확장성과 유지보수성이 조금 떨어지더군요.
성능을 수치로 비교해 보지는 않았습니다만, 스마티가 컴파일한 소스를 보면 그리 좋아 보이지 않
습니다.
스마티 대신 php로 사용하는데 스마티 처럼 사용합니다.
====================================================
php에 해당하는 예제 코드는
====================================================
$result = mssql_query($sql,$conn);
$setdata=array();
while($data=mssql_fetch_array($result))
{
$setdata[]=$data;
}
//--------------------------------------------
// 결과를 디자인 파일에 넘긴다
include 'skin/list_skin.php';
====================================================
스마티 대신 php로 작성된 list_skin.php의 핵심구조.
====================================================
foreach($setdata as $data)
{
$link="list_detail.php" ;
?>
|
?trdate==$data[sdate]?>"> |
}
?>
이렇게만 사용해도 디자인와 프로그램 부분이 별도로 존재하기 때문에 전혀 문제가 없습니다.
개발 후 잦은 수정이 있을 경우 프로그램 부분과 스마티를 바꿔야 하기에 저의 경우는 조금 불편
했습니다.
스마티 문법을 배우는 것도 부담이 되구요.
다만, 스마티를 이용한 입력모듈이 따로 존재하는데 그것을 이용할 경우 자바스크립트 를 사용하
지 않고도 쉽게 입력값 확인이나 오류를 방지할수 있는 것은 조금 끌리는 점입니다.
모든 부분에서 스마티가 좋다고는 할 수 없겠네요.
장 단점을 알고 해당 프로젝트에 적당히 사용하는게 가장 현명한 방법이라고 생각듭니다.
06/01 9:38:34
mir.
php의 template자체가 조금 불편하게 만들어 졌다고 생각합니다만..
파일을 여러개로 쪼개서 보관해야 한다는 점에서 디자이너 측에서 상당히 불편한 방식이 된건 아
닌가 싶군요.
차라리 template을 좀 더 개량해서 디자이너/프로그래머에게 모두 더 편한 환경을 생각 해 보시는
건 어떠신지..
="var=?">를 쓰던 {var}를 쓰던 양쪽 다 같은 건 마찬가지이겠지만, 로직 자체가 디자인페이지와
섞여 있다는것이 template을 쓰는 가장 이유가 아닐까 생각됩니다
php 파일 하나에 로직과 디자인 함께 들어있는 구조가 아니었다면, 굳이 template을 만들지도 않
았겠죠.
마지막으로..
로직 파일 한개, 그리고 디자인 파일 한개, 이렇게 두개의 파일으로만 이루어지는 template방식은
어떨까 생각해 봅니다만..
이번 프로젝트에서 template code precompile, cache system을 적용하여 php에서 engine을 개
발하려고 구상하다가 그냥 ms측 기술사용으로 넘어가는바람에 c#.net으로 넘어가게 될것 같습니
다만.. 이쪽으로 넘어와서 보다보니.. .net도 비슷한 개념의 방식을 쓰고 있는것 같더군요.
개발자에게 있어서 가장 중요한건 새로운 방식에 대한 비판 이후에 기존의 방식으로 되돌아가기
보다는 더 나은 방식을 만들어 내는것이 아닐까 싶습니다.
06/01 9:53:47
mir.
어찌되었건.. 기존의 template이 느리고 불편한 것은 확실한 것 같습니다. ^^;
06/01 9:54:40
석이
분리되고 smarty 보니 한번만 파싱하고 두번부터는 프리파싱된 데이터를 이용해 하는걸 보니....
뭐 쓸만 하다는 생각도 듭니다. 사실 클래스를 이용해 smarty 문법을 만들어 쓰는 것을 본적도 있
습니다. 클래스가 좀 어려워서 그렇지 쓸만 했는데 거기에 더해 프리파생은 상당히 메리트가 있어
보였습니다. 개발 4개월째 ㅡ.ㅡ ;; 초보가
06/02 2:31:37
네오플
논쟁이 대단합니다. 음... 역쉬 아직 PHP는 살아있다는 증거겠죠..? 저도 템플릿에 대해서 한마디
하겠습니다.
Template 는 하나의 기술입니다. OOP도 마찬가지구요..
Java, C 기타 다른 언어에서도 마찬가지로 이러한 기술은 PHP에서만 쓰이는 것이 아니란 예기죠..
그럼 이러한 것은 왜 쓰는것일까? 각자 목적을 이루려는 결과물을 쉽고 간편하게 얻기 위한 것이
겠죠..
Template의 중요성은 규모가 있는 프로젝트를 많이 해보신 분이라면 필요성을 더 느끼실것입니
다. 만약 Template의 목적을 안다고 가정할때..
그럼 Template를 꼭 써야 하나..? 그것은 아니라고 봅니다.
Template는 하나의 기술일뿐 필수는 아니라는 것이겠죠..
나에게 가장 편한방법을 써야겠죠..
하지만, 앞서가시려면 쓰지 않더라도 그목적과 쓰임세는 알아두시는 것이 좋을것입니다.
초보시절
테그에 항상 border=0 을 주었지요..
나중에 스타일시트의 IMG {BORDER: NONE;} 을 알고 난후
그 편안함은 이루 말할 수 없었습니다.
위에서 말하려는 요점은 내가 현재 알고 있는것이 지금은 편할지 모르지만 더 낳은 방법을 찾는다
면 예전의 방법은 쓸려고도 하지 않을 것입니다.
적어도 Template은 이럴때 좋은 역활을 해 주더군요..
- 경험 피력 -
임대형 쇼핑몰 솔루션을 제작중 일부 변수의 충돌로 Skin의 변수명을 변경시킬일이 생겼지요.
Skin은 약 150개정도 Editplus 로 150개를 열어서 일일이 수정하고 또 몇일후 똑같은 상황으로 변
수명을 수정하였습니다. 이게 뭡니까~ 변수나빠요~(블랑카버젼)
결국 Template 을 사용한 후 이러한 문제들을 해결할 수 있었으며, 많은 구조 변경이 일어나도
Design Skin 을 그대로 사용할 수 있는 효과가 있더군요..
전 지금도 좀더 간편하고 효율적인 방법이 있다면 기존것을 버리고 새로운 방법을 찾습니다.
여러분들이 PHPSchool 을 찾는 이유도 이러한 이유 때문은 아닐까요..?
06/02 2:53:10
나그네
네오플 님에게 한표.
프로그래머는 무엇을 쓰느냐가 문제가 아니라 어떻게 쓰느냐가 더 중요한 문제인것 같습니다.
저 경우도 smarty를 쓰고 있지만 꼭 써야한다고는 생각하지 않습니다. 그리고 smarty를 익히느냐
시간을 많이 투자하지도 않았습니다. 그저 중요한것만 쓰고 나머지는 조금조금씩 메뉴얼을 보면
서 썼습니다. 그러나 php도 제대로 못쓰면서 smarty부터 쓴다면 절음발이 프로그래머로 전략됩니
다. --이상--
phpschool 화이팅 !!!
06/02
13:00:55
음..
디자이너가 단독으로 간단한 문제를 처리할 수 있다는것과
드림위버등의 툴이 코드를 깨먹지 않는다는것
두가지만으로도 제게는 쓸 가치가 충분하군요.
06/02
16:15:33
Akal
템플릿을 제작할때 보통 예약어를 특별한 구분자를 두어서 표현하긴 합니다만, 좀더 쉽게 제작한
다면 예를 들어 예약어를 한글로 표현한다면 더더욱 쉽게 템플릿을 제작하고 디자이너들과의 의
사소통도 한결 간결해 질 수 있습니다. {글제목} 이런식으로 말이죠. 저는 이런식으로 템플릿을
제작해서 꽤 좋은 효과를 봤습니다.
템플릿은 또한 리뉴얼이나 리빌딩 시에도 예약어만 그대로 지켜준다면 프로그램은 건드릴 필요도
없이 디자인만 바꿀수 있다는 유지보수의 장점이 대단히 큽니다.
smarty의 강력함에 젖어보기도 했지만 smarty의 사용하지 않게 되는 수많은 기능들을 생각해보고
자기만의 빌딩라이브러리로 템플릿을 구축한다면 더욱 많은 도움이 되리라 생각되는데요..^^
06/05 8:09:46
4000만개
템플릿을 써도 속도에는 전혀 지장없나요
저는 게시판을 전문으로 만드는데 속도는 1000만건에서도 0.0x 대의 게시판만 만들거든요 템플릿
을 써도 속도저하가 없다면 써도 괞찬을듯 하군요 그리구 전 디자인 쪽은 {$var}이런식으루 사용
하는데 이게 몸에 익어서 그런지 참 편하고 좋군요 ㅎㅎ
디자인도 내가 다 하니 ㅋㅋ 템플릿의 필요성은 전혀 못느끼겠군요
06/08
17:08:19
지우개
템플릿을 사용하면 아무래도 include나 변수재할당등의 파싱으로 조금 느려질수는 있습니다.
템플릿을 사용한다는건 그정도의 속도저하쯤은 템플릿의 편의성등으로 묻을수 있기때문이죠.
그리고 게시판속도는 DB설계이지 php 파싱속도가 아닙니다.
혼자작업한다면 굳이 템플릿을 사용할 필요없겠지만 조금만 큰 규모에 투입되면 템플릿(혹은 그
비슷한 기술)은 필수입니다.
06/09
10:51:12
야호~~
http://mail.smarty.co.kr/man/kr/index.html
06/10
17:44:35
그러니까
템플릿의 장점 :
PHP가 아니니까 디자이너에게 새로운 규칙을 익힐것에 대해
보다 유리하며, 디자이너의 소스 수정을 쉽게 유도할 수 있다.
템플릿의 단점 :
개발시간이 느려지고, 수정이 불편하며, 스마티라는 새로운 템플릿의 규칙을 알지 못하면, 접근하
기 힘들다.
에러를 쉽게 찾아낼수 없으며, 소스를 보면 실제로 어떤 의미를 가지는지 명확하게 찾아내기 힘들
어진다. 또한 속도는 템플릿을 쓸 경우 쓰지 않을경우에 비하여 파싱부분에 있어 몇배로 느려진
다. 마지막에 이야기한 느려진다는 이야기는 현재 서버의 사양과 인터넷 속도때문에 느끼지는 못
할 것이다.
06/13 0:56:21
그러니까
제가 보는 템플릿은 (저도 템플릿을 개발해 봤습니다) 별로 도움이 되지 못할뿐더러, 필수적으로
하지 않으면 이상한 개발자라고 인식할만큼 효용가치가 있는것도 아니다. 그러나 요즘은 템플릿
을 많이 쓰는 추세인데, 유행을 따라가는 것인지, 안쓰면 안되는 퀄리티가 있는것인지, 도저히 알
수가 없다. 중요한것은 PHP와 똑같은 코딩규칙을 배워야 한다는 것이다.
구지 그렇게 쓰고 싶다면 PHP도 한글 변수를 지원한다.
=$내용?>아싸리 이렇게 쓰기를 권고한다.
06/13 0:59:48
.ㅡㅡ.
그러니까//
물론 템플릿이 만능은 아니지만 경우에 따라서는 필수입니다.
예를들어 사용자가 스킨을 직접 만들어서 올릴 수 있게 시스템을 만든다면
코드와 보여지는 화면은 철저히 분리되어야 합니다.
그런 시스템에서 스킨 안에 php코드를 직접 넣을 수 있게 된다면 돌이킬 수 없는 결과를 일으킬
수도 있으니까요.
템플릿을 잘 쓴다면 그런일은 방지할 수 있겠지요.
06/14
13:15:57
그러니까
.ㅡㅡ.//
사용자 부분에서 그렇게 하는것은 저도 쓰고 있고 인정합니다.
그러나 지금은 그부분에 대해서 이야기 하는것이 아닌듯
06/14
17:43:38
아주작은새
실제로 php 를 잘 아는 사람들은 smarty 가 필요없을수도 있죠
smarty 가 필요한 사람들은 어설프게 여러군데 해야 하는 사람들 .......에게 필요하죠
마당쇠 라고 불리우는 에이젼시 업체의 나홀로 프로그래머들
멀티플레이어라고 불리우는 디자인 + 프로그램 작업 하는 사람들
이런 사람들에게 코드의 재사용성과 디자인 변경의 편리성을 제공하기 때문에 smarty 를 사용하
는것 같습니다.
smarty 가 필요하고 안필요하고는 자신의 판단이지만
업계의 현실상 위에서 언급한 어슬프게 작업해야 하는 사람들이 많은 점을 감안한다면 더 많은 사
용자를 확보할 것이라고 생각이 됩니다.
오해가 있을까봐 답니다만
저도 어설프게 작업해야 할 경우 smarty 를 씁니다.
개발속도+안정성+퍼포먼스 가 요구되는 포탈 사이트 같은 작업에서는 smarty 는 비추천 입니다.
06/14
17:55:53
엥
다운받고 보니 별 내용 없네요. 원론적인 내용뿐..시간나는대로 두번째 article 올린다고 해놓는다
고 했는데.. 정작 중요한 그거 아닌가?
06/17
17:15:20
잠깐익명
저 문서보다도...문서PDF파일 어케 만든거예요?
06/17
20:12:23
오토나스
감사합니다. 잘 쓰겠습니다. ^^
06/18
15:05:00
소리
CF님.. 저랑 같은 생각을 하고 있었네요. 반가워요. -_-/
저도 지난 2년동안 템플릿을 만져왔었는데...
결국은 그냥 정통 php 로 돌아섰습니다.
06/21
15:23:30
CF
소리님 저도 방갑습니다. -_-/
06/22
14:59:57
xtac.net
내용이.. 스마티 무용론이 아니라 템플릿 무용론인거 같네요. 2~3 년 전 토론과 달라진 것은 MVC
패턴의 유용성에 대해서는 동의들을 하고 계신거 같습니다.
말씀들 하신 것처럼 MVC 패턴을 구현하려고 할 때, PHP 코드만으로 가능합니다. 또 다른 문법, 규
칙을 익히지 않아도 되고 동작원리상 성능도 비교적 뛰어납니다. 다른 이야기일 수 있지만 PHP 코
드만 사용하더라도 MVC 패턴을 구현하기 위한 방법들을 잘 정리하여 하나의 클래스로 묶어.. 일
관성 있는 개발 방법을 마련할 수 있을 겁니다. 예를 들어 Servant Template 이나 Brian Lozier의
컬럼(Beyond The Template Engine)에 소개되어 있는 Template 클래스가 있습니다. 간단한 소스
이고 이미 이런 것을 만들어 쓰실지도 모르겠네요.
이런 클래스에 비해 자체적인 문법이나 규칙을 가지고 있는 템플릿 엔진이 유용한가는.. 어떤 템
플릿이냐에 따라 달라지는 문제라고 생각합니다. 수많은 템플릿 엔진이 있고 나름대로의 특색이
있습니다. Template_ 를 예로 들면.. 템플릿 대 PHP 코드 변환이 1 : 1 이 아니라 1 : 1+alpha 라고
할 수 있습니다. 예를 들어.. 템플릿용 객체플러그인이나 함수플러그인을 만들었을 때, 해당 파일
을 인클루드하거나 객체생성하는 코드를 작성하지 않아도 되고 스마티처럼 register 할 필요도 없
이 바로 사용하기만 하면 됩니다. 템플릿 구문 오류에 대해서는 PHP 메세지가 아닌 자체메세지를
줄번호까지 정확하게 출력해 줍니다. 강의 주제가 스마티인 만큼 성능, 가독성, 일관성, 편의성..
편리하면 얼마나 편리한 건지, 자체 문법과 규칙이 정말 어려운 건지.. 여타 길어지는 이야기는 하
지 않겠습니다.
이렇게 이야기하긴 했지만.. 예로 든 Template_ 를 사용했을 때 작업시간이 몇 % 단축된다던가 개
발자의 엔돌핀? 분비가 상승했다던가 하는 구체적인 데이터는 없습니다. Warrenty 가 있는 것도
아닙니다. 다만.. 즐겁게 사용하시는 분들이 있고, 제법 규모가 되는 싸이트를 운영하시는 분들도
있는데.. PHPSchool 같은 곳에서 템플릿 무용론에 대한 적절한 반론이 부족하다는 것에 안타까운
나머지.. 글을 남겨 봅니다.
06/23 1:48:09
지나가는이
다~~ 장단점이 있기에 하는겁니다. 일단 해보세요!
왜 템플릿을 사용하는지... 저두 정통으로만 사용하다가.. 요근래에 사용해보니... 정말 편하다는
느낌이 들더군요 특히 개발 속도면에서... 정말 맘에 듭니다.
06/23
18:51:25
소리
물론 자기한테는 편하겠죠.
하지만 자기만이 아닌 다른 사람도 볼 필요가 있을 경우엔..??
06/24
10:20:43
xtac.net
소리// 한 두 시간만에 캐쉬까지 마스터하고 사용하시는 분도 있고 경력이 3년인데 도저히 모르겠
다며 싸이트 개발 소스를 요청하는 분도 있습니다. 두 경우의 차이는 아마도 어떤 방식이 됐든
MVC 패턴을 경험해 본 적이 있느냐인 것 같습니다. 공식메뉴얼이 있으니 새로운 환경에 쉽게 적
응하는 분들은 다른 개발자에게 피해가 될거라고 생각하지 않을 수 있겠죠. 어쨌든.. 쓰라 마라 강
요하는 것은 좋은 일 같지 않네요.
06/24
11:45:50
소리
앗.. xtac.net 이다.
예전에 자주 다니던 사이트인데. ^^
물론 잘 이해하시는 분이 있으시겠죠. 저도 잘 이해하는 편입니다.
하지만 굳이 그냥 php 로 해도 될 것을 템플릿 문법을 또 익히며
할 필요성을 못 느낀다는 거죠.
디자인을 쉽게 고칠 수 있다는 것과.. 디자이너도 만질 수 있다는 장점이 있긴 하지만..
두가지 모두 다 하는 저로는 그리 매력을 못 느껴서요. ^^
혹 모르죠. 나중에 다시 마음을 바뀔지. ^^
06/25
13:16:37
sy
근데 php를 알려고 하지않는 디자이너는 템플릿도 알려고 하지않던데요.
결국 템플릿의 목적은 거의 빗나갔다고 보여집니다.
중요한건 템플릿이 주장하는 '디자이너와의 원만한 협업을 위한 방법론' 이겠죠!
06/25
14:42:02
CF
이쯤에서 생각하건데 개발방법론이란 따로 없는 것 같습니다.
자기가 현재 위치한 곳에서 맞춰나가는 방법뿐...
이것이 현실입니다.
서로 자신이 옳다고 주장해도 결국 합의점이 없으면
개발을 할 수가 없죠.
06/26
10:30:23
인간조
템플릿을 쓰느냐 마느냐는 중요하지 않습니다.
중요한 것은 로직과 프리젠테이션 계층의 분리입니다.
06/28 4:05:19
그러니까
템플릿은 선별적으로 사용되어야 합니다.
디자이너와의 관계, 개발기간, 퀄리티 등등
06/28
10:21:20
배틀제이
대단해... 코멘이 50이 넘다니...
06/28
23:40:02
떼송이
Smarty 익히는 시간보다는, 디자이너가 php기본 언어구조를 익히는 시간 훨씬 빠를 것으로 생각
합니다.
다만 smarty의 로직을 생각하며 Smarty 코딩을 입힐 정도의 실력이 디자이너라면, 프로그래머의
길을 정말로 권유하고 싶군요.
Smarty를 보았을때 디자이너를 위한 단순 템플릿 엔진이 아닌 개발자가 쉽게 자신의 코드 유지 관
리하기 위한 유용한 해결책을 제시한 기술인것 같군요.
사실 외국에서 애플리케이션을 만든것을 보면, 우리나라 사람이 보기에는 딸리게 보이는것 같지
만 유저빌리티를 중시한 가치관의 차이라는 것을 염두해 보자면, Smarty로 프로그래머가 쉽고 정
말유용히 디자인을 바꾸어 가며 자신들의 소스를 유지 관리할 수 있겠다라는 생각이 듭니다.
Smary. 어디 그게 디자이너를 위한 템플릿이덥니까.. 프로그래머가 쉽게 디자인을 바꾸게 하는 것
이지.. ^^
07/01 1:06:18
wizzet
꼭 디자인이 빈번히 바뀌는 경우가 아니더라도 템플릿의 접근방법은 코드의 재사용(copy & paste
가 아닌)의 면에서 상당히 유용하다고 생각합니다. 꼭 smarty과 같은 템플릿 엔진을 쓰지 않더라
도 직접 템플릿을 만들어 쓰는 경우도 있더군요.
처음부터 재사용 가능한 코드를 만드는 것은 쉽지가 않습니다. 한번의 프로젝트를 염두에 둔다면
기간이 더 길어지기도 합니다. 하지만 매번 프로젝트를 끝낼때마다 장단점을 분석하고 유지보수
가 이루어진다면 개발 기간도 단축되고 더욱 질이 높은 결과물을 만들수 있으리라 생각합니다.
템플릿 엔진은 이러한 방법중에 하나라고 생각합니다. 코드와 디자인의 분리, 디자이너와의 원할
한 협업은 디자이너가 프로그래머 출신이 아니라면 상당히 힘듭니다. 저희 회사 디자이너는 프로
그래머 출신인데도 힘들더군요.
결론은 템플릿 엔진을 코드와 디자인의 분리, 디자이너와의 원할한 협업의 관점에서 볼것이 아니
라 코드의 유지보수, 재사용의 관점에서 봐야 한다고 생각합니다. 프로그래머와 디자이너의 원할
한 협업은 원할한 인간관계에 의해서 이루어지는 것이지 도구를 통해서 이루어지는게 아닙니다.
07/03
14:50:04
ssehoony
에구.. 위에 글이 많아서 다 읽지는 못했지만 이거 하나는 말씀 드릴 수 있습니다.
일단 smarty 의 캐쉬를 사용해서 웹의 포퍼먼스를 올릴 수 있습니다.(캐쉬는 다른 걸 이용해도 가
능하긴 하져) 더 중요한건
울 디자이너는 php 소스도 어느정도 수정할 능력이 되는데요
내가 smarty 템플릿 파일을 수정하도록 환경을 만들어 주고, 후에 php 를 직접 수정하는게 좋냐
템플릿을 하는게 좋냐고 물어보니깐 템플릿이 더 하기 편하다고 하더군요. 그래서 계속 템플릿을
사용하기로 디자이너와 합의를 봤져.
과정이 어떻든 목적은 document 와 view 를 나누어서 일을 편하가 하자인데 그 목적에 잘 부합한
다고 보여지네요 ^^
07/06 9:37:20
더미
스마티를 쓰고있지만, 퍼포먼스가 떨어진다고 생각도 않고, 또 개발에서 관리 유지보수가 힘들다
고 생각해본적도 없습니다.
물론 PHP코드를 마구 집어넣어 코딩하는게 개발자로써는 속편할지 모를일입니다만, 유지관리를
생각해보세요. 스마티건 뭐건 템플릿을 쓰는 이유는 HTML과 PHP의 분리에 있는거니까요.
스마티 문법익히기 어렵다고 하는데 사실 익힐것도 없습니다. 간단한 규칙몇개하고, 루프로 반복
해서 찍어내는 부분 그부분에 대한 이해만 있으면 됩니다. 템플릿들에 대한 벤치마킹은 지금까지
많이 논의되어왔고, 또 그 유용성이라던가 필요성에 대해서는 국내외 개발자모임에서 논의되어왔
습니다. 극단적으로 템플릿은 필요없는 놈이다 라는 식으로 논의를 몰고가는 것은 개발자로써는
별로 도움이 되지 못할 생각인거 같군요.
사실 그 모든 컴퓨터의 언어들이 뭐 다 필요합니까? 걍 살던대로 살면되지... 그렇지만 그런식으로
살거면 인생아무의미가 없죠.
07/19 6:50:58
더미
디자이너와 플머의 협업관계에대해서도, 위에서 몇몇분들이 말씀하셨지만, 스마티는 별로 디자이
너를 위한 것은 아닌것 같아요. 디자인 변경작업이 들어가면 보통 디자이너에게 HTML 파일만 달
라고합니다. 그리고 거기에 PHP소스는 건드리지 않고, 템플릿 파일만 새로 갱신하는거죠. 복잡하
게 PHP소스까지 건드리는 일 말구요.
07/19 7:01:37
베르사체
저는 PHP 몇년했지만, 머리가 따라주질 못해서 템플릿 자체를 적용할 엄두를 내지 못하고 있습니
다.
그것도 학습에 대한 압박이 있군요.
07/24
13:07:31
정용훈
저는 CF님 말이 이해가 갑니다. Smarty와 pearDB를 사용해서 작업해봤는데, pearDB는 많은 도움
이 되었지만 Smarty는 득보다 실이 많은것 같더군요(Smarty뿐만 아니라 템플릿형태의 작업). 그
래도 Smarty는 좋은 프로그램입니다.
07/29
17:55:29
wizzet
Smarty 사이트에 가서 Smarty가 만들어지게 된 배경에 대해서 읽어보세요. Smarty는 도구일 뿐입
니다. 도구는 만능이 아니죠. 사용하는 사람이 필요에 따라 잘 사용해야지 훌륭한 도구가 되는 것
입니다.
저는 Smarty의 개념이 상당히 좋다고 생각합니다. Smarty를 사용해서 득보다 실이 많았다면 정용
훈님의 설계 및 코딩 방식이 Smarty의 개발자와 다르기 때문입니다. Smarty 개발자와 정용훈님의
설계 및 코딩 방식중에 저는 Smarty 개발자에게 손을 들어 주고 싶군요.
07/30
11:10:32
아이구
저는 주로 Class 를 사용해서 OOP 방식으로 코딩하는데..
이런 경우에도 템플릿이 유용하겠습니까?
한번도 안써봤는데.. 저는 HTML 코드들도 함수 안에다가 다 넣어서 쓰거든요.. 근데.. 디자이너는
소스코드에 손을 못대요. 물론 그러니 덥어써서 곤란을 당할일도 없지만 아무래도 수정때마다 일
일이 손봐줘야 하는 불편함이 있어서요. 조언좀..
08/01
20:43:01
지나가던 넘
논쟁이 뜨겁군여...저는 자바 개발자로 PHP에서 요즘 뜨는 기술이나 이슈를 자바로 구현하거나 개
념적으로 자바쪽에 적용하는 등의 이유로 이곳을 방문하는데.. 제가 요즘 템플릿 관련 하여 개발
을 하고 있어서 참 잼있게 위에 글들을 읽었네여..
템플릿을 쓰면 물론 새로운 개념이니, 새로이 배워하는건 당연하구, 물론 속도면에서 약간의 손해
를 볼수 있겠죠..
물론 없다구 하다면, 속도를 높이기 위해서 캐쉬, 풀링, 폴링등을 이용하여 메모리등 자원의 리소
스 더 소비했겠죠..
어떻게든 상대적으로 소비를 할 겁니다.
그런데, 굳이 쓰고자 하는 사람들은 무엇때문에 그렇까여..
저의 경우에 템플릿을 쓰는 이유는, 저희는 자바도 쓰고 ASP도 쓰고, PHP도 씁니다. 시스템이 복
잡하게 엮여 있거든여..
하지만, 이럴경우, 디자이너가 3가지 경우를 모두 알면 좋지만, 실제 한개 하기도 벅찰수도 있거든
여..
따라서, 어떤 템플릿의 개념의 정의 및 문법 구현을 자바, ASP, PHP쪽에 모두 구현해둔다면,
템플릿 엔진을 각 언어 맞게 구현해 둔다면,
상황을 달라지죠..
시스템 변경으로 어쩔수 없이 언어의 변경이 가해진다 하여도 디자이너로 부터 일관된 디자인을
제공받을 수 있으며,
기존 PHP에서 쓰던 템플릿을 수정없이 자바쪽에서 거의 바로 적용이 가능할수 있죠.
이런 측면으로도 템플릿을 바라 볼 수 있수도 있죠..
08/19
17:38:09
나도
정말 좋은 생각인거 같습니다. ASP PHP JSP 등을 통합할수 있는 템플릿 표준이 나온다면 정말 괜
찮겠군요.
08/20
10:59:29
하늘아버지
smarty는 php로 안만들고 java로 만들었습니까?
php만으로... 라는 표현 우습네요...
성능, 효율, 편의성...
따지고 보면 그런 것들보다 개발 여건, 그동안의 습성, 이해 수준 뭐 그런 것들 때문에 지금의 개발
방법이나 라이브러리를 고수하는 것 아닌가요? ㅋㅋ
이건 안좋고 저건 안좋고...
그런 얘기 하지 마시고 솔직히 나한테 안맞더라 그렇게 얘기하세요...
08/27
20:41:24
흠.
전 template_ 가 가볍고 빠르고 좋은거 같네요..
09/13
11:34:30
아름다운 폐인
첫...index.php 소스에서...
디렉터리 설정 부분
$smarty->template_dir = '/home/warper/sm/template/';
$smarty->compile_dir = '/home/warper/sm/template_c/';
$smarty->config_dir = '/home/warper/sm/config/';
가 아닌지요?
09/14
10:27:12
-_-
누가머라고 하든 가장 중요한건 프로그래머와 디자이너의 팀웍
둘이 맘만 맞으면 충돌없이 최적의 시간과 최상의 결과 물이 나옵니다.
전 이걸 가장 중요시 했고 그렇게 결과를 얻었습니다.
(흠흠 디자이너들이 날 너무 좋아해서 탈이야..)
09/14
15:04:30
초보
사용하기 나름이지요..저 같은 경우는 프로그래밍에 디자인에 다 하다보니 HTML, PHP 같이 사용
합니다. 협업할때는 템플릿이 정말 필요한것 같아요.
09/17 1:10:30
구이
로컬에 항상 작업했던 파일을 날짜별로 백업받아두는 습관이 중요한것 같아요
10/07
11:31:51
^_^_^
자 ^^ 이제 하던일 하죠~~
10/08
13:45:55
음;;
템플릿...
일의 경계를 나누기 위한 하나의 언어라고 생각 합니다.
구분을 두기 위한 개념의 존재라고 생각 하구요..
필요한 부분도 있을수 있으며 없을수도 있겠지만,
템플릿 쪽에 앞으로 많은 발전이 있을거라 장담합니다..
smarty.php.net 이 사이트 그냥 허물은 아니거든요..
10/17 9:56:14
-_-;;;
코드가 깔끔해져요..
디렉토리가 좀 복잡해지긴 하지만..
(프로그램 따로 돌리니 좋군요.. 페이지 나느는거라든지..
디비에서 글 빼오는거랑 html이랄 같이 쓸려면 지저분해지는데..
갈결해지는거 같어..)
Posted by 나현재