과연 php는 무엇이란 말인가? 보통의 웹페이지는 html 로만 이루어지게 되어 있는데, 이런 페이지는 서버에 있는 자료를 일방적으로 가져 오게 됩니다. 그래서 웹서버에서 사용자의 입력을 받아서 처리하는 방법을 필요로 하게 되었는데, 그것이 CGI 입니다. 즉 우리가 하는 검색이라든지, 지금 노스모크에서 글을 쓴것이 바로 다른 사람이 볼 수 있게 되는 등등의 처리를 위해서 브라우저 상에서 사용자가 입력한 것을 전송하면 웹서버는 그 자료를 처리하기 위한 지정된 프로그램을 실행하게 되고, 그 프로그램이 입력 내용에 상응하는 결과 페이지를 만들어 내서 사용자에게 보여주는 구조가 바로 cgi입니다.
이러한 구조의 문제점은 첫째, 요청이 있을 때마다 프로그램을 실행시켜야 한다는 점이고, 둘째, 프로그램 자체에서 결과 문서를 전부 출력해 주어야 된다는 점입니다. 이러한 점을 보안해서 프로그램(프로세서)를 계속 실행시키지 말고 웹서버에서 직접 쓰레드(보다 작은 프로그램)로 처리해주고, html 문서를 쓰다가 특정한 문법을 통해 필요한 출력들을 끼워 넣는 방식 등이 고안되었습니다. 바로 php가 두가지 특징을 모두 가집니다. 따라서 php를 이용해서 웹 프로그래밍을 하게 되면 PerlLanguage이나 PythonLanguage등을 이용한 cgi프로그래밍 보다 빠른 속도로 보다 편하게 프로그래밍을 할 수 있습니다. 물론 펄이나 파이썬 등도 cgi로 돌리지 않고 쓰레드로 돌리는 방법도 있습니다.
sql은 데이터베이스와 "사용자 혹은 다른프로그램" 사이의 의사소통을 위한 언어 입니다. 'INSERT wiki INTO no-smok' 이러한 형식의 문장을 통해 데이터베이스를 명령하는 것입니다. php를 이용해서 데이터베이스에 접속하고 sql문장을 통해 데이터를 처리할 수 있습니다.
그리고, php는 거의 모든 플랫폼에서 사용가능합니다. 윈도우즈는 물론 리눅스와 FreeBSD를 포함한 대부분의 유닉스에서 사용 할 수 있으며, PhpLanguage로 만든 위키엔진도 많습니다.
추가로 php는 웹프로그래밍에 있어서 가히 놀라운 생산성과 더불어 플랫폼도 거의 타지 않는 중소규모에서 특히 좋은 성능을 내는 웹서비스를 만들 수 있는 걸로 널리 알려져 있죠.. .png ":)")
물론 thread 나 기타 어플리케이션 프로그래밍 랭귀지에서 지원되지 않는 것들이 있긴하지만, connection pool문제도 포함. (tick함수로 thread를 임시로 대체가능했던 기억인데 2년전 기억인지라..;; )
물론 thread 나 기타 어플리케이션 프로그래밍 랭귀지에서 지원되지 않는 것들이 있긴하지만, connection pool문제도 포함. (tick함수로 thread를 임시로 대체가능했던 기억인데 2년전 기억인지라..;; )최근엔 pear, GTK, java와 섞어서 사용가능한 것이라던가(sayclub), XML지원도 libxml, expat 등을 2년전부터 지원했고, PRAX API, sablotron, xml-rpc 등도 다양~~하게 지원합니다. PhpWiki는 sourceforge에 있는걸 다운받아서 pear부분과 템플릿부분 부분만 손봐주면 금방 사용 가능합니다. php에 익숙한 사용자는 php로 가능한 건 뭐든 빠른시간내에 할 수 있다란 얘기를 할 만큼, 웹스크립트 언어의 편의성만큼은 매우 뛰어납니다.
내가 생각하는 php ¶
약 두달여동안 학생들에게 php+MySQL에 대해 가르쳐야만 했던 때가 있었습니다. 강의 시작을 일주일 앞두고 명색이 강사라는 작자가 php가 뭔지 전혀 몰랐었기에... 흐흐흐... 하루 두시간정도 투자한다면 프로그램이나 뭐 이딴거 전혀 모르는 초보자라도 개념잡고 MySQL연동의 간단한 게시판 만들기까지는 보름, 간단한 쇼핑몰의 구현정도라면 대충 한달정도면 충분히 익힐 수 있을겁니다. 물론 어느정도 웹이란 녀석에 익숙하다는 가정하에... - 하지만, 그 이상의 것을 바란다면 php만으로는 조금 벅찰지도 모르겠습니다. --nobody
LinuxdocSgml/PHP-HOWTO
AnswerMe그 이상의 것이라면 구체적으로 어떤 것들을 말씀하시는 것인지요? -- 프로그래밍 문외한 ChatMate
Please see 30만줄 이상의 프로그램은 PHP를 사용하지 말라는 말이 있더군요. 이러한 단점은 PerlLanguage로 프로그래밍을 할때도 적용이 될 것 같습니다. JSP나 Python등의 방법이 적절한 해결책이 되겠지요. 하지만 일반적인 웹 사이트의 운용에서는 그런 점을 느끼지 못할것 같습니다. .png ":-)")
--씨엔
저 같으면 30만줄 정도까지 늘어 나면 아예 코드 최적화를 해 버려서 반 정도 줄여 버릴 것 같습니다. (그런 프로그램을 만들 것 같지도 않지만) --토끼군
--씨엔저 같으면 30만줄 정도까지 늘어 나면 아예 코드 최적화를 해 버려서 반 정도 줄여 버릴 것 같습니다. (그런 프로그램을 만들 것 같지도 않지만) --토끼군
LinuxdocSgml/PHP-HOWTOPHP is a just script language, no more no less. Don't:
- Try to write OO program. Do not expect anything about destructor (at least with PHP 4.2.x)
- Expect web server will initialize PHP extension modules just once (at least with Apache 1.3.x)
- Complain about its documentation (especially undocumented side effects!). PHP is not a real programming language. --LispM
최근에는 웹어플리케이션이 점차 복잡화되고, 출력과 로직의 분리를 위해 Template을 이용한 간접출력 방식이 다양하게 고안되면서, 처음 PHP에 강한 인상을 주었던 HTML에 임베드되는 장점이 의미를 잃은 것 같습니다. Java의 JSTL이라든가 PHP의 Smarty 같은 최근의 지능적인 템플릿 엔진들은 디자이너들이 쉽게 이해할 수 있는 간단한 제어구조와 다차원 변수까지 지원을 하면서 로직단에서의 출력물에 대한 고민을 상당 부분 해소해주고 있습니다. HTML-Embedding의 장점이 사라진 환경에서는 라이브러리의 미성숙, 언어 확장에 대한 제약이 많은 PHP가 크게 어필하기 힘들 것 같습니다(물론 PHP에도 Extension API가 있긴 하지만). Perl이나 Python 같은 언어에서는 런타임-엔진을 디폴트 옵션으로 한 번 설치하면 그후의 확장은 대부분 외부 라이브러리만으로 가능한데, PHP에선 매뉴얼에 나와있는 함수 중 쓸만하다 싶은 것은 컴파일시 옵션에 들어있어야 하는 경우가 많습니다.
현재 웹프로그래밍의 대세는 자바와 닷넷이지만, 웹서버의 SAPI(Server Application Programming Interface)를 통해 프로세스 호출에 대한 부담을 덜고, 잘 구성된 프레임웍을 사용하는 PerlLanguage, PythonLanguage 같은 범용적 언어들에 비해 장점이 없을 것 같습니다. 물론 국내의 경우에는 워낙 PHP가 강세이고, 후발 언어로써 다른 언어의 장점을 차용하여 계속 진화할 여지가 있기 때문에(특히 PEAR가 제시하는 OOP와 CPAN의 장점을 취합한 표준적 프로그래밍) 적은 비용으로 빠르게 개발하는 것이 관건인 중소규모의 웹환경에선 그 영향력이 크게 약화되진 않을 것 같습니다. 하지만 프로그래머 입장에서 개발 영역이 웹환경으로 제한되는 문제가 있어 답답한 것은 쉽게 개선되지 않을 것 같습니다. 그리고 고급문서, 고급개발자가 너무너무 빈약한 것도 큰 문제입니다. --nohmad
현재 웹프로그래밍의 대세는 자바와 닷넷이지만, 웹서버의 SAPI(Server Application Programming Interface)를 통해 프로세스 호출에 대한 부담을 덜고, 잘 구성된 프레임웍을 사용하는 PerlLanguage, PythonLanguage 같은 범용적 언어들에 비해 장점이 없을 것 같습니다. 물론 국내의 경우에는 워낙 PHP가 강세이고, 후발 언어로써 다른 언어의 장점을 차용하여 계속 진화할 여지가 있기 때문에(특히 PEAR가 제시하는 OOP와 CPAN의 장점을 취합한 표준적 프로그래밍) 적은 비용으로 빠르게 개발하는 것이 관건인 중소규모의 웹환경에선 그 영향력이 크게 약화되진 않을 것 같습니다. 하지만 프로그래머 입장에서 개발 영역이 웹환경으로 제한되는 문제가 있어 답답한 것은 쉽게 개선되지 않을 것 같습니다. 그리고 고급문서, 고급개발자가 너무너무 빈약한 것도 큰 문제입니다.
--nohmadTemplate 방식 VS 임베딩 방식 ¶
AnswerMe 처음 공부할때는 임베딩 방식을 사용했지만, 수정의 편의성, 단축성을 생각해서 지금의 거의 Template 방식에 의존하는 편이다. 하지만, 디자이너는 기존의 임베딩 방식이 훨씬 편하다고 하며 - 물론, 그 디자이너는 임베딩 방식으로만 해왔었다 - 문제를 제기해 오고 있는 상태다. 과연 어떤길을 택하는 것이 좋을까? --야수
DeleteMe Embeding 방식도 그 designer가 처음 시작할때는 어려웠을껍니다. 익숙하기 때문에 기존의 방식이 편한것이지, 기존의 방식이 좋기 때문이 아니지요. 아무리 좋은 개념이라도 그걸 잘 활용할수 있기까지는 시간과 노력이라는 댓가를 치러야 하는 법입니다. 그 designer의 말은 새로운걸 배우는게 귀찮다는 말입니다. Designer라는 사람들은 page를 예쁘게 design하는데 관심이 있는 사람입니다. 즉, web application 또는 web site가 잘 설계되고 유지보수 및 재사용이 용이하게 만들어지는 데는 관심이 없다는 말입니다. 그러므로 설계, 유지보수, 재사용의 관점에서 designer를 설득하십시오.