한동안 눈팅만 하다가 오랫만에 글을 써 봅니다.
깃허브 이슈에 쓰려다가 안그래도 공홈에 약간의 논쟁(?)이 있었으니, 이 참에...
라이믹스 작업을 하면서 느꼈던 제일 큰 아쉬운 점은
관리자 페이지를 구축하기가 너무 까다롭다는겁니다.
UI의 미적인 요소 뿐 아니라 DX 측면에서도 삭아버렸어요. 라이믹스가 사전 정의한 클래스, 라이믹스 내장 모듈들이 사용하고 있는 UX 컨벤션들이 깔끔히 정리되지 않아
(설령 AI가 대신 해주더라도) 매번 내장 모듈의 것을 뒤적이며 작성해야 하는 상황이 반복됩니다.
이에 관리자 페이지의 표준화 및 정규화가 필요하다고 생각합니다.
가깝게는 이미 구현되어 있는 관리자 페이지 컴포넌트들의 지침과 문서를 작성하는 것일테고,
좀 더 나아가서는 컴포넌트화를 하거나, 아예 새로운 방식으로 선언하는 방법이 있겠네요.
컴포넌트화는 이미 어느정도의 준비가 되어 있죠.
blade 템플릿 엔진의 include 지시자를 사용하여 유사 컴포넌트를 구현할 수 있습니다. 파라미터 정보를 깔끔하게 제공하긴 힘들겠지만, 파일 최상단에 주석을 달아두는 정도로 대체해 볼 수 있겠습니다.
composer를 이용해서 버전 관리도 나름 가능하겠네요.
blade 파일 묶음을 컴포저 패키지로 배포하면, 각 모듈 개발자들은 해당 패키지를 설치해 사용하는 형태로요.
라이믹스 코어 버전에 따라 없는 컴포넌트를 사용하게 되는 문제에서도 자유로워집니다.
(각 모듈이 각자의 vendor 폴더를 가지는 것을 권장하니, 각자 충돌없이 자신이 원하는 버전의 컴포넌트를 끌어올 수 있습니다.)
새로운 방식으로 선언하는 것은... 음. 애드온이나 레이아웃이 사용하는 info.xml을 일부 채용하는 방향입니다.
자유도 측면에서 많은 제약이 있을거라, 크게 선호하지도 않고, 라이믹스 측에서 그리 반기는 선택지도 아니겠지만...
여러 개발자분들이 공개하신 대시보드 모듈, 부관리자 모듈 등 관리자 페이지를 커스터마이징 하는 모듈들에서 손쉽게 끼어들어 디자인을 변경하거나, 권한을 제어하는 등의 기능을 좀 더 안전하게 구현할 수 있다는 장점이 있습니다.
개인적으로 select 라는 백오피스 제품을 흥미롭게 봤습니다. 나름의 자유도를 챙기면서도 관리자 페이지를 쉽고 빠르게 구성할 수 있어서, 라이믹스에서도 유사한 컨셉을 고민해볼 수 있지 않을까 싶습니다.
---
이 새벽에 글 쓰다 보니 머리도 아프고 정신도 몽롱해져서... 일단은 어중간한 글로 마무리합니다. 이따 정신 말짱할 때 조금 더 다듬어 수정할게요ㅎㅎㅠ
댓글 3
두 가지 이슈가 섞여 있는 것 같습니다.
첫째는 현재(v2.1) 관리자 화면이 오래된 버전의 부트스트랩 기준으로 만들어진 것이다 보니, HTML 마크업과 눈에 보이는 디자인 양쪽 모두 아주 구리다는 점입니다. 좀더 모던한 디자인 시스템, 깔끔한 마크업을 사용하는 새로운 표준 컴포넌트들을 마련할 필요가 있습니다. 여기에 대해서는 100% 동의합니다. 이견의 여지가 없죠.^^
둘째는 이런 컴포넌트들을 제공하고 활용하는 방법입니다. 언급하신 예시들을 보면 "관리자 화면 작성의 편의성"을 넘어서서 "관리자 화면 커스터마이징"(내 모듈의 설정 화면뿐 아니라 남의 모듈이나 코어 영역, 즉 대시보드 전체에 내 디자인을 일괄 적용하려는 니즈)까지 생각하고 계신 듯 한데, 여기에 대해서는 의문이 있습니다. 전자에는 분명 도움이 되겠지만, 후자는 "표준화"라는 작업의 특성상 오히려 된서리를 맞을 수도 있거든요.
클라이언트의 요구나 자사 상품 홍보 등 여러 가지 이유로 남의 모듈 화면까지 커스터마이징하려는 시도가 종종 일어나는데, 그런 니즈를 공식적으로 지원한다고 너무 복잡하게 pluggable한 구조를 만들어 놓으면 절대 다수의 일반 사용자와 제작자가 불편해질 수 있습니다. 예를 들어 게시판의 "추가 설정" 화면처럼 여러 모듈이 개입하는 화면에 각각 다른 디자인 시스템을 들고 오도록 허용한다면 난장판이 되겠지요. 표준을 벗어나는 영역은 비공식으로 놔두는 것이 어떨지...
(물론 .x_control-group 같은 기존 구조를 사용하는 자료들이 하루 아침에 깨져 버리면 곤란할 테니, 기존의 CSS 클래스에도 일관성있는 스타일을 적용해 주는 작업 역시 필요합니다. 새로운 디자인까지는 모두들 좋다고 덤비는데, 하위 호환성 보장 얘기가 나오면 부리나케 도망갑니다. 하위 호환성 챌린지를 즐기는 저 같은 변태는 흔하지 않은지라...)
"애드온이나 레이아웃이 사용하는 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로 설치해서 쓴다는 제안에 대한 코멘트였습니다. 자유도가 높아지는 만큼 파편화가 심해질 수 있고, 폼 관련 컴포넌트야 어차피 뻔하다 보니 서로 유사한 컴포넌트를 각자 수정해서 쓰다가 충돌할 가능성도 높아집니다.
물론 서드파티 자료가 커스텀 디자인을 사용하겠다는 것을 막을 수도 없고 막아서도 안 되겠지만, 굳이 코어에서 "각자 쓰고 싶은 컴포넌트 들고 와"을 권장하는 듯한 구조를 택할 필요는 없다는 거죠. 제작자분들이 믿고 쓸 수 있는 디폴트가 코어에 포함되어 있어야 하고, 그것을 어떤 문법으로 끌어다 쓰느냐는 다른 문제입니다.