Conversation
if server with the specified name exists, its config is returned in exactly the same form as a create response.
Gruntfile.js
Outdated
| } | ||
| }, | ||
|
|
||
| "postmark-servers": { |
There was a problem hiding this comment.
This is a neat idea. Can you move this to a separate PR? I think we should try to focus on sending and syncing templates with existing servers for now.
Gruntfile.js
Outdated
| build: { | ||
| name: "testing-template-node-js-" + new Date().valueOf(), | ||
| subject: "Testing grunt-postmark-templates", | ||
| // NOTE these are read from filesystem. globbing not supported |
There was a problem hiding this comment.
I know that grunt has fancy src and dest file handling but in my first pass I did it in a less idiomatic way.
Gruntfile.js
Outdated
| name: "testing-template-node-js-" + new Date().valueOf(), | ||
| subject: "Testing grunt-postmark-templates", | ||
| // NOTE these are read from filesystem. globbing not supported | ||
| htmlFile: 'test/email.html', |
There was a problem hiding this comment.
For consistency with our API, can you rename these to htmlBody and textBody?
There was a problem hiding this comment.
In order to distinguish between literal htmlBody and htmlFile(filename) the task will accept either. I'll update the gruntfile to indicate this, and hopefully that will make it clearer.
There was a problem hiding this comment.
After working on this some more, I now agree with you @derekrushforth that these should be htmlBody and textBody. The entire workflow with mailmason is file based, so it doesn't really make sense to allow literal strings for template bodies.
Gruntfile.js
Outdated
| } | ||
| }, | ||
|
|
||
| "postmark-templates": { |
There was a problem hiding this comment.
Having separate tasks for pushing new templates and editing existing templates might be hard to manage for users.
I imagine this would work as a single task(grunt postmark-sync), where it creates a new template if the referenced template isn't found on the server, otherwise it updates the existing template.
That way users don't have to worry about what lives on the server and what doesn't.
There was a problem hiding this comment.
I built postmark-server to be idempotent, which wasn't too hard. The issue I encountered with doing the same for postmark-template is that you need the templateID to update, as I don't think template names are unique identifiers.
tasks/grunt-postmark-templates.js
Outdated
| htmlBody: htmlBody, | ||
| subject: _data.subject || options.subject, | ||
| }, function(err, response) { | ||
| handleResponse(err, response, done); |
There was a problem hiding this comment.
I'd like to get editTempate (update) working as well, but haven't figured out where the templateIDs will come from. It might make sense to move this to a separate grunt plugin.
Can you see the TemplateId being returned from this response object? From here, could you maintain a reference to the email template in the file system, the server(s) it lives on, and template ID of server in an external JSON file?
I know it's a bit tough to manage on the plugin end, but it would be super nice for users to not even think about this.
There was a problem hiding this comment.
A private config that the plugin maintains could look something like this:
[
{
"name": "welcome",
"htmlBody": "test/welcome.html",
"textBody": "test/welcome.txt",
"servers": [
{
"token": "1234-5678",
"templateId": "123456"
},
{...}
]
}, {...}
] There was a problem hiding this comment.
For our system that will be stored in a database, which I imagine to be in a separate user-space gruntfile. Pulling it from another JSON config file (as you do with secrets.yml) seems like the idiomatic way to do it for Grunt. In my user-space gruntfile I imagine setting the config entries which are then used by the postmark gruntfile.
|
Just for reference :) |
|
simplified the configuration so that the user just specifies a set of templates in this form: templates.json: {
"confirm_email": {
"subject": "SiteWorx: Confirm your email",
"htmlBody": "dist/confirm_email.html",
"textBody": "dist/confirm_email.txt"
}
}or in the Mailmason Gruntfile: "postmark-templates": {
"confirm_email": {
"subject": "SiteWorx: Confirm your email",
"htmlBody": "dist/confirm_email.html",
"textBody": "dist/confirm_email.txt"
}
}The next step will be to use a templateID for update if it appears in the configuration. I'd also really like to write out a json file when the copies are finished with the new {name, templateID} pairs (possibly the templates.json file) because I need this information to configure my template-using app. |
|
@derekrushforth @hybernaut Hello guys, any progress on this PR? It's already done or have some critical issues? |
|
Any updates on this PR? Would love to have this to help with our automated builds. |
|
I have not looked at this in a while, but I've been using it regularly since filing the PR. |
4 participants
No description provided.