Is there a way to conditionally end an action, yet still honor the AFTER SUCCESS configuration?
I have a multi-step action that includes this JavaScript at the end of the second-to-last action. The last action is an HTML Preview step.
if (previewListAfterSuccess) {
// Refer to the next action step: HTML Preview
draft.setTemplateTag("list_content", d.content);
} else {
// Do not continue with the next action step.
context.cancel();
}
The context.cancel() above does end the action, but the AFTER SUCCESS configuration is ignored because of the cancel.
Possibly the easiest way is to script the „after success“ stuff into the else path here. (I suppose you don’t want to execute the action steps afterwards).
The only action context options are succeed (which is implicit), cancel, and fail (which are both explicit). Succeed will continue through the remaining steps. Cancel and fail are explicitly saying do not continue (and specifying a type of stop for notification/logging).
There is no branching or step-skipping, just a linear sequence when it comes to action steps; unless for example you programmatically set template tags and then use those tags to dynamically call other actions by name. But that requires multiple actions to accommodate.
What I would recommend doing is redesigning that last part of your action and keeping your logic inside of the script action.
In Drafts scripting, I think I’m right in saying you can do anything you can do in an action step. If there is something you cannot do, I don’t think I’ve needed to do it yet. So what you would want to do is bring that final HTML Preview step backward into the script step and into the “true” part of your if statement. I would remove the else part entirely as you do not want to cancel, you wish to succeed whether or not your preview is to be shown.
There is an example at the top of the HTMLPreview class reference that you can use as the basis for preparing your own scripted HTML Preview.
If you have a complex set of HTML or CSS, consider defining the content within a custom template tag action step earlier in one or more custom template tags earlier in the script, and then using draft.processTemplate() to construct the preview HTML string from static HTML and template tags. I find it leaves the code looking less cluttered that way and makes your HTML/CSS a little bit easier to maintain because it is not wrapped in JavaScript.
I would not take this approach. The reason being the end user could change what the after success processing is on an action (archive, add a tag, etc.), I don’t think you could accommodate that easily through adding code in. It would only be possible if you did not expect the end user to ever set any after success action - which wouldn’t be a good design for the action.
Imagine you do this, then the end user changes it, and the result is it still sometimes never applies, and when it does, it may even conflict or combine with what the action is doing.
@sylumer, this suggestion seems like a great approach. But unfortunately when I tried various combinations of draft.setTemplateTag(), draft.processTemplate(), HTMLPreview.create(), and preview.show(), I’ve come up short. Clearly I’m missing something fundamental.
Might you be able to point me to an example that uses your suggested approach? Note that the list that I’m attempting to preview is a draft in markdown format.
The HTMLPreview is pretty straightforward, and there’s demo code on that page. It takes HTML, and displays it in a preview window.
I assume where you are stuck is constructing the HTML? This would be an example with a template in a string variable:
const template = `<html>
<head><title>Title</title></head>
<body>
%%[[draft]]%%
</body></html>`
// pass template through template engine to replace tag values
const html = draft.processTemplate(template)
// show that html in a preview
let preview = HTMLPreview.create();
if (preview.show(html)) {
// continue button was pressed
}
else {
// cancel button was pressed
}
I think @sylumer was suggesting it would be easier to manage your preview template in a “Define Template Tag” step earlier in the action. If you did that, you could retrieve the template by evaluating the tag. So if you had a define step for the tag “my-template”, you could get that value to use as your template for the preview like:
Here’s an example that holds the CSS in one tag, the Markdown in another tag, but also pulling in the CSS and some Drafts data through a standard tag too.
It uses the conditional structure to choose whether or not to show the preview - in this case based on choice via a prompt. If no preview is chosen, then I’ve added in a message just so you can see it is processing.
Hi, @sylumer. Thanks for the reply and example! That seems to work reliably and I understand the code you provided. Much appreciated!
Unfortunately, I’m seeing an intermittent issue when I attempt to set the markdown within the code. Here’s a simple example:
const md = "## Title";
draft.setTemplateTag("my_markdown", md);
// Prep Markdown to HTML conversion using the MMD engine
let mmdContent = MultiMarkdown.create();
mmdContent.format = "html";
// Show the preview of the rendered content based on the content specified by tags in the action
let hpMain = HTMLPreview.create();
hpMain.show(mmdContent.render(draft.processTemplate("[[mdcontent]]")));
I’ve never seen a timing issue on that. You could try explicitly splitting out the HTML generation strps from the display to see if that makes any difference.
// Show the preview of the rendered content based on the content specified by tags in the action
let strMMD = draft.processTemplate("[[mdcontent]]");
let strHTML = mmdContent.render(strMMD);
let hpMain = HTMLPreview.create();
hpMain.show(strHTML);
If you want to retrieve and use as a template a value you created previously in a define template tag, you should retrieve its value using drafts.getTemplateTag – and then pass that value through the template processor.
It’s a subtle difference, but try:
let strMMD = draft.getTemplateTag("mdcontent");
let strHTML = mmdContent.render(strMMD);
let hpMain = HTMLPreview.create();
hpMain.show(strHTML);
You might just want the template to incorporate your Markdown processing where appropriate, because I don’t think you really want to be passing your full HTML template through the Markdown processor – but rather just the actual Markdown content. You do that by wrapping values in the template with %% %%. So you can just get the template value, and call processTemplate on it without the extra Markdown renderer steps.
On that particular point, doesn’t Markdown include HTML? I.e. Markdown as a format recognises HTML as valid, and renderers just skip it leaving it unchanged when transforming Markdown to HTML.
When writing in Markdown for me website it isn’t uncommon for me to have to put some HTML amongst the more typical Markdown in my Markdown file to get something to render how I want.
A little off-topic, but I guess it depends. Markdown is designed to support inline content HTML, but not necessarily structural HTML – and it’s supposed to be separated block-level elements.
Most newer, more advanced parsers, like MultiMarkdown and mark in Drafts, are pretty savvy about ignoring and leaving intact various HTML, but you can get some weird results even with them, and other parsers don’t handle it well at all.
For example, if you run this text:
<html>
<head>
<title>WAT</title>
</head>
<body>
## My Markdown
This *is* it.
</body>
</html>
In fact it seems that I don’t need to render the markdown in the code since %%[markdown]%% within a Define Template Tag action step seems to work as expected (assuming I order the action steps properly as @sylumerdemonstrated above.)
I think if it was purely order, the results would have been consistent - alway work or always fail. If there was a timing element to it and moving it to the start changed the timing enough to deal with any race condition on setting the tag, that could explain the result.
If you want a technical explanation, Drafts template engine is not recursive, a tag cannot return additional tags and expect them to be evaluated. Tags are evaluated sequentially, but not in any guaranteed order. So what you really want to do is for this case is the below - where you retrieve the value of the template and use it, not rely on tag evaluation to insert it’s content:
let hpMain = HTMLPreview.create();
let template = draft.getTemplateTag(“template”)
hpMain.show(draft.processTemplate(template));
