I'm using markojs for my emails templates but now we are moving these templates inside our database to edit them online.
We still need to use marko to keep our full HTML structure and variables behavior aswell.
I've found 2 ways to get templates as string like renderSync() method but it need the template to exist as file before or with compile() but I don't know how to make it work with variables handling.
You can use Marko's load method to compile templates and get back the template instance which you can then render to get the final HTML:
const template = require("marko").load(templatePath, templateSource, compilerOptions);
const html = template.renderSync(data);
You probably don't need to pass any custom compilerOptions and can omit the last argument.
Even though your template doesn't exist on disk, you still need to pass a templatePath to a real directory with a dummy .marko file. For instance you could do this:
const templatePath = path.join(__dirname, `${database.id}.marko`);
The templatePath is used for two purposes:
As a key for node's require cache. If you request to compile the same filename multiple times, you will get the original compilation. This might mean you need to purge the require cache when a template is edited: delete require.cache[templatePath];
To discover custom Marko tags. If you have custom tags/components that are intended to be used by the email templates, you should make sure that the path specified by templatePath allows those tags to be discovered.
Related
I've applied the guidance on programmatic usage of M2Doc (also with this help) to successfully generate a document via the API, which was previously prepared by using the M2Doc GUI (configured .docx plus a .genconf file). It seems to also work with a configured .docx, but without a .genconf file.
Now I would like to go a step further and ease the user interface in our application. The user should come with a .docx, include the {m:...} fields there, especially for variable definition, and then in our Eclipse application just assign model elements to the list of variables. Finally press "generate". The rest I would like to handle via the M2Doc API:
Get list of variables from the .docx
Tell M2Doc the variable objects (and their types and other required information, if that is separately necessary)
Provide M2Doc with sufficient information to handle AQL expressions like projectmodel::PJDiagram.allInstances() in the Word fields
I tried to analyse the M2Doc source code for this, but have some questions to achieve the goal:
The parse/generate API does not create any config information into the .docx or .genconf files, right? What would be the API to at least generate the .docx config information?
The source code mentions "if you are using a Generation" - what is meant with that? The use of a .genconf file (which seems to be optional for the generate API)?
Where can I get the list of variables from, which M2Doc found in a .docx (during parse?), so that I can present it to the user for Object (Model Element) assignment?
Do I have to tell M2Doc the types of the variables, and in which resource file they are located, besides handing over the variable objects? My guess is no, as using a blank .docx file without any M2Doc information stored also worked for the variables themselves (not for any additional AQL expressions using other types, or .oclAsType() type castings).
How can I provide M2Doc with the types information for the AQL expressions mentioned above, which I normally tell it via the nsURI configuration? I handed over the complete resourceSet of my application, but that doesn't seem to be enough.
Any help would be very much appreciated!
To give you an impression of my code so far, see below - note that it's actually Javascript instead of Java, as our application has a built-in JS-Java interface.
//=================== PARSING OF THE DOCUMENT ==============================
var templateURIString = "file:///.../templateReqs.docx";
var templateURI = URI.createURI(templateURIString);
// canNOT be empty, as we get nullpointer exceptions otherwise
var options = {"TemplateURI":templateURIString};
var exceptions = new java.util.ArrayList();
var resourceSetForModels = ...; //here our application's resource set for the whole model is used, instead of M2Doc "createResourceSetForModels" - works for the moment, but not sure if some services linking is not working
var queryEnvironment = m2doc.M2DocUtils.getQueryEnvironment(resourceSetForModels, templateURI, options);
var classProvider = m2doc.M2DocPlugin.getClassProvider();
// empty Monitor for the moment
var monitor = new BasicMonitor();
var template = m2doc.M2DocUtils.parse(resourceSetForModels.getURIConverter(), templateURI, queryEnvironment, classProvider, monitor);
// =================== GENERATION OF THE DOCUMENT ==============================
var outputURIString = "file:///.../templateReqs.autogenerated.docx";
var outputURI = URI.createURI(outputURIString);
variables["myVar1"] = ...; // assigment of objects...
m2doc.M2DocUtils.generate(template, queryEnvironment, variables, resourceSetForModels, outputURI, monitor);
Thanks!
No the API used to parse an generate don't modifies the template file nor the .genconf file. To modify the configuration of the template you will need to use the
TemplateCustomProperties class. That will allow you to register your metamodels and service classes. This instormation is then used to configure the IQueryEnvironment, so you might also want to directly configure the IQueryEnvironment in your code.
The generation in this context referes to the .genconf file. Note The genconf file is also an EMF model, so you can also craft one in memory to launch you generation if it's easier for you. But yes the use of a .genconf file is optional like in your code example.
To the list of variables in the template you can use the class TemplateCustomProperties:
TemplateCustomProperties.getVariables() will list the variables that are declared with their type
TemplateCustomProperties.getMissingVariables() to list varaibles that are used in the template but not declared
You can also find le list of used metamodels (EPackage nsURIs) and imported services classes.
The type of variables is not needed at generation time, it's only needed if you want to validate your template. At generation time you need to pass a map from the variable name to its value as you did in your example. The value of a variable can be a any object from your model (an EObject), a String, an Integer, ... If you want to use something like oclIsKindOf(pkg::MyEClass) you will need to register the nsURI of pkg first see the next point.
The code you provided should let you use something like projectmodel::PJDiagram.allInstances(). This service needs a ResourceSetRootEObjectProvider() that is initialized in M2DocUtils.getQueryEnvironment(). But you need to declare the nsURI of your metamodel in your template (see TemplateCustomProperties). This will register it in the IQueryEnvironment. You can also register it yourself using IQueryEnvironment.registerEPackage().
This should help you finding the missing parts in the configuration of the AQL environment. Your code seems good and should work when you add the configuration part.
According to the latest Django Documentation for templates namaspace, we should put our templates in the order.
app/templates/app/template_files
But the default location it looks for templates is app/templates/, why not simply create a template file in templates sub-folder ?
Template namespacing
Now we might be able to get away with putting our templates directly in polls/templates (rather than creating another polls subdirectory), but it would actually be a bad idea. Django will choose the first template it finds whose name matches, and if you had a template with the same name in a different application, Django would be unable to distinguish between them. We need to be able to point Django at the right one, and the easiest way to ensure this is by namespacing them. That is, by putting those templates inside another directory named for the application itself.
According to the explanation give in the documentation my approach would lead to ambiguity. so let's say we have two apps viz.
app1 & app2 and they have index.html in app/templates/ path, why can't django distinguish between two different path - /app1/templates/index.html & /app2/templates/index.html ?
Is it possible to create a custom variable in CMS Made Simple that could be set in one template and then this value would be available in another template for the same site?
Edit:
I forgot to add that the template I want to set the variable in is using a different domain, although it is the same site. This means I can't use cookies or session vars.
You can use the smarty assign or capture system:
{assign var="foo" value="bar"}
{capture name="foo"}bar{/capture}
Please note that this depends on the order of the templates are executed. For example, in most scenarios, everything inside is executed before everything inside from the main template.
I wonder if it's possible to store/restore the Ember.TEMPLATES cache object in the localStorage of the client?
The reason why I want to do this is because I'm not sending the client the whole bunch of precompiled templates at first, but loading them 'on demand' from the backend server. Now, if the user decides to reload the browser, I want to save/restore the whole Ember.TEMPLATES object so that the client doesn't need to query the backend server again for already requested template files.
I'm able to store the templates in the localStorage with the following function, but I guess it's not pretty (or performance optimized) at all:
saveCacheToLocalStorage: function() {
var stringifiedCache = "{ ";
for(var tmpl in Ember.TEMPLATES) {
stringifiedCache += JSON.stringify({name: tmpl, template: Ember.TEMPLATES[tmpl].toString()});
}
stringifiedCache += " }";
localStorage.setItem(this.localStorageId, stringifiedCache);
this.hasChanged = false;
return true;
}
but if I try to parse the stringified value from the localStorage it fails because of an Syntax Error: Unexpected token: {. Is there a better solution for my problem?
I am not able to deliver all precompiled templates at first, because the users of the web application access different areas and use different functions of the web app so it is not acceptable to serve the full set of templates to each and every user.
EDIT
There were some errors in my scripts and now I'm able to store/restore templates in the localStorage, but I had to create another cache which temporarily stores the templates I fetch from the web server so that I am able to save them to the localStorage. Somehow I'm not able to get the templates from Ember.TEMPLATES itself, as I'm always getting the same function in return which is pretty useless (some general stuff for deprecation warnings, etc).
You can't, even when the syntax is correct, it still will not work because the template functions is generated and contains closure (scoped) information.
Your best bet is to precompile all the templates to a single templates.js and use (abuse) localStorage to cache the whole template script. (Manually, or with http://addyosmani.github.io/basket.js/)
Please note that localStorage is synchronous so it will block and might hang the browser for big template script.
If you must do this, don't cache the compiled templates (they're functions and can't be stored in localStorage). You can cache the templates themselves, and rebuild the compiled templates as you read them out of localStorage. (Remember to expire the template yourself when you need to. localStorage doesn't expire on its own.)
I'm trying to obtain a visual representation of the templates of a Django project, as a hierarchy.
The main idea is to get a list of template names as the default template loading machinery would return (ie honoring TEMPLATE_DIRS, TEMPLATE_LOADERS, etc.) and then parsing the templates looking for {% block %} and {% extends %} tags, in order to create a tree structure. Finally use grapviz for the visualization.
I'm not sure if it's a viable approach. But just to start, how can I load the templates the way I described?
Or maybe, does something similar already exist?
Normally, templates are looked up by names online, there is no root entry for every template that might be used.
Thus if you want to grep all used templates in a project, you need to scan every place that loaders in TEMPLATE_LOADERS might check, to generate possible entries for later bottom-to-up checking. This would be hard, some backends of loaders might even does not allow fetch-by-directory operation.
Or you could parse views and urls files inside INSTALLED_APPS to grep template names, but this only works w/ hard-coded name of template and even more difficult.
Also, there might be templates loaded from hard-coded string...
For a given template name, its easier to load the template and check nodes inside it, just as your idea. You could check django.template.base to know how it works.
Furthermore, you could take advantage of django-debug-toolbar to show the templates used for a request. And, IMO, keeping template structure flat, simple and thus determined, is easier to achieve.