애드온을 개선한 새로운 시스템으로 보이는데요.
(다이나믹)라우터를 추가할 수 있다거나 일부 모듈의 역할도 수행할 수 있을까요?
mid나 module_srl 같은건 없겠지만 라우터를 이용하면 모듈의 일부 역할도 가능할 것 같은데 라우터 를 추가할 수 있을까요?
라우터 정의가 가능하다면 mid가 없는 모듈이하던 기능을 개발 할 수 있을지, 모던하게 바뀐 애드온일 뿐인지 아직은 감이 안 잡히네요.
kkigomi
Lv. 3
댓글 4
쓰다 만 페이지이긴 하지만, 매뉴얼에 따르면 모듈과 애드온의 차이는 아래와 같습니다.
여기서 "독립적인 URL"을 act로 이해하고 (route는 act의 속성일 뿐), 애드온을 플러그인으로 치환하더라도 크게 달라지지는 않을 것으로 예상합니다. 동일한 수준의 기능을 갖는 두 가지 구조를 지원할 필요는 없지요.
물론 애드온으로 특정 요청을 가로채서 HTML이나 JSON을 뿌려 버리고 exit하는 꼼수를 쓰는 자료도 종종 보이는데, 플러그인에서도 여전히 그렇게 할 수 있을 것으로 보입니다. PHP 특성상 exit를 막을 수는 없으니까요.^^
(이게 웬 자다가 봉창 두드리는 소리인가 하시는 분들은 2.2에 적용 예정인 이 패치를 참고하시면 됩니다.)
애드온을 뛰어넘는 기능을 갖췄다는건지 그냥 애드온을 대체하는 모던한 체계라는건지 헷갈리네요.
라우트는 act의 속성일 뿐이라면 플러그인은 라우트를 추가할 수 없고, 이벤트를 가로채 응답을 강제로 반환하는 방법이라면 가능하겠지만, 일반적으로보면 모던한 애드온 이라는 것이라 보여지네요.
네, 일단 애드온의 역할을 흡수하는 것이 목표이고, 앞으로 기능이 추가될 수도 있겠지만 기본적으로는 "이벤트 핸들러의 집합"이라는 개념입니다. 모듈과는 역할이 다릅니다.
라우터의 초기화 과정에 동적으로 끼어들기에는 플러그인 로딩 타이밍이 너무 늦습니다. 그렇다고 플러그인 로딩 타이밍을 지금보다 앞당기면 Context 변수나 세션 등이 준비되지 않아서 대다수의 제작자분들이 오히려 불편을 겪을 테고요. 그래서 라우터 욕심은 내지 않으면 좋겠습니다. 처음부터 플러그인이 감히 route를?! 이라고 못박아 놓고 설계한 것이 아니라, 가장 효율적인 방법을 고민하면서 역할 배분을 하다 보니 지금 같은 결과가 나왔다고 봐야겠지요.
물론 URL 전체를 컨트롤할 필요가 없다면... 플러그인에서도 비교적 깔끔한 방법으로 API 엔드포인트 같은 것을 선언할 방법이 없지는 않아요. Response 클래스와 엮어서 확장할 방법을 생각해 두고 있습니다만... "애드온 대체"라는 주 용도가 어느 정도 자리잡을 때까지는 함구하겠습니다. (읍읍)
페이즈 1은 애드온 대체 시스템이라는거군요.🙂