화면 캡처 2022-07-30 183706.png

https://www.poesis.org/tools/modulegen/

 

몇 달전에 이 존재를 알게되고, 이번에 새롭게 모듈을 만들 일이 생겨서 사용해보게 되었습니다.

 

라이믹스 2.1 이상이라고 되어있지만, 사실상 지금 버전에서도 정상적으로 작동합니다 ㅋㅋ

 

 

일단 파일 구조가 많이 달라졌는데, 최신 트렌드를 따라가는게 보입니다

 

가장 크게 달라진 점은 여러개의 컨트롤러와 여러개의 모델을 생성할 수 있다는 점입니다

 

화면 캡처 2022-07-30 183933.png

 

먼저 아래와 같이 용도에 따라 모델을 분류할 수 있습니다

화면 캡처 2022-07-30 184042.png.jpg

 

위 클래스는 제가 만든 CRUD Generator로 만든 클래스입니다

 

사용할때는 Transaction::insertTransaction($obj) 이렇게 쓰면되니까 기존과 크게 달라진 부분은 없는데

 

용도에 따라 모델을 분류할 수 있으니, 정리도 잘되고 개발하기 한층 편리해진거 같습니다

 

 

특히 컨트롤러에 엄청난 개선이 있더라고요

 

view.php와 controller.php에 모든것을 우겨넣어야 했던 기존과 달리, 여러 파일로 구성할 수 있도록 개선되었습니다

 

화면 캡처 2022-07-30 185020.png

 

그리고 이렇게 한 컨트롤러 파일에 view와 controller 구분 없이 넣어둘 수 있으니, 원하는 분류에 맞춰 컨트롤러를 구성할 수 있어서 편리해 졌습니다

 

 

 

존재를 알고 계셨던 분들도 계셨을테고, 이번에 처음 알게되신 분들도 계실텐데

 

한번 체험해보면 이전 버전으로 못돌아갑니다 ㅋㅋ

리버스

profile
모듈 제작하는 현역 대학생 리버스입니다!

== 판매중인 모듈 ==
미션] https://xetown.com/thirdparties/1511787
길드] https://xetown.com/thirdparties/1387146
  • profile
    module.xml 파일이 핵심입니다.

    거기에서 지정한 class 을 따라 가도록 설정이 가능한데요.

    네임스페이스 기능 특징이 그냥 일반적인 PHP처럼 구조화시켜서 모듈을 만들 수 있다는게 핵심입니다.

    그러면서 라이믹스의 proc disp 다 요청할 수 있고, 풀더 구조는 본인이 원하는대로 막 짤 수 있고요.
  • profile profile

    그것도 찍어 올린다고 생각하고 까먹고 있었네요

    폴더 구조도 원하는대로 짤 수 있다니 대단하네요 ㄷㄷ

  • profile profile
    그냥 PHP처럼 코딩하면 되고, module.xml 파일 만들때만 잘 연결해서 하면되요.

    proc disp 액션 모두 원하는 폴더 아무폴더에 막 넣어두됩니다.

    그래서 이런구조화도 가능합니다.


    shop/payment/inisis.php
    shop/product/product_list.php

    뭐 이안에 proc disp 액션 다 때려박을 수 있죠.

    실제로 module.xml 내에 모든 클래스 항목만 잘 넣으면되니까요 ㅋㅋ
  • profile
    컨트롤러 파일이 너무 길어져서 고민이었는데 한번 써봐야겠네요
  • profile profile
    저도 그 문제때문에 사용해본건데, 대만족입니다! ㅎㅎ
  • profile

    클래스 파일이름은 클래스 이름과 완전히 똑같아야(대소문자 구분) 합니다. 그렇게 합의되었으며, 실제로 next 브랜치에서는 대소문자를 구분하지 않으면 오류가 발생합니다.

  • profile profile

    next 브랜치 기준, 소문자로만 이루어진 파일명은 허용합니다. 대소문자 모두 일치하는 버전을 일단 찾아보고 없으면 소문자 버전을 로딩하기 때문에 살짝 비효율적일 뿐... 이놈의 하위호환성... ㅋㅋㅋ

  • profile profile
    오류가 나긴 났던 것 같은 데 지금 보니 아니네요. 헷갈렸나 봅니다;;
  • ?

    훌륭합니다.
    저는 model+controller 겹친다 싶으면 그냥 class 파일에 메소드 선언해 왔습니다.
    생각만 했던 불편함이 깔끔하게 구현되었네요.

    2가지 호기심이 생기긴 합니다.
    1. 개발자가 함수 내에서 require(__DIR__ ... __FUNCTION__ . '.php'); 비스무리한 추잡한(-_-)방식으로 성능과 호환을 잡음.
    2. 최신 rhymix 에서 작동하니 php 버전도 최신을 바라볼테고, 그렇다면 한 파일에 코드를 몰아넣든 그렇지않든 JIT 환경에서의 성능 잇점은 그닥 크지 않을 것 같단 생각.

    10년 전 Core 에 이런 것이 있어야 했었는데, 지금은 소프트웨어와 하드웨어가 많이 발전해서 현 시점에는 이게 무슨 소용인가 싶습니다,, 타이밍이 아쉽네요. 꼭 필요한 기능이 너무 늦게 나와서 아쉽다는 뜻입니다.
    글 쓰면서 생각하니 7.x php 호스팅에는 꽤 효과적일 것 같네요.
    다만 제 경우 (위에 언급해주신 단어) '하위호환성'을 중요하게 생각해서 되도록 xe 호환을 고려할 때 이 훌륭한 기능은 조심스레 활용 하겠습니다. (아마 저는 안 쓸겁니다 -_-;;; 하지만 다른 분들은 써주시길)


    한국 웹 생태계 발전에 큰 공언 하시는 곰님에게 박수를.. ^^

  • ? profile

    그나마 지금이라도 나와서 새로 개발하는 모듈에서 사용할 수 있다는게 다행인거 같습니다.

    사실 개발 트렌드를 따라가다보면 말씀하신 두가지 호기심이 해결되는거 같습니다
    이전에는 1번과 같은 방식으로 개발을 많이 진행했지만, 요새는 오토로딩을 활용하면 자동으로 원하는 PHP파일을 불러오게 할 수 있으니 굳이 저 방식을 사용할 필요가 없겠죠. (사실상 저걸 대체하는게 오토로딩이네요)

    그리고 저 형태의 모듈은 옛날 방식으로 생각해보면 성능이 더 떨어져야하는게 맞습니다. 파일 하나 불러오면 될 것을 굳이 여러개로 나누어 놓았으니 말이죠.
    그러나 2번 호기심을 답변해보자면, 저 방식은 성능의 이점 보단 개발의 이점이 더 크다고 봅니다.
    모듈 개발해보셨다면 아시겠지만 조금 큰 모듈을 만든다면 컨트롤러 파일이 수백수천줄로 늘어나는게 일상 다반사입니다. 이걸 용도 별로 분류해서 작게 나눠주면 한눈에 들어오는 코드를 짜기도 편리하고, 유지보수할때 코드 찾는데 시간을 보내지 않아도 되죠 ㅎㅎ

    특히 모듈이 커질 수록 이 구조를 활용하면 기존 구조보다 더 빠르고 메모리 덜먹게 만들 수도 있습니다. 실행 할때마다 모든 함수를 불러오는게 아니라 필요한 부분만 불러오니까 말이죠



    아무튼 곰님께서 여러가지 고민하셔서 이 기능을 만들어 주셨는데, 라라벨과 같은 최신 PHP 프레임워크를 따라가면서 점점 발전해가는 라이믹스의 모습이 보기 좋습니다. 

    이렇게 점차 발전해나가서 타 PHP 프레임워크를 활용하는 개발자가 라이믹스에 접근하기 쉬운 환경을 만들면, 언젠가는 옛날 엔진이라는 오명도 벗을 수 있게되는 날이 오지 않을까 상상해봅니다 :D

  • profile profile

    네, 성능 면에서는 opcache 덕분에 파일이 1개든 10개든 더이상 큰 차이가 없습니다. 순전히 개발과 유지보수 편의를 위한 변경이지요. 최악의 경우 1만 줄이 넘는 컨트롤러 파일도 본 적이 있는데, 이건 뭐 하나 찾기가 너무 힘듭니다...

    다른 프레임워크의 MVC 구조에 익숙한 개발자들이 라이믹스에 쉽게 적응할 수 있기를 바라는 마음도 있습니다. XE의 view는 사실상 view controller의 역할을 하는데, 라라벨이나 코드이그나이터 등 대부분의 다른 프레임워크에서 view는 곧 템플릿을 의미하거든요. *.view.php에 들어 있는 코드는 원래 다 controller에 넣는 것이 일반적이라는 얘기지요. XE만 다르니까 처음 접하면 굉장히 헷갈립니다.

     

    그렇다고 *.view.php의 내용을 모두 *.controller.php에 넣어 버리면 파일이 더 비대해지겠지요. 그래서 controller를 여러 개로 쪼갤 수 있도록 지원하려고 하다가, 내친 김에 다른 프레임워크처럼 controllers, models, views 3개의 폴더로 싹 정리해 버렸습니다. 스킨을 따로 지원할 필요가 없는 모듈이라면 skins나 tpl이 아닌 views 폴더에 템플릿을 넣으면 되고, 트리거도 일반 액션들과 섞이지 않도록 따로 모아둘 수 있지요.

    model을 여러 클래스로 분리하는 것도 나름 쌈박하게 응용할 방법이 있어서 기대중이예요. executeQuery의 $output->data는 stdClass로 나오는 것 아시지요? (결과가 여러 개라면 stdClass를 배열에 담아서 반환) 그런데 마지막 파라미터를 변경하면 임의의 클래스로 나오도록 할 수 있습니다. Models\Foo에서 getFoo 쿼리를 하면서 결과를 self::class에 담도록 한다면? 쿼리 결과가 Foo의 인스턴스로 나옵니다. 곧바로 $foo->bar() 메소드를 호출하여 $this->foo_srl 등의 속성을 참조할 수 있겠지요. 마치 DocumentItem이나 CommentItem처럼요. 간단한 ORM의 역할까지 할 수 있는 셈입니다. 해당 타입을 담당하는 클래스가 따로 선언되어 있으니 가능한 일이지요.^^

  • ? profile
    XE 호환을 고려하실 필요가 없도록 + XE 호환되도록 만들려고 하면 오히려 손해보는 상황으로 만들어 가는 것이 목표입니다. 식물인간 상태에 빠진 지 3년이 다 되어 가는데 아직도 (사람들 마음 속에서) 안 죽고 있으면 얼굴에 베개를 덮어서라도 숨통을 끊어야지요. 😈