stringex에서 빗장 변환 삭제

묘사

헤이!
나는 최근에 Mongoid::Slug을 사용해 왔다. 이것은stringex에 의존하여 영구 링크를 형성한다. 내가 URL을 형성할 때/문자가 사선 내연으로 전환된다. 이것은 나를 매우 놀라게 한다. 왜냐하면 이것은 유효한 URL 문자이고 본문의/2011/05/26/title와 같은 영구 링크가 형성되는 것을 방지할 수 있기 때문이다.
Mongoid::Slug으로 하겠습니다.
slug:published_at_permalink_prefix,:title
만약 내가 대시를 구분자로 사용한다면, 효과는 매우 좋으나, 만약 내가 날짜 구분자로 빗장을 사용한다면, 이것은 분명히 잘못될 것이다.
나는 네가 URL의 a/가 영구 링크가 되는 것을 원하지 않는 용례를 생각해 보려고 한다. 비록 이것은 매우 보기 드문 용례이지만, 나는 상상할 것이다. 그러나 내가 머리를 쥐어짜도, 나는 그것을 삭제하고 요청을 요청하는 것이 가장 좋다고 생각한다.
변경을 하고pull 요청을 보냈습니다. 하지만 좋은 이유가 있으면 말씀해 주십시오.그냥 철저하게 한 것 같아.
안녕히 계세요!
다릴.

토론 #1

헤이, 다른 댓글에도 댓글을 달았지만 여기에 주석을 하나 쓰고 싶어요.stringex의acts as url 부분의 목표는 전체 url 구조가 아니라 음역 단어입니다.슬래시는 Rails 라우팅 아키텍처에서 의미가 있으므로 분할할지 여부를 결정하지 못했습니다(이와 무관할 수도 있음).나도 내가 너무 무거운 URL 생성 (날짜와 내용 포함) 은stringex 기능의 일부분이라고 생각하는 것을 별로 좋아하지 않는다. 단지 짧은 단어를 읽을 수 있는 목적으로 간단하게 번역할 뿐이다.예를 들어,dots는 URI에서 합법적이지만,stringex는dots를 사용하여 더 읽을 수 있는 형식을 제공합니다.루트 자체에서 의미를 제거한다.일리가 있었으면 좋겠어요.

토론 #2

공평한 거 알잖아.그냥 해보고 싶었어요. 생각하고 있었으니까...잠깐만, 빗장은 합법적인데 왜 이러는 거야.만약 목표가 음역이라면 문제없을 것 같다.
만약 내가 Stringex를 갈라서 Stringex의 사선을 보석으로 삼는다면, 당신은 매우 화를 낼 것입니까? (왜냐하면, 당신은 아무도 umbrage=p를 원하지 않는다는 것을 알고 있기 때문입니다.)나에게 있어서 이곳의 문제는 한 함수로 전체 내용을 해석한 다음에 사용하는 것이 더 많다
slug:published_at_permalink_prefix,:title
Mongoid: Slug을 사용하면 점프가 아니라 필요한 효과를 얻을 수 있습니다. (앞에서 말한 바와 같이 대시를 사용할 때 사선만 바꾸면 됩니다.)
나의 또 다른 선택은Mongoid::Slug을 해독하여 Slug 앞에 어떤 URL 구조를 제공하는 것이다. 이것은 당연히 가능하지만,find by Slug 방법을 사용하는 방식을 깨뜨릴 것이라고 생각한다.
안녕히 계세요!
다릴.

토론 #셋

사용자 정의 덮어쓰기 '단계별 검색' 만 하면 url 구조를 쉽게 벗길 수 있지만, 그 중에서 자동으로 생성할 수 있는 방법은 확실하지 않습니다.만약 당신이 날짜 데이터를 날짜 데이터로 해석하지 않았다면, 왜 날짜 데이터를 안에 넣으려고 합니까?내가 말하고자 하는 것은 바로 이런 조잡하고 남조된atm가 사용자로 하여금 그 의미와 구조를 신속하게 해석할 수 없게 하는 것이다.posts/2010/05/19를 사용하여 날짜를 정하지 않으면, 나는 직접 내 프로그램에서 그것을 삭제할 것이다.obvsymmv, 하지만 몇 가지 문제를 고려해야 합니다.

토론 #4

오, 만료된 데이터를 해석하는 데 사용하면stringex의 기본 동작이 바로 원하는 것입니다. (빗장 없음)post/:년/월/일/:slug.

토론 #5

날짜가 영구 링크에 추가된 후에 slug를 간단하게 불러올 수 있습니다
이것은 데이터의 의미를 전달했다...wordpress URL 같아.
/2011년 3월 28일/제목 강타
발표 날짜를 반영했기 때문에, 같은 일을 완성했지만,
날짜를 제대로 해석해야 합니다.사실 나는 이것이 더 좋은 선택이라고 생각한다
퍼블릭 도움말을 작성해서 날짜를 분석하는 것보다 해결 방안이 훨씬 낫다.
그리고 이런 방식은 속도가 매우 빠르다.간단한 단계별 게시물 찾기
제어기.봐.완성url 도움말 프로그램과 복잡한 날짜 해석이 없습니다.완료. =]
사실 내가 유일하게 날짜를 해석할 계획을 세운 곳은 내가 가는 곳이다
서류가 좀 필요합니다.ie 도메인 이름.com/2010 연간 페이지
게시물.히드록시 메틸 멜라민 메틸 에테르...
사실, 나는 도메인 이름과 같은 아주 좋은 사이트 주소를 가지고 있다.com/2011/03/28/알겠니
어쨌든 이것은 내가 생각할 수 있는 가장 간단한 전진 노선이다.이 가능하다, ~할 수 있다,...
그래.나에게 있어서 해석 날짜는 단지 하나를 찾은 것보다
독특한permalink tho.
안녕히 계세요!
다릴.
2011년 3월 29일 화요일 오전 12:14,rsl [email protected]:

it'd prolly be easier to just custom override find_by_slug to peel off the url structure but i'm not sure how you'd get it to autogenerate them in there. why are you putting the date data in there at all though if yr not actually parsing it as date data? i'd say it's cruft atm that keeps users from quickly parsing the meaning and structure. unless yr using posts/2010/05/19 to scope to that date i'd personally cut it from my own app. obvs ymmv but something to think about.

Reply to this email directly or view it on GitHub: https://github.com/rsl/stringex/pull/22#issuecomment-925891

토론 #6

나는 네가 이전에 이 인출 요청을 거절한 것을 알고 있지만, 내가 선택할 수 있는 매개 변수 하나만 허용해서 빗장 전환을 비활성화하는 요청을 받아들일 수 있겠니?아니면 프로필 계획에 진전이 있습니까?
나는 아직도 내 포크를 사용하고 있다. 이렇게 하면 나는 너의 훌륭한 프로젝트를 사용할 수 있고, 나는 마스터 브랜드에서 일하고 싶다.

토론 #7

합리적으로 들린다.새로운 당김 요청을 열면 좋을 것 같습니다.

토론 #8

이 문제를 해결할 방법을 찾은 사람이 있습니까?