리자님의 답글에 개인의 의견입니다 정보
리자님의 답글에 개인의 의견입니다
본문
원문글
@리자님의 답글중
만약, shop 이라는 게시판이 존재할때
쇼핑몰 (shop) 과 같은 경로를 사용하지 못하는 경우가 생길 수 있습니다.
코멘트로 달려다 보니 영 불편해서 따로 글을 남겨 봅니다
개인의 의견이니 그냥 그럴수도 있겠구나라고 봐주시면 고맙겠습니다
뉴스, 블러그, shop등 큼직한 섹션은 2차 도메인이나 폴더형 하부 섹션을 생각하게 됩니다
아마 네이버, 다음등 커다란 커뮤니티들을 먼저 선경험 했기 때문일겁니다
news.sir.kr/뉴스 디비 고유 번호
blog.sir.kr/블러그 디비 고유 번호
또는
sir.kr/news//뉴스 디비 고유 번호
sir.kr/blog/블러그 디비 고유 번호
샵의 경우는 위와 같이 샵이란 폴더 혹은 2차 도메인에 귀속 되도록해도 큰 무리는 없을듯 합니다
꼭 줄여야 한다면 전문적인 shop 커뮤니티에서는 괜챦겠지만 일반 커뮤니티에서는
주객 전도가 될거 같습니다 영자님 글 처럼 꼭 써야할 커뮤니티용 게시판 아이디를
잘못하면 쓸수 없으니까요
게시판도 community혹은 bbs 섹션 폴더나 2차 도메인에 귀속 시켜도 되겠지만
게시판의 경우는 아무래도 검색이나 찾아들기 편하게 하려면
url 타이핑 갯수를 하나라도 줄이는게 좋을듯 싶습니다
sir/free 와 같이 써도 일반적인 커뮤니티 혹은 개인홈에서는
게시판 혹은 어디 속한 메뉴가 아닐까 충분히 상상할 수 있을거 같습니다
( 제 개인 생각일뿐 각 커뮤니티에서 규정하는 정책에 따라서 정하면 될듯 합니다
대안으로 shop_아이디 같이 말머리를 넣어 아이디를 정해도 되구요 )
프로그램 정책을 잡아야 하니 머리가 더 복잡하실듯
힘내세요 : )
추천
1
1
베스트댓글
shop 뿐만 아니라 mypage(profile) 등 확장성을 고려하면 게시판을 board로 분리하는게 낫다고 봅니다. 게시판 ID에 방해받지 않고 구성이 가능하죠.
서브도메인은 SSL 인증서 추가 구매나 멀티인증서 구매 등 추가 비용과 사용하는 호스팅에 따라 서브도메인 제한 등 board 하나 떼는 것때문에 고려하거나 부담해야 할 것이 너무 큽니다.
서비스 운영자 입장에서만보면 자신이 제어 가능하기 때문에 board를 떼는 것이 낫지만 서드파티에서 짧은 주소에 커스텀으로 기능을 제공하는 등의 관점에서보면 분리하여 이름 공간을 사용할수있도록 제공하는 편이 훨씬 편리하기도하고요.
또한, 폴더 내 파일에도 접근해야한다면 폴더명과 게시판 ID가 겹치는 문제도 피해야합니다.
board를 떼면 내용관리 기능으로 작성된 페이지와의 구성도 애매해지고요.
하지만 이런 것들은 "현재" 그누보드에서 발생하는 충돌의 우려입니다.
만약 다이나믹 rewrite를 지원하고 폴더 경로로 접근하는 것을 제한하는 등으로 변화한다면 board를 떼는건 가능한 범주라고 봅니다. 어쨌든 현재 상황에서는 위와 같은 충돌 문제를 서비스 운영자가 아닌 소프트웨어 제공자 입장에서는 충돌 상황을 간과해서는 안될 것같습니다.
사실 지금도 board가 붙지 않은채로 /free로 게시판 접근이 가능한 짧은주소 기능을 제공하고 있죠.
이미 충돌이 쉽게 발생할 수 있는 상황이고한데 저 설문은 큰 폭의 변화를 암시하는 것인지 궁금해지는군요. 만약 다른 베이스로 개발되고 /{id}를 통제할 수 있다면 굳이 board를 붙이냐 마냐를 고민하지 않고도 충돌은 해결할 수 있을텐데라는 생각을 해봅니다.
라이믹스가 content(내용관리) 유사한 페이지와 게시판 ID, 기타 서드파티가 점유하는 ID 등이 통제되어 /board 등으로 구분되지 않고 /free 등으로 바로 접근이 가능하고 서드파티의 기능과도 충돌이 방지되고 있죠.
어쨌든 통제 가능하다면 굳이 board를 붙일 필요가 없다는 입장이고, 그렇지 않다면 board를 붙여 구분하는 편이 좀 더 나을 수 있다고 봅니다. 서브도메인은 대안이 될 수 없다고 보고요.
서브도메인은 SSL 인증서 추가 구매나 멀티인증서 구매 등 추가 비용과 사용하는 호스팅에 따라 서브도메인 제한 등 board 하나 떼는 것때문에 고려하거나 부담해야 할 것이 너무 큽니다.
서비스 운영자 입장에서만보면 자신이 제어 가능하기 때문에 board를 떼는 것이 낫지만 서드파티에서 짧은 주소에 커스텀으로 기능을 제공하는 등의 관점에서보면 분리하여 이름 공간을 사용할수있도록 제공하는 편이 훨씬 편리하기도하고요.
또한, 폴더 내 파일에도 접근해야한다면 폴더명과 게시판 ID가 겹치는 문제도 피해야합니다.
board를 떼면 내용관리 기능으로 작성된 페이지와의 구성도 애매해지고요.
하지만 이런 것들은 "현재" 그누보드에서 발생하는 충돌의 우려입니다.
만약 다이나믹 rewrite를 지원하고 폴더 경로로 접근하는 것을 제한하는 등으로 변화한다면 board를 떼는건 가능한 범주라고 봅니다. 어쨌든 현재 상황에서는 위와 같은 충돌 문제를 서비스 운영자가 아닌 소프트웨어 제공자 입장에서는 충돌 상황을 간과해서는 안될 것같습니다.
사실 지금도 board가 붙지 않은채로 /free로 게시판 접근이 가능한 짧은주소 기능을 제공하고 있죠.
이미 충돌이 쉽게 발생할 수 있는 상황이고한데 저 설문은 큰 폭의 변화를 암시하는 것인지 궁금해지는군요. 만약 다른 베이스로 개발되고 /{id}를 통제할 수 있다면 굳이 board를 붙이냐 마냐를 고민하지 않고도 충돌은 해결할 수 있을텐데라는 생각을 해봅니다.
라이믹스가 content(내용관리) 유사한 페이지와 게시판 ID, 기타 서드파티가 점유하는 ID 등이 통제되어 /board 등으로 구분되지 않고 /free 등으로 바로 접근이 가능하고 서드파티의 기능과도 충돌이 방지되고 있죠.
어쨌든 통제 가능하다면 굳이 board를 붙일 필요가 없다는 입장이고, 그렇지 않다면 board를 붙여 구분하는 편이 좀 더 나을 수 있다고 봅니다. 서브도메인은 대안이 될 수 없다고 보고요.
댓글 6개
아이디어 참고가 되겠습니다.
shop 뿐만 아니라 mypage(profile) 등 확장성을 고려하면 게시판을 board로 분리하는게 낫다고 봅니다. 게시판 ID에 방해받지 않고 구성이 가능하죠.
서브도메인은 SSL 인증서 추가 구매나 멀티인증서 구매 등 추가 비용과 사용하는 호스팅에 따라 서브도메인 제한 등 board 하나 떼는 것때문에 고려하거나 부담해야 할 것이 너무 큽니다.
서비스 운영자 입장에서만보면 자신이 제어 가능하기 때문에 board를 떼는 것이 낫지만 서드파티에서 짧은 주소에 커스텀으로 기능을 제공하는 등의 관점에서보면 분리하여 이름 공간을 사용할수있도록 제공하는 편이 훨씬 편리하기도하고요.
또한, 폴더 내 파일에도 접근해야한다면 폴더명과 게시판 ID가 겹치는 문제도 피해야합니다.
board를 떼면 내용관리 기능으로 작성된 페이지와의 구성도 애매해지고요.
하지만 이런 것들은 "현재" 그누보드에서 발생하는 충돌의 우려입니다.
만약 다이나믹 rewrite를 지원하고 폴더 경로로 접근하는 것을 제한하는 등으로 변화한다면 board를 떼는건 가능한 범주라고 봅니다. 어쨌든 현재 상황에서는 위와 같은 충돌 문제를 서비스 운영자가 아닌 소프트웨어 제공자 입장에서는 충돌 상황을 간과해서는 안될 것같습니다.
사실 지금도 board가 붙지 않은채로 /free로 게시판 접근이 가능한 짧은주소 기능을 제공하고 있죠.
이미 충돌이 쉽게 발생할 수 있는 상황이고한데 저 설문은 큰 폭의 변화를 암시하는 것인지 궁금해지는군요. 만약 다른 베이스로 개발되고 /{id}를 통제할 수 있다면 굳이 board를 붙이냐 마냐를 고민하지 않고도 충돌은 해결할 수 있을텐데라는 생각을 해봅니다.
라이믹스가 content(내용관리) 유사한 페이지와 게시판 ID, 기타 서드파티가 점유하는 ID 등이 통제되어 /board 등으로 구분되지 않고 /free 등으로 바로 접근이 가능하고 서드파티의 기능과도 충돌이 방지되고 있죠.
어쨌든 통제 가능하다면 굳이 board를 붙일 필요가 없다는 입장이고, 그렇지 않다면 board를 붙여 구분하는 편이 좀 더 나을 수 있다고 봅니다. 서브도메인은 대안이 될 수 없다고 보고요.
서브도메인은 SSL 인증서 추가 구매나 멀티인증서 구매 등 추가 비용과 사용하는 호스팅에 따라 서브도메인 제한 등 board 하나 떼는 것때문에 고려하거나 부담해야 할 것이 너무 큽니다.
서비스 운영자 입장에서만보면 자신이 제어 가능하기 때문에 board를 떼는 것이 낫지만 서드파티에서 짧은 주소에 커스텀으로 기능을 제공하는 등의 관점에서보면 분리하여 이름 공간을 사용할수있도록 제공하는 편이 훨씬 편리하기도하고요.
또한, 폴더 내 파일에도 접근해야한다면 폴더명과 게시판 ID가 겹치는 문제도 피해야합니다.
board를 떼면 내용관리 기능으로 작성된 페이지와의 구성도 애매해지고요.
하지만 이런 것들은 "현재" 그누보드에서 발생하는 충돌의 우려입니다.
만약 다이나믹 rewrite를 지원하고 폴더 경로로 접근하는 것을 제한하는 등으로 변화한다면 board를 떼는건 가능한 범주라고 봅니다. 어쨌든 현재 상황에서는 위와 같은 충돌 문제를 서비스 운영자가 아닌 소프트웨어 제공자 입장에서는 충돌 상황을 간과해서는 안될 것같습니다.
사실 지금도 board가 붙지 않은채로 /free로 게시판 접근이 가능한 짧은주소 기능을 제공하고 있죠.
이미 충돌이 쉽게 발생할 수 있는 상황이고한데 저 설문은 큰 폭의 변화를 암시하는 것인지 궁금해지는군요. 만약 다른 베이스로 개발되고 /{id}를 통제할 수 있다면 굳이 board를 붙이냐 마냐를 고민하지 않고도 충돌은 해결할 수 있을텐데라는 생각을 해봅니다.
라이믹스가 content(내용관리) 유사한 페이지와 게시판 ID, 기타 서드파티가 점유하는 ID 등이 통제되어 /board 등으로 구분되지 않고 /free 등으로 바로 접근이 가능하고 서드파티의 기능과도 충돌이 방지되고 있죠.
어쨌든 통제 가능하다면 굳이 board를 붙일 필요가 없다는 입장이고, 그렇지 않다면 board를 붙여 구분하는 편이 좀 더 나을 수 있다고 봅니다. 서브도메인은 대안이 될 수 없다고 보고요.
@jihan6?
우선 댓글 감사합니다 : )
아래 두가지에 대해 약간은 다른 의견을 가지고 있어서 잠깐 제 생각을 넣어 봅니다
첫번째 의견
"서브도메인은 SSL 인증서 추가 구매나 멀티인증서 구매 등 추가 비용과 사용하는 호스팅에 따라 서브도메인 제한 등 board 하나 떼는 것때문에 고려하거나 부담해야 할 것이 너무 큽니다."
맞습니다 서브 도메인을 선택했을 경우엔 지적하신대로의 문제점이 생깁니다
그럼에도 그누보드가 발전이란 이름하에 확장을 해야 한다면 지원을 할수 있게 선택 사항으로 넣어야 합니다
서브 도매인을 지원하지 않는 곳도 있지만 지원한다는 조건하에 아래의 글을 덧 붙입니다
소규모 홈페이지를 지향하는 사람도 있지만 좀 더 큰 개념의 커뮤니티를 직접 만들어
운영하길 원하는 사람이 있구
보통은 저와 같이 업체의 계정을 얻어 사용하지만
누군가는 가상 서버 공간을 얻거나 혹은 직접 서버를 운영하기에
확장된 서비스를 그대로 사용할수 있기를 원합니다
주소 구조가 아무래도 서브 폴더 보다는 서브 도매인이 좀더 서비스 개념에 맞을듯 합니다
프로그램은
다소 복잡하긴 하지만 충분히 서브 도매인으로 빼던지 서브 폴더로 빼던지
관리자의 선택으로 양쪽다 선택해서 사용할수 있는 프로그램으로 만들수 있습니다
SSL인증서 또한 잘 찾아보면 무료 인증서를 통해서 왠만큼은 해결 가능 합니다
만약 해결이 안되고
개인 홈페이지가 아닌 규모 있는 사이트를 운영할거라면 약간의 지출이 발생하더라도 저 같으면
금액이 저렴한 인증서를 찾아서라도 설치할거 같습니다
사업이란 걸 생각할 정도의 사람이라면 어느 정도의 지출은 필히 생각할 겁니다
---------------------------------------------------------------------------------------------------
두번째 의견
"또한, 폴더 내 파일에도 접근해야한다면 폴더명과 게시판 ID가 겹치는 문제도 피해야합니다.
board를 떼면 내용관리 기능으로 작성된 페이지와의 구성도 애매해지고요."
이부분에 대한 제 생각을 잠깐 적어봅니다
그누보드는 .htaccess파일에 의해 게시판으로 샵으로 컨텐츠로 타겟을 넘겨줍니다
그러니 문제가 살짝 드러나게 됩니다
이렇게 분류되는 것을 스위칭할 수 있는 하나의 페이지로 넘겨주면 어느정도 해결 가능합니다
아마 제 기억으로는 워드프로세스와 몇가지 이름이 알려진 프로그램에서 사용하는 걸로 기억하는데 제 기억이 틀린 기억일 수도 있습니다
저 또한 만들고 있는 것이 있어서 되도록 메이저급 프로그램은 보지 않을려구 하다 보니
기억이 잘못되어 있을수 있습니다
아래는 제가 사용했던 방법인데 게시판, 일반 컨텐츠 페이지, 디비 작성페이지등 원하는 페이지로
선택해서 가져옵니다 즉 문제라고 하셨던 모든 부분을 어느정도 해결합니다
스위칭 페이지를 하나 만들어 파일 혹은 폴더, 스타일시트, 자바스크립트 파일, 이미지파일등
직접 호출을 해야 의미 있는 파일은 빼고 나머지는 모두 그곳( 스위칭 페이지)으로 향하게 합니다
안에서 아래와 같이 분기 처리를 합니다
들어온 주소 ( 예 : https://sir.kr/cm_free ) url구조에서 필요부분인 cm_free를 가지구
이게 게시판인지 컨텐츠인지 파일인지 구분을 해서 해당 모듈로 넘겨줍니다
좀 더 첨언한다면
1. https://sir.kr/cm_free 로 사용자가 들어옵니다
2. 메뉴 디비 테이블에 cm_fre 메뉴가 있는지 찾아 봅니다
3. 메뉴가 없다면 없는 메뉴이니 해당 주소가 잘못되었다는 404페이지를 보여줍니다
4. 메뉴가 존재한다면 해당 메뉴가 어떤한 종류의 메뉴인지 필드값을 가져옵니다
디비는 아래와 같은 형식이면 됩니다
----------------------------------------------------
menu_id | menu_name | menu_type | call_url
----------------------------------------------------
cm_free | 자유게시판 | board |
----------------------------------------------------
menu_id | menu_name | menu_type | call_url
----------------------------------------------------
cm_free | 자유게시판 | page | ../page.php
----------------------------------------------------
menu_id | menu_name | menu_type | call_url
----------------------------------------------------
cm_free | 자유게시판 | content | db내용
5. menu_type이 무엇을 선택하고 있는지에 따라서 ( 관리자가 선택 가능 ) 해당 페이지는
게시판이 될수도 있구 일반적인 페이지를 인클루드 해서 사용할 수도 있구
디비에서 내용을 가져와 컨텐츠로 뿌려줄 수도 있습니다
메뉴에 무엇이 들어 있느냐 없느냐에 의해 페이지가 설정되기 때문에
해당 메뉴와 똑 같은 메뉴가 있어서는 안된다는 전제 조건은 가지고 있어야 합니다
왼쪽을 바라보면서 오른쪽에 있는 사람에게 윙크를 하라는 모순된 상황이 아니라면
왠만큼 해결됩니다 위의 문제도 실상 거울을 가져다가 바라보면서 윙크하면 되긴 하지만요
두번째 문제의 핵심은 달걀이냐 닭이냐와 비슷한 개념인데
https://sir.kr/cm_free
위의 주소를 게시판의 아이디로 볼것인지 하나의 사이트 메뉴로 볼것인지가 핵심입니다
게시판 아디디로만 본다면 개념이 게시판으로 좁게 보이지만
메뉴로 본다면 메뉴를 통해서 개념을 좀 더 넓힐수 있을거 같습니다
우선 댓글 감사합니다 : )
아래 두가지에 대해 약간은 다른 의견을 가지고 있어서 잠깐 제 생각을 넣어 봅니다
첫번째 의견
"서브도메인은 SSL 인증서 추가 구매나 멀티인증서 구매 등 추가 비용과 사용하는 호스팅에 따라 서브도메인 제한 등 board 하나 떼는 것때문에 고려하거나 부담해야 할 것이 너무 큽니다."
맞습니다 서브 도메인을 선택했을 경우엔 지적하신대로의 문제점이 생깁니다
그럼에도 그누보드가 발전이란 이름하에 확장을 해야 한다면 지원을 할수 있게 선택 사항으로 넣어야 합니다
서브 도매인을 지원하지 않는 곳도 있지만 지원한다는 조건하에 아래의 글을 덧 붙입니다
소규모 홈페이지를 지향하는 사람도 있지만 좀 더 큰 개념의 커뮤니티를 직접 만들어
운영하길 원하는 사람이 있구
보통은 저와 같이 업체의 계정을 얻어 사용하지만
누군가는 가상 서버 공간을 얻거나 혹은 직접 서버를 운영하기에
확장된 서비스를 그대로 사용할수 있기를 원합니다
주소 구조가 아무래도 서브 폴더 보다는 서브 도매인이 좀더 서비스 개념에 맞을듯 합니다
프로그램은
다소 복잡하긴 하지만 충분히 서브 도매인으로 빼던지 서브 폴더로 빼던지
관리자의 선택으로 양쪽다 선택해서 사용할수 있는 프로그램으로 만들수 있습니다
SSL인증서 또한 잘 찾아보면 무료 인증서를 통해서 왠만큼은 해결 가능 합니다
만약 해결이 안되고
개인 홈페이지가 아닌 규모 있는 사이트를 운영할거라면 약간의 지출이 발생하더라도 저 같으면
금액이 저렴한 인증서를 찾아서라도 설치할거 같습니다
사업이란 걸 생각할 정도의 사람이라면 어느 정도의 지출은 필히 생각할 겁니다
---------------------------------------------------------------------------------------------------
두번째 의견
"또한, 폴더 내 파일에도 접근해야한다면 폴더명과 게시판 ID가 겹치는 문제도 피해야합니다.
board를 떼면 내용관리 기능으로 작성된 페이지와의 구성도 애매해지고요."
이부분에 대한 제 생각을 잠깐 적어봅니다
그누보드는 .htaccess파일에 의해 게시판으로 샵으로 컨텐츠로 타겟을 넘겨줍니다
그러니 문제가 살짝 드러나게 됩니다
이렇게 분류되는 것을 스위칭할 수 있는 하나의 페이지로 넘겨주면 어느정도 해결 가능합니다
아마 제 기억으로는 워드프로세스와 몇가지 이름이 알려진 프로그램에서 사용하는 걸로 기억하는데 제 기억이 틀린 기억일 수도 있습니다
저 또한 만들고 있는 것이 있어서 되도록 메이저급 프로그램은 보지 않을려구 하다 보니
기억이 잘못되어 있을수 있습니다
아래는 제가 사용했던 방법인데 게시판, 일반 컨텐츠 페이지, 디비 작성페이지등 원하는 페이지로
선택해서 가져옵니다 즉 문제라고 하셨던 모든 부분을 어느정도 해결합니다
스위칭 페이지를 하나 만들어 파일 혹은 폴더, 스타일시트, 자바스크립트 파일, 이미지파일등
직접 호출을 해야 의미 있는 파일은 빼고 나머지는 모두 그곳( 스위칭 페이지)으로 향하게 합니다
안에서 아래와 같이 분기 처리를 합니다
들어온 주소 ( 예 : https://sir.kr/cm_free ) url구조에서 필요부분인 cm_free를 가지구
이게 게시판인지 컨텐츠인지 파일인지 구분을 해서 해당 모듈로 넘겨줍니다
좀 더 첨언한다면
1. https://sir.kr/cm_free 로 사용자가 들어옵니다
2. 메뉴 디비 테이블에 cm_fre 메뉴가 있는지 찾아 봅니다
3. 메뉴가 없다면 없는 메뉴이니 해당 주소가 잘못되었다는 404페이지를 보여줍니다
4. 메뉴가 존재한다면 해당 메뉴가 어떤한 종류의 메뉴인지 필드값을 가져옵니다
디비는 아래와 같은 형식이면 됩니다
----------------------------------------------------
menu_id | menu_name | menu_type | call_url
----------------------------------------------------
cm_free | 자유게시판 | board |
----------------------------------------------------
menu_id | menu_name | menu_type | call_url
----------------------------------------------------
cm_free | 자유게시판 | page | ../page.php
----------------------------------------------------
menu_id | menu_name | menu_type | call_url
----------------------------------------------------
cm_free | 자유게시판 | content | db내용
5. menu_type이 무엇을 선택하고 있는지에 따라서 ( 관리자가 선택 가능 ) 해당 페이지는
게시판이 될수도 있구 일반적인 페이지를 인클루드 해서 사용할 수도 있구
디비에서 내용을 가져와 컨텐츠로 뿌려줄 수도 있습니다
메뉴에 무엇이 들어 있느냐 없느냐에 의해 페이지가 설정되기 때문에
해당 메뉴와 똑 같은 메뉴가 있어서는 안된다는 전제 조건은 가지고 있어야 합니다
왼쪽을 바라보면서 오른쪽에 있는 사람에게 윙크를 하라는 모순된 상황이 아니라면
왠만큼 해결됩니다 위의 문제도 실상 거울을 가져다가 바라보면서 윙크하면 되긴 하지만요
두번째 문제의 핵심은 달걀이냐 닭이냐와 비슷한 개념인데
https://sir.kr/cm_free
위의 주소를 게시판의 아이디로 볼것인지 하나의 사이트 메뉴로 볼것인지가 핵심입니다
게시판 아디디로만 본다면 개념이 게시판으로 좁게 보이지만
메뉴로 본다면 메뉴를 통해서 개념을 좀 더 넓힐수 있을거 같습니다
@예뜨락
서브도메인 문제는 말씀하신 것처럼 무료 인증서도 있고, 사업할 사람이면 인증서 비용을 무서워 할 정도도 아닐테고... 동의합니다.
하지만, 서브도메인은 "원하면" 그렇게 구성할 수 있도록 아래 라이믹스 사례처럼 기능을 제공하면 가장 좋은것이지만, "겹치니까" 분리하는거라면 그것에는 동의하지 않습니다. (글을 수정하다보니 라이믹스 얘기는 아래에 있습니다.)
그리고, shop 외에도 충돌이 우려되는 항목은 https://sir.kr/cm_forum/11051#c_11106 요기 댓글에 나열해봤습니다.
---
말씀하신 것처럼 그누보드 자체에서 파일 경로에 의존하지 않고 다이나믹 rewrite를 지원하면 /board를 붙이니 마니 하는 이야기도 할 필요가 없습니다. 이것도 말씀하신 "두번째 의견"에 해당하는 내용입니다.
shop은 /store로 할당하고, 자유게시판은 /free로 할당하고, 포인트 가위바위보게임은 /point_rsp에 할당하고, faq는 /faq에 할당하고...
이야기했던 것처럼 "현재"의 그누보드 상태에서 충돌이 발생하고 관리되지 못하기 때문이고, 다이나믹 rewrite로 모든 URL이 관리/통제 된다면 /board 이런거 붙일 필요도 없죠.
/shop, /store 등 대신 store.domain.com 처럼 서브도메인 지원도 추가되면 더욱 좋겠죠.
라이믹스가 위와 유사합니다. 페이지, 게시판 등이 MID라는 것으로 전체 시스템에서 관리되어 서로 겹치지 않게 생성하여 /ROOT 경로로 제공하고, 서브도메인도 설정할 수 있더군요.
서드파티에서 개발한 기능도 /ROOT 경로를 할당하여 사용할 수 있고요.
라이믹스 외에도 워드프레스, 줌라, 드루팔 같은 오래된 CMS나 최근에 개발되는 대부분의 것들은 그누보드처럼 파일 경로 기반이나 .htaccess 에서 정의한 일부가 아닌 전체 URL을 통제하는 방식으로 구현되는게 보다 일반적입니다.
그누보드는 "내용관리"에서 작성한건 /content로 구분하고 있고, 게시판그룹은 또 짧은 주소가 없고... 그렇더군요.
"현재"는 그렇지 못하기 때문에 /board로 구분하여 /ROOT의 충돌을 예방하는게 낫겠다는 의견이었습니다.
근데 이미 그누보드는 /free로 짧은 주소 기능이 동작하고 있지만요 ^^;
서브도메인 문제는 말씀하신 것처럼 무료 인증서도 있고, 사업할 사람이면 인증서 비용을 무서워 할 정도도 아닐테고... 동의합니다.
하지만, 서브도메인은 "원하면" 그렇게 구성할 수 있도록 아래 라이믹스 사례처럼 기능을 제공하면 가장 좋은것이지만, "겹치니까" 분리하는거라면 그것에는 동의하지 않습니다. (글을 수정하다보니 라이믹스 얘기는 아래에 있습니다.)
그리고, shop 외에도 충돌이 우려되는 항목은 https://sir.kr/cm_forum/11051#c_11106 요기 댓글에 나열해봤습니다.
---
말씀하신 것처럼 그누보드 자체에서 파일 경로에 의존하지 않고 다이나믹 rewrite를 지원하면 /board를 붙이니 마니 하는 이야기도 할 필요가 없습니다. 이것도 말씀하신 "두번째 의견"에 해당하는 내용입니다.
shop은 /store로 할당하고, 자유게시판은 /free로 할당하고, 포인트 가위바위보게임은 /point_rsp에 할당하고, faq는 /faq에 할당하고...
이야기했던 것처럼 "현재"의 그누보드 상태에서 충돌이 발생하고 관리되지 못하기 때문이고, 다이나믹 rewrite로 모든 URL이 관리/통제 된다면 /board 이런거 붙일 필요도 없죠.
/shop, /store 등 대신 store.domain.com 처럼 서브도메인 지원도 추가되면 더욱 좋겠죠.
라이믹스가 위와 유사합니다. 페이지, 게시판 등이 MID라는 것으로 전체 시스템에서 관리되어 서로 겹치지 않게 생성하여 /ROOT 경로로 제공하고, 서브도메인도 설정할 수 있더군요.
서드파티에서 개발한 기능도 /ROOT 경로를 할당하여 사용할 수 있고요.
라이믹스 외에도 워드프레스, 줌라, 드루팔 같은 오래된 CMS나 최근에 개발되는 대부분의 것들은 그누보드처럼 파일 경로 기반이나 .htaccess 에서 정의한 일부가 아닌 전체 URL을 통제하는 방식으로 구현되는게 보다 일반적입니다.
그누보드는 "내용관리"에서 작성한건 /content로 구분하고 있고, 게시판그룹은 또 짧은 주소가 없고... 그렇더군요.
"현재"는 그렇지 못하기 때문에 /board로 구분하여 /ROOT의 충돌을 예방하는게 낫겠다는 의견이었습니다.
근데 이미 그누보드는 /free로 짧은 주소 기능이 동작하고 있지만요 ^^;
/bbs/1234
/board/1235
이런 것도 가능하지 않을까요?
게시판id+ wr_id 를 숫자로 하거나
게시판 테이블을 통합하면요.
/board/1235
이런 것도 가능하지 않을까요?
게시판id+ wr_id 를 숫자로 하거나
게시판 테이블을 통합하면요.
@엑스엠엘 그 또한 괜챦은 구조네요 ^^
