그누보드를 관두고 XE로 가볼까.. 해서

라이믹스를 다시 깔아봤습니다.

저번에도 한번 깔아봤지만 그때는 그냥 관리자 메뉴만 좀 만져본 정도였는데

이번에는 어차피 이것저것 손대지 않으면 안될 상황이기에 소스도 좀 열어봤습니다.

깊게는 안파고 잠깐 살펴본 소감입니다.

구조적으로는 나쁘지 않다는 느낌입니다.

사이트를 이루는 핵심적인 부분들을 잘 분리해서 정돈한 것 같습니다.

첨에 봤을때는 잘 이해가 안가서 어려운가 했는데 이해하려고 노력하면서 보니까

생각밖에 쉽게 이해가 갔습니다. 디렉토리 구조도 손쉽게 이해가 갔구요.

모듈이라는 개념이 꽤 좋군요. 근데 트리거를 너무 의존해서 디버깅하기는

극악일 것 같은데요...

인라인 디버거로 쫓아간다고 해도.. 트리거에 뭐뭐가 걸려있는지 어디로 튀는지

일일이 추적하기가 어려워서... (트리거는 함수가 아니고.. F7누르면 STEP IN하고

그런게 아니다보니..) 예측할 수 없는 문제에 봉착하면 망할 것 같은 느낌..

이럴때는 로그에 의존할 수 밖에 없는데.. 

XE 정도 되는 규모의 소스가 의외로 공통 로그 모듈이 없는거 같은데요..?? 맞나요?

규격화된 로그를 모듈마다 뿌리게 해서 필요할때 쉽게 추적할 수 있어야 할텐데...

그런게 안보여서 약간 아쉽더군요.

그리고 인터페이스를 전혀 안쓰는 것도 좀 아쉬웠습니다.

구지 확장성이 필요없더라도 인터페이스는 소스를 읽을때 기준점이 되어주는데 말이죠..

모듈쪽이 잘 정리된거에 비해서 애드온은.. 이거 소스만 보고선 어떻게 사용하는건지

언제 호출되는건지 정말 이해하기가 어렵더군요. 

그리고 뭣보다 레이아웃등에 사용되는 html 확장자의 파일...

이거 대체 왜 확장자를 html로 한걸까요? 내부 문법은 html하곤 별 상관없어보이는데 말이죠 ^^;

이 부분은 좀 아쉽습니다..

사실 이건 구지 XE가 아니더라도 다른 프레임워크도 비슷한 경향이더라구요.

전 이런 류의 템플릿 엔진에 대해서 효용성을 좀 의심하고 있어요.

간단하게 쓸때는 직관적이고 좋아보이지만 좀 복잡해지면 감당이 안되잖아요.

속도 느린거야 당연하고 그냥 php 직접 쓰는 것보다 딱히 가독성에서 좋다고 하기도 어려워 보이는데... 

애초에 php 자체가 이런 용도로 쓰라고 만든 언어일텐데

왜 좋은 php 놔두고 자꾸 다른 템플릿 문법을 또 도입하려는지 잘 모르겠습니다.

배우기만 힘들고 크게 더 좋을 것도 없는데..

자바스크립트 쓰는 nodejs나 파이썬이야 별도의 템플릿 엔진이 당연히 필요하고

클라이언트에서 렌더링하는 angularjs 같은 것도 당연히 필요한데..

대체 왜 php가...?? 

확장자 phtml 부활시켜서 이건 뷰표시용 템플릿이다 하고 구분하면 관리도 간단할거 같은데 말이죠...

물론 템플릿 엔진으로 php 쓰면 전역변수로 데이터 주고받아야 해서 관리가 어렵다고들 하는데

그거야 약간의 규격화된 제약으로 해결되는데 말이죠..  저같은 경우엔 phtml 안에서는

function으로 감싸두고 호출을 require 같은게 아니라 function 호출로 하는 것만으로도

데이터 건네주는걸 함수 파라미터로 관리할 수 있어서 간단하던데...

진짜 XE 자체 템플릿 엔진만 아니어도 개발 난이도가 뚝 떨어질 것 같은데 아쉽습니다.

또 새로운걸 배울 엄두가 안나네요... 템플릿 엔진은 이제 그만.. 흑흑... 

아 그리고 아쉬운 점은.. composer가 적용되어 있던데 기왕 적용된 김에

composer 부트스트랩처럼 php 소스들하고 public 디렉토리를 구분해서

소스를 완전히 숨겼으면 더더욱 깔끔했을거 같다는 생각입니다.

그럼 __XE__ 이런거 체크 안해도 될텐데 말이죠...

 

  • profile

    라이믹스는 XE 구조와 최대한 비슷하게 유지하면서 점진적으로 새 기술을 도입하려다 보니 구조가 많이 복잡합니다. 모듈이나 애드온 등은 XE와 공통이고, classes 폴더는 XE 호환성 유지를 위해 남겨두었지만 점점 껍데기만 남아가는 중이고, 깔끔하게 정리한 기능은 대부분 common/framework 폴더 쪽에 집중되고 있어요.

     

    XE의 트리거 시스템은 IDE로 디버깅하기에는 최악이지만 CMS로서의 확장성을 고려하면 꽤 괜찮은 선택입니다. 특별히 느린 트리거는 라이믹스 디버그 패널을 사용해서 확인할 수 있고, 그냥 목록을 추출하고 싶으시면 Rhymix\Framework\Debug 클래스를 사용하시면 됩니다. (디버그 클래스에서 로그를 수집할 수 있도록 준비는 되어 있는데, 모듈들이 로그를 생성하질 않습니다 ㅎㅎ) 문제는 애드온이죠. 특정 함수를 호출하는 게 아니라 그냥 인클루드하기 때문에 답이 없습니다;; 그래도 너무 느린 애드온은 디버그 패널에서 트리거와 함께 볼 수 있습니다. 애드온도 일종의 트리거라...

     

    인터페이스는... 음... XE 처음 나왔을 때는 그런 거 없었어요. PHP 4.4부터 호환되던 물건이라...ㅋㅋㅋ 라이믹스는 메일, 캐시, SMS 등의 서드파티 드라이버 지원을 위해 인터페이스를 사용하는 곳이 몇 군데 있습니다. 앞으로 DB 드라이버, 트리거, 모듈, 위젯 등으로도 점차 확대해 나가야지요.

     

    composer는 라이믹스에서만 쓰는 거고요... 국내 대부분의 웹호스팅에서는 public 디렉토리를 따로 빼낼 수 없기 때문에 굳이 숨기려고 하지 않습니다. (해외 프레임워크들은 웹호스팅 따위 무시하고 개발합니다. 거긴 개발자라면 최소한 VPS는 쓸 줄 알아야 한다는 문화라...) 게다가 모듈, 애드온 등에 CSS, JS, 이미지 파일 등을 포함시켜 배포하려면 설치 경로에 웹에서 접근할 수 있어야 하지요. 소수의 개발자들이 구동 환경을 100% 컨트롤하는 프레임워크가 아니라 일반 사용자가 플러그인을 자유롭게 설치하여 사용하는 CMS라는 점을 기억하셔야 합니다.

     

    일반 사용자의 편의를 증진하기 위해 해외 프레임워크 개발자들이 주장하는 best practice를 고의로 위반하는 부분이 많습니다. 이건 라이믹스에서도 바꿀 생각이 없습니다. 실제로 큰 불편을 주는 문제점이 있다면 개선해야겠지만, 단지 개발자들 사이에 유행하는 방법이라는 이유만으로 개발자 편의주의적인 개념을 마구 수입해서는 안됩니다. 그럴 바에야 라이믹스 집어치우고 그냥 라라벨이나 심포니 기반으로 직접 만들어 쓰지요.

     

    사실 지금도 애드온 외에는 __XE__ 상수를 체크할 필요가 없습니다. 대부분의 모듈과 위젯 쪽 .php 파일들은 직접 호출하면 상속받을 클래스가 없어서 그냥 에러뿜고 종료되니까요. 제로보드 시절처럼 개별 파일을 직접 호출하면 이상하게 동작하는 경우는 극히 드뭅니다. 라이믹스는 XE와 달리 __XE__ 상수를 선언하지 않고 config.inc.php를 인클루드해도 정상 작동합니다.


    템플릿은 일단 컴파일해서 .php 캐시파일로 만들어 놓으면 opcache가 알아서 가져가기 때문에 그냥 인클루드하는 것과 속도 차이가 전혀 없습니다. PHP 자체로 템플릿 언어의 기능을 할 수는 있지만, <?php echo $var ?> 이게 그다지 편리한 문법은 아니지요. 다들 {$var}로 쓰고 싶어하는 이유가 있어요...

     

    물론 템플릿 문법 쓰기 싫으면 확장자만 .html로 놔두고 그냥 PHP 코드를 때려박아도 되긴 합니다 ㅎㅎ

     

    라이믹스에서는 XE의 템플릿 엔진을 확장해서

      {$var|escape} : 변수에 htmlspecialchars() 적용

      {$var|lower|urlencode} : 소문자로 변환한 후 urlencode() 적용

      {$array|join:,} : 배열을 쉼표로 구분하여 출력

      {$time|date:Y.m.d} : 유닉스 타임스탬프를 년.월.일 포맷으로 표시

    등 다양한 문자열 변환 기능을 제공하기도 합니다. 10년 전에 제가 쟝고 배울 때부터 엄청 부러웠던 기능...! 변수를 출력하는 곳마다 (따로 예외처리한 곳은 제외하고) 모두 자동으로 htmlspecialchars() 적용을 해서 XSS 공격을 원천봉쇄하는 autoescape 문법도 있습니다. 그냥 PHP로 뿌려버리면 이런 걸 못하죠.

  • ?
    그누보드는 배우기 쉽나요..
    감이 전혀 안옵니다ㅠㅠ
  • profile

    다른건 몰라도 XE 템플릿 엔진은 제 입장에서는 꽤 편했습니다. 초보자들의 접근성이 조금 더 높다고 생각합니다. 기본적으로 ul.class > li(5) 와 같은 emet 플러그인으로 편하게 디자인 작업이 가능하다는 점과 php 코드와 html 코드가 분리되어 있다는 느낌이 강해서 굳이 php 문법을 배우지 않아도 작업할 수 있다는 점 때문에 좋았습니다.

    제가 그누보드로 디자인 작업을 할 때 가장 불편했던게 <?php echo $var ?> 이 문법입니다.
    특히 아래와 같은 경우를 처음 접했을 때 멘붕이 왔던 기억이 납니다.
    <?php echo "<ul class=\"sct sct_pv\">\n"; ?>

    정규 표현식인가, 그냥 표현식인가, 이름은 잘 모르겠지만 php에서 굉장히 중요한 부분이라고 하던데 이해도 잘 안되고 일단 따옴표가 많아지기 시작하면 다 떠나서 너무 불편합니다. 가독성 극악에 머리가 터질 지경입니다.

    물론... XE의 템플릿 엔진도 막상 php 코드를 작성하다보면 헷갈리거나 불편했던 점이 있었습니다. 특히 foreach나 조건문을 쓰다보면 가독성이 심각하게 떨어집니다. 일단은 얘네가 주석이다보니... 에디터에서는 회색으로 밖에 안보이거든요. 코드의 구분감이 너무 없습니다.

    결국은 케바케인 것 같아요. 디자인 위주로 작업하는 저같은 경우는 XE 쪽이 더 편하지만 정교하고 논리적인 코딩을 많이 하시는 분들에게는 그누보드 쪽이 더 편할지도요.

  • profile
    템플릿 엔진이 어려운건 아니지만, 항상 새로운걸 배운다는건 귀찮은 일이죠.
    그런 의미에서 템플릿 엔진에 대한 지적은 공감할 부분도 있을꺼 같습니다.

    물론 효용성이 없다거나 느린건 절대 아니구요