potência do motor Velocidade extra

Question

Eu tenho uma variedade de arquivos de modelo Velocity que representam mensagens de correio electrónico. Estou à procura de uma maneira elegante para permitir que o arquivo de modelo para a saída de uma linha de assunto da mensagem, bem como o conteúdo. Eu considerei algumas opções:

1. Faça a primeira linha da saída algo como "Assunto: Bla" e tira-lo no Java. I têm rejeitado esta abordagem, porque realizando corda manipulação fantasia de Java é exatamente o problema que estou tentando resolver usando Velocity em primeiro lugar.

2. Jogue um objeto configurável para o mapeamento para algum código na macro Velocity para chamar um setter por diante. Prós: simples bonito. Contras: Eu não gosto da ideia de objetos externos de velocidade, mesmo que apenas uma forma de saída. Pode ser uma aversão irracional, apesar de tudo.

3. Criar algum comando Velocity personalizado, como #setSubjectLine. Prós: mais elegante. Contras: seria aplicável como um comando válido para todos os meus modelos, independentemente de se eles são e-mails ou não

.

4. arquivos de modelo em separado tem para a linha de assunto e o resto do e-mail. Pro: Sem truques especiais em tudo! Con:. Nem todas as vidas lógica de e-mail no mesmo lugar

5. Alguns truque legal Velocity eu não sei.

6. ???

Então, o que devo fazer? Você tem uma sugestão para 5 ou 6? A razão pela qual eu deveria escolher 1, 2, 3 ou 4?

Answer 1

2) Jogue um objeto configurável para o mapeamento para algum código na macro Velocity para chamar um setter por diante. Prós: simples bonito. Contras: Eu não gosto da ideia de objetos externos de velocidade, mesmo que apenas uma forma de saída. Pode ser uma aversão irracional, apesar de tudo.

Esta foi a minha abordagem, e estou satisfeito com ele, apesar de meus próprios receios semelhantes à primeira. I até mesmo definir a codificação de caracteres e outros atributos dessa maneira. Isso deixa o resto do modelo como o corpo da mensagem. Mais uma vez, estou satisfeito.

#set ( $myAtts.encoding = "utf-8" )
#set ( $myAtts.from = "stu@nowhere.net" )

Answer 2

No $work fazemos 4. Ele funciona muito bem, e o argumento contra o não toda a lógica email vivendo no mesmo lugar parece um pouco rigoroso. Você teria apenas dois arquivos de velocidade ao lado do outro. E mesmo com apenas um arquivo de modelo, você ainda tem lógica para preencher os dados, determinar os destinatários, anexar os anexos, e assim por diante, que também não vive no arquivo Velocity.

---

Eu preferiria 2 sobre 3, só porque eu não gosto de macros Velocity. Usando objetos Java parece mais flexível.

$mailContext.setSubjectLine($subject)

Com 2 ou 3, você pode chegar mais perto de seu objetivo de ter tudo em um só lugar: Você poderia começar Velocity para definir a lista de destinatários, também, por exemplo. Este, um outro lado, parece entrar em conflito com a idéia de Velocity ser uma tecnologia de modelagem pura.

Uma coisa a considerar aqui é que está escrevendo os modelos Velocity. Quanto mais perto se chega ao "usuários finais", a menos que você quer incomodá-los com (e mantê-los de brincar com) qualquer coisa que não está directamente relacionado com a criação de conteúdo de e-mail.

---

Não tenho certeza se isso é viável, faz sentido ou é mesmo possível com a API Java Mail, mas apenas para ser completo:

6. Tem velocidade de criar toda a mensagem de e-mail incluindo os cabeçalhos, não apenas conteúdo e assunto. Há diferença para 1 é que você não precisa de pós-processo esta saída, pode ir direto para o agente de transporte de correio. Provavelmente não funciona com anexos.

To: $to
CC: $cc
Subject: $subject

Here comes the content.