아날로그 메일 클라이언트의 제한

묘사

메일 클라이언트는 많은 제한이 있다.gmail에서 모든 css는 원소에 내연되어야 합니다. 그렇지 않으면 css를 볼 수 없습니다.
브라우저에서만 html을 보는 것은 큰 도움이 되지 않는다.gem는 반드시 메일 클라이언트의 행위를 모방하여 완벽한 테스트 도구로 만들어야 한다
다음은 서로 다른 메일 클라이언트가 지원하는 css 요소 목록입니다.
http://www.campaignmonitor.com/css/

토론 #1

편지 봉투에서 이렇게 할 필요가 없다.다음 서비스를 사용할 수 있습니다.http://getfractal.com.아마도 letter opener는 그들의 API와 통합할 수 있습니까?

토론 #2

하지만 이gem는 실제 메일을 보내지 않고 html메일을 개발하는 데 도움을 줄 수 있을 것이다.만약 메일의 실제 모습을 볼 수 없다면, 나는 어떻게 해야 합니까?그래서 나는 어쩔 수 없이 메일을 보낼 것이다.그렇다면 이런 보석을 사용하는 의미는 무엇일까?

토론 #셋

HTML을 복사하고 붙여서 테스트할 수 있을 것 같아서 다른 서비스(예를 들어 Litmus와 Campaign Monitor도 허용할 수 있을 것 같습니다.그러나 API는 이러한 서비스와 잘 통합될 것입니다.

토론 #4

네, 맞아요.나는 메일을 보내는 것이 아니라 결과를 보고 싶을 때마다 복사하고 붙여넣기:)?

토론 #5

API를 사용할 수 있을 때 도대체 왜 복사/붙여넣기:http://litmus.com/api및http://getfractal.com/rest_api-

토론 #6

이 API들은 당신에게 외관을 보여주지 않았기 때문에 html만 복구하고 결과를 보냅니다.리트머스는 캡처만 생성할 수 있다.그리고 돈도 써야 돼.
전자 우편을 보내는 것이 여전히 해결 방안보다 낫다.

토론 #7

헤이, 나는 단지 누군가가 API 통합을 시작하기로 결정하기 전에 이것은 네가 동시에 할 수 있는 일이라고 말하고 싶었을 뿐이야:)
나는 이gem를 사용하고 싶다. 더 많은 것은 내용, 링크 등을 검사하는 것이지, 레이아웃을 테스트하는 것이 아니다. 진정한 전자메일을 보내는 것이 영원히 가장 좋은 방법이다.

토론 #8

나는 각종 메일 클라이언트를 모방하는 것이 매우 좋을 것이라고 생각하지만 어디서부터 시작해야 할지 모르겠다.무슨 건의가 있습니까?
편지 오픈기는 진정한 디자인 도구가 아니라 메일이 발송되고 정상적으로 작동하는지 검증하는 도구이다.만약 복잡한 HTML 전자메일을 설계하고 있다면, 원본 메일 클라이언트에서 실제 발송과 테스트를 하는 것이 가장 좋다.
동시에 동적 교부 행위를 맞춤형으로 만드는 더 좋은 방법이 있을지도 모른다.아마도 이것은 전통적인 교부 방식으로 돌아가는 방식일 것이다.

토론 #9

미리 보기 맨 위에 전자 우편 필드와 제출 단추가 있는 폼이 있는 것은 좋은 생각일 수도 있다. 그러면 내용이 마음에 들면 보낼 수 있다.
전자 우편 필드는 자동으로 원본 수신자의 주소를 채울 수 있지만,[email protected]"개발 환경에서 다른 내용으로 변경할 수 있습니다.

토론 #10

네, 이것은 특정한 프레임 응용 프로그램이 폼 요청을 처리하고 메일의 발송을 처리하는 설정 옵션이 필요합니다.나는 이 보석을 간단하게 유지하고 싶다.
보통, 서로 다른 클라이언트에서 메일의 외관을 테스트하려면, 처음부터 이런 행동으로 전환해야 한다.이것은 시작할 때 간단한 env 변수나 config 옵션을 통해 완성할 수 있습니다.

# config/environments/development.rb
if ENV["MAIL_DELIVERY"] == "sendmail"
  config.action_mailer.delivery_mode = :sendmail
else
  config.action_mailer.delivery_mode = :letter_opener
end

또는 어떤 임시 저장 환경을 이용하여 실제 우편물 전달을 진행한다.

토론 #11

비록 나는 Gmail과 다른 메일 클라이언트의 기능을 모의하는 것을 매우 좋아하지만, 나는 아직 이 기능을 추가할 계획이 없고 이렇게 할 가치가 있다고 생각하지 않는다.95퍼센트의 시뮬레이터가 그곳에 있어도, 디자이너가 전자메일에서 전자메일을 테스트해서 업무를 확보해야 한다. 전자메일은 이동의 목표이며, 모든 다른 메일 클라이언트는 말할 것도 없다.나는 또한gem과 유사한mail 시도가 디자이너의 업무 절차에 더욱 적합하다고 생각한다. 그들은reload를 클릭하여 자신의 변경 사항을 볼 수 있다.
만약 이 기능이gem를 너무 복잡하게 하지 않는다면, 나는pull 요청을 받아들일 것입니다. 그러나 지금 이 문제를 끝냅니다.

토론 #12

유닉스의 이념을 인용하여 마지막 논평을 제시했다. "한 가지 일을 하고 잘하는 프로그램을 작성하라."나의 건의는 서로 다른 메일 클라이언트의 요청을 시뮬레이션하지 말라는 것이다.이것은 단독의 임무다.