관리자 페이지의 표준화, 정규화

"애드온이나 레이아웃이 사용하는 info.xml을 일부 채용하는 방향"에 대한 코멘트라고 이해하고 답변드리자면,

아예 별개의 관리자 페이지용 클래스 등을 제공하여 구조화된 데이터만으로 관리자 페이지를 구성할 수 있도록 하기-의 의미였습니다.

```

// AdminController.php

class AdminController extends Module {

    public function dispDummyAdmin() {

        return ModuleAdminModel::buildNewAdmin(__DIR__ . '/admin.yaml');

    }

}

// admin.yaml

menus:

- path: appuser

   name: 유저 조회

- path: appuser/{{id}}

   name: 유저 상세

   placement: page-only

pages:

- path: appuser

   class: container

   blocks:

      - type: markdown

        content: |

            https://www.selectfromuser.com/ 의 문법을 그대로 작성해봄.

            라이믹스의 컨셉에 맞게 적절한 선을 찾아야 할 것.

```

위 코드처럼 관리자 페이지를 선언하는 세팅파일만 작성하면 라이믹스가 알아서 관리자 페이지를 만들어주는... 뭐 그런 느낌으로요.

관리자 페이지 구성의 자율성은 많이 떨어지겠지만,

통일성있는 UI/UX를 제공해줄 수 있고, 서드파티는 특정 메뉴, 페이지, 블럭에 안전하게 끼어들 수 있겠지요.

```

function triggerBeforeRenderNewAdmin ($obj) {

  if ($obj->page->path !== '/board/additional-config-blah') {

    return;

  }

  $obj->page->blocks[] = (object) [

    'type' => 'block',

    'content' => [ ... ]

  ];

}

```

같은 식으로 언급하신 게시판의 추가 설정 화면에 통일성있는 디자인으로 새로운 내용을 추가해줄 수도 있는거죠.

위 댓글은 일단 info.xml (또는 yaml)을 활용하자는 제안과는 관련이 없고, Blade 컴포넌트를 composer로 설치해서 쓴다는 제안에 대한 코멘트였습니다. 자유도가 높아지는 만큼 파편화가 심해질 수 있고, 폼 관련 컴포넌트야 어차피 뻔하다 보니 서로 유사한 컴포넌트를 각자 수정해서 쓰다가 충돌할 가능성도 높아집니다.

물론 서드파티 자료가 커스텀 디자인을 사용하겠다는 것을 막을 수도 없고 막아서도 안 되겠지만, 굳이 코어에서 "각자 쓰고 싶은 컴포넌트 들고 와"을 권장하는 듯한 구조를 택할 필요는 없다는 거죠. 제작자분들이 믿고 쓸 수 있는 디폴트가 코어에 포함되어 있어야 하고, 그것을 어떤 문법으로 끌어다 쓰느냐는 다른 문제입니다.

컴포넌트화 기능 제안은 커스터마이징을 고려하지 않은 제안이었습니다.

커스터마이징은 info.xml 을 도입했을 때에만 기대할 수 있는 장점...

컴포넌트: 6-8문단만 / info.xml: 9-11문단만으로 분리해 별개의 다른 방향성으로 인지하고 읽어주시면 되겠습니다.

이 밑으로는 info.xml과 외부 조작 관련 내용은 완전히 배제하겠습니다.

---

컴포저 패키지를 이야기한 이유는, 오히려 코어 버전이 올라 관리자 페이지의 UI가 완전히 변하더라도 하위 호환성을 지킬 수 있는 방향이 되지 않을까 해서였습니다. 서드파티들이 패키지를 이리저리 만들어 커스터마이징하는 목적보다는, 공식 컴포넌트를 별도의 패키지로 분리하자는게 주 논지에요.

1. 코어 CSS에 영향을 받지 않는 새로운 클래스 체계를 도입해 독립적으로 작동할 수 있는 공식 컴포넌트를 제작

2. CI/CD를 사용해 자동으로 클래스명에 버전 prefix를 붙여 packagist 배포

3. 사용자는 원하는 버전의 패키지 rhymix/admin-component@2.2.0를 설치해 사용

4. 이후 라이믹스 3.0 버전이 관리자 페이지가 부트스트랩이 아닌 블라블라UI 기반으로 변경한다 하더라도, 사용자는 독립적으로 작동하는 2.2.0 패키지를 설치해 사용하고 있으므로, 화면이 깨지지 않음

5. 또 사용자가 rhymix/admin-component@3.0.0을 설치해 사용하더라도, 마찬가지로 독립적으로 작동하므로 2.2.0에서도 깨지지 않고 출력됨

코어에 남는 레거시는 지금까지의 것으로 한정하고,

이후 추가 도입될 것들은 별도 패키지로 분리해 코어를 깔끔하게 유지하면서도 하위/상위 호환성을 보장할 수 있다는 것이죠.

물론 이렇게 되면 확실히 "믿고 쓸 수 있는 디폴트가 코어에 포함"되지 않는다는 문제가 존재하고,

또, 같은 CSS 파일을 여러번 컴파일 하는 등 성능 상 문제가 존재하겠지만...

믿고 쓸 수 있는 디폴트를 코어에 포함시키는 만큼

코어의 프론트엔드 파일들이 점점 비대해지거나, 하위 호환성 때문에 관리자 페이지의 개편이 한도 끝도 없이 미뤄질 수 밖에 없지 않을까 싶습니다.

또, 같은 CSS 파일을 여러번 컴파일하는 문제는

같은 해시의 파일은 경로가 다르더라도 여러번 컴파일 하지 않도록 하거나, 별도의 버전별 에셋 관리 클래스를 하나 둬서 해당 클래스가 에셋을 불러오도록 처리하면 회피할 수 있을거구요.

아, 저는 컴포넌트는 무한 커스터마이징이 가능하고 info.xml과 유사한 방식이 오히려 자유도를 낮추는 것이라고 이해했는데, 네모님은 정반대로 생각하고 계셨군요.

라이믹스 3.0이나 4.0에서 일부 모듈만 2.2 버전의 관리자 화면 스타일로 박제되어 있는 것을 원하는 분이 얼마나 될지 모르겠습니다. 라이믹스 생태계는 한 번 만들어 놓고 수 년간 방치하는 자료가 대부분이고, 웬만하면 그렇게 방치해도 괜찮다는 것이 라이믹스의 장점 중 하나이다 보니 ㅋㅋ 실제로 일어날 가능성이 매우 높은 시나리오입니다.

만약 관리자 화면의 전반적인 UI/UX가 바뀐다면, 기존 모듈들의 관리자 화면도 (불가피한 사정이 없다면) 새 스타일에 어울리는 모습으로 나오기를 기대하는 것이 더 상식적이고 일반적인 기대치 아닐까요?

댓글을 몇 번에 나누어 쓰셔서, 가장 내용이 많은 곳에 답글 답니다.

- 관리자 페이지에 완전히 새로운 UI/UX를 도입하더라도 .x_control-group .x_controls 같은 기존 클래스명을 사용하는 서드파티 모듈 설정 화면에도 최소한의 스타일은 입혀 주어야 하기 때문에, 부트스트랩이 아니더라도 해당 CSS 선택자들이 완전히 깨끗해지기는 어렵습니다. 기껏해야 "나는 그런 거 필요없으니 빼줘!"라고 선언할 수 있도록 해드리는 정도?

- 이런 문제가 재발하는 것을 막기 위해, 관리자 모듈 리뉴얼시 어떤 버전의 부트스트랩도 사용하지 않을 생각입니다. 따라서 이미 있는 쓰레기만 prefix로 회피하시면 앞으로 또다른 문제가 생길 일은 없을 겁니다.

- jQuery 대체 얘기는 왜 나온 건지 모르겠습니다. 무엇을 쓰든 jQuery를 대체하는 것이 아니라 추가로 도입하는 것이 됩니다. 전역 스코프에 `$` 변수 하나쯤 선언해 놓는다고 다른 라이브러리를 못 쓰는 것도 아니니, jQuery를 안 좋아하는 분은 그냥 무시하시면 되고요. (굳이 충돌나게 만든 AlpineJS가 오히려 유별난 듯)

- 가능하면 어떤 프론트엔드 라이브러리라도 공식적으로 도입한다는 선언은 하지 않을 계획입니다. 한 번 도입해 놓으면 5년이고 10년이고 계속 가져가야 하는데.... 18년째 큰 변화 없이 잘 쓰고 있는 jQuery와 달리, 요즘은 18개월 지원이 LTS라고 주장하는 미친놈들이 넘쳐나니 믿을 수가 있어야죠.

- 관리자 화면의 전체적인 틀을 깨지 않으면서 내 모듈 영역 안에서만은 모던하게 개발하고 싶다면 Svelte를 추천드립니다. 이 녀석은 화면 전체를 자기가 컨트롤해야 한다는 강박관념이 없어서, 원하는 영역에 빌드 파일을 인클루드하면 그 안에서 잘 놀더군요.

- 하나의 서비스를 도맡아서 구축하는 전문 개발자분들의 니즈와, 여러 자료를 조합하여 홈페이지를 운영하는 일반 사용자분들의 니즈가 크게 다른 것을 느낍니다. 주로 전자가 최근 개발 트렌드에 적극적이신데, 후자를 고려하면 "하나의 개발팀이 서비스 전체를 컨트롤한다는 가정" 위에서 정립된 일반적인 개발 방법론과 거기에 맞추어 설계된 최근 툴들을 도입하기가 무척 힘들지요. 라이믹스의 숙명과도 같은 딜레마입니다.

- 다른 부트스트랩 버전을 사용하지 않는다면 다른 대안을 생각하시는 것 같네요. 자체 컴포넌트 제작에 대한 내용도 어디선가 본 것 같기도 합니다.

- jQuery는 좀 뜬금없을 수는 있지만 좀 넓게 생각해서 포함된 의견입니다. 탈 jQuery 의견을 봤던 것 같은데 기억이 정확하진 않아서 라이믹스가 아닌 다른 데서 봤던거랑 헷갈렸을 수도 있을 것 같네요.

jQuery도 CSP 적용이 불가능한 것은 아니지만 탈 jQuery 와 CSP 이슈까지 포함한 의견이고, 일반 사용자페이지 보다 선제적으로 관리페이지에 적용하기에 좋을 것 같아서 포함한 의견입니다. 

jQuery 자체는 CSP와 아무 관련이 없습니다. CSP 적용시 일부 위험한 기능이나 오래된 플러그인이 막히는 것 뿐인데, 맹목적으로 jQuery를 혐오하는 부류들이 잘못된 정보를 퍼뜨리는 것 같아요.

물론 라이믹스 입장에서는 인라인 스크립트로 떡칠해 놓은 서드파티 레이아웃, 스킨들에 비하면 이 정도는 문제 축에도 못 들지만요.

최소한 순정 코어에서는 unsafe-inline 없이 CSP를 적용할 수 있도록 하는 것을 목표로, 인라인 스크립트 및 스타일 선언을 꾸준히 제거해 나가고 있습니다. v2.2 브랜치 기준으로 코어가 무조건 주입하는 HTML 헤더와 푸터에는 더이상 인라인 스크립트가 없고, 기본 레이아웃과 기본 관리자 화면도 손을 댈 일이 있을 때마다 정리하려고 합니다.