모든 상하문 값이 빈 문자열로 나타나는 것을 허용하지 않습니다

묘사

pystache에서 None이라는 값을 전달하고 그것을 {{name}이라고 부르면 "None"으로 돌아갑니다. 만약mustache에 값이 하나 있고 그것을 "None"이라고 부르면 "None"을 얻을 수 있습니다.이것은 템플릿이 클라이언트에서 왔는지 서버에서 왔는지에 따라 일치하지 않을 수 있습니다.
가장 좋은 처리 방법은 무엇입니까?

토론 #1

규범도 빈 문자열이 아니라 빈 문자열을 되돌려야 한다는 것에 동의하는 것 같다.
https://github.com/mustache/spec/blob/master/specs/interpolation.yml#L106

토론 #2

나는 이 문제를 해결하기 위해 인출 요청을 했지만 그것이 정확한 실현 방식인지 아닌지 확실하지 않다(#131)

토론 #셋

If I pass an object with a None value in pystache and call it {{ name }}, it returns "None"

일부러 그런 거야.예를 들어 설명서this--
"이 태그의 컨텐트는 대체 태그의 데이터 이름입니다...보간하기 전에 데이터를 문자열로 강제로 변환하고 적절한 경우 이스케이프해야 합니다."
파이썬에서 --

>>> str(None)
'None'

심지어 이런 행위here(예를 들어 0와 False를 검사하는 테스트도 있다.

This is resulting in inconsistent rendering dependent on if my template is coming from client side or server side.

Mustach의 구현에 따라'거짓'값에 대한 처리 방식이 다르다는 것은 잘 알려져 있다.예를 들어, 스레드 참조this issue.

What is the best way to handle this?

만약 어떤 내용을 빈 문자열로 나타내기를 원한다면, 내 조언은 빈 문자열의 값을 현저하게 주는 것이지, None 로 표시하는 것이 아니다.이것은 너에게 쓸모가 있니?

토론 #4

The spec also seems to agree that it should return empty string, not None: https://github.com/mustache/spec/blob/master/specs/interpolation.yml#L106

텍스트를 읽으면 "실패한 상하문 검색은 기본적으로 빈 문자열이어야 합니다."라고 합니다.키를 찾을 수 없음(찾기 실패)과 값이 None인 키 사이에 차이가 있습니다.만약 잃어버린 키를 시도해 본다면, 빈 문자열을 되돌려서 일하는 것을 발견할 수 있을 것 같다.사실, 이것은 Pystache가 모든 규범 테스트(여기서 인용한 테스트 포함)를 실행하기 때문에 그 단원 테스트 세트의 일부가 되어야 합니다!

토론 #5

이 값을 빈 문자열로 설정하는 것은 의미가 없습니다. None/null이기 때문에 값이 설정되지 않습니다.나는 단지 그것을 일치하게 유지하고 싶을 뿐이다. 이렇게 하면 나는 수염을 쓸 수 있다.js나pystache에서 같은 템플릿을 가져옵니다.만약 같은 결과를 되돌려 보려고 시도하지 않는다면, 서로 다른 언어로 실현하는 것은 무의미하다.

토론 #6

당신은'자전'을 사용합니까, 아니면'대상'형식의 상하문을 사용합니까?

It wouldn't make sense to set these values as empty strings because they are None/null, they haven't had a value set.

하지만 너는 이 값을'무'로 설정했다.앞에서 말한 바와 같이 상하문 키가 존재하지 않는 것과 상하문 키가 존재할 때 값이 없는 것은 차이가 있다.값이 없으면 왜 키를 삭제하지 않습니까?그렇지 않으면 [없음] 값을 빈 문자열로 설정하는 것은 렌더링 정합성을 얻기 위한 작은 대가인 것 같습니다.
서로 다른 Mustach를 고수해 부런, null, 논 등에서 같은 행동을 하는 것은 이미 달라졌기 때문에 실패한 싸움이다.수염은 이렇다.내가 위에서 언급한 그 선을 보고 네가 한번 맛보게 해라.
아마도 우리는 API를 통해 어떤 방식(예를 들어 어떤 방법을 다시 쓰거나 주입류를 허용하는 등)으로 부울 값, 무등의 다른 표현을 공개할 수 있을 것이다.

토론 #7

맞춤형 행동을 허용하는 것을 고려하지만 시간이 좀 걸릴 수 있습니다.

토론 #8

네, 커버하기 쉬우면 완벽해요.내가 전달하는 상하문은 SQLAlchemy 대상의 목록이기 때문에 데이터베이스에 있는 값이null이면 결과 속성에 설정된 값은None입니다.내가 정말 가치가 있을 리가 없어.

토론 #9

와 동시에 데이터를 정화하고 None를 ''로 설정할 수 있습니까?

토론 #10

저는 새pull 요청 #132를 만들었습니다. 그러면 위아래 문장을 쉽게 덮어쓰고 원하는 일을 할 수 있습니다.그것은 완전히 뒤로 호환성을 유지하기 때문에 어떤 것도 파괴되지 않고, 단지 내가 물건과 수염을 매칭할 수 있도록 허락한다.js

토론 #11

@cjerdonek은 당신에게 충분합니까?그것은 나의 요구를 완벽하게 만족시켰고 현재의 사용을 파괴하지 않을 것이다.

토론 #12

나는 곧 앉아서 API의 변화를 고려하고 싶다. 이번 주말을 위해 계획을 세우고 싶다.나는 렌더링 구조 함수에 다른 키워드 파라미터를 추가하는 데 열중하지 않는다. 왜냐하면 이것은 쉽게 제어할 수 없기 때문에 이것은 특수한 수요이다.내가 고려하고 싶은 대체 방안은 Renderer 클래스에서 다시 쓸 수 있는 방법이 있고, 기록되지 않거나 일시적인 API 변경 사항을 공개할 수 있으며, 우리는 나중에 필요에 따라 조정할 수 있으며, context 클래스를 모듈의 속성으로 설정할 수 있습니다.
이 변화의 또 다른 의미는 만약에 우리가 사용자 정의 상하문 클래스를 지원하기 시작한다면, 우리도 상하문 클래스의 인터페이스를 확정하고 있는데, 이것은 아직 진정으로 고려한 적이 없다는 것이다.그것은 더 많은 세부 사항을 실현하는 내부 클래스로 설계되었다.그래서 만약 우리가 이 길을 걷게 된다면 일은 더욱 약해질 것이다.

토론 #13

"pystache와mustache.js 간의 차이"에서 "상하문 값이 빈 문자열로 나타나는 것을 허용하지 않습니다"로 다시 명명합니다인내심 고마워요.나는 개발 부서에서 이 문제를 해결하겠다고 약속했다.
나는 Context 클래스가 아닌 Renderer 클래스에서 이 문제를 해결하기로 선택했다. 왜냐하면 Context 값이 어떻게 나타나는지는 Context 클래스가 알아야 할 문제가 아니라 나타나는 문제이기 때문이다.