Referencing another Jade file from within one:
include ../widget
Renders HTML like this:
<include>../widget</include>
Using Scalatra, specifically. What am I doing wrong?
Scalate Jade is different than JavaScript Jade, so the tag isn't the same. You have to reference the filename in full, like so:
- include("../widget.jade")
Related
I am using EJS in the browser (not on the server).
I have some ejs that I would like to use in multiple pages, so I want to put that in its own file, say table.ejs.
Is there a way I can include it in my HTML such that it is immediately accessible to my javascript after onload?
I was thinking something like:
<script id="table-ejs" type="text/ejs" src="ejs/table.ejs"></script>
then in my javascript:
ejs.render(document.querySelector('#table-ejs').???, data)
Is this possible?
I could use the Fetch API to retrieve the ejs file but then I would need to rewrite a lot of code to make it async. I was wondering if I could avoid that.
Well,
place all your ejs-files within a file "views" - within your views you can create another file "partials" - in this file you place your header and footer.ejs.
Within, lets say, your home.ejs you have to include the following code:
<%- include('partials/header'); -%>
// the rest of your code
<%- include('partials/footer'); -%>
You can find more here: https://ejs.co/#docs
I’m using the new TYPO3\CMS\Core\Mail\FluidEmail feature of TYPO3 v10.3 to send HTML system e-mails. Unfortunately, I’m experiencing a weird behavior with Viewhelpers in the e-mail Templates. Calling the regular Viewhelper notation like e.g. <f:uri.resource extensionName="backend" path="Images/typo3_orange.svg"/> works as expected. But inline notations of the same Viewhelper (like {f:uri.resource(extensionName: 'backend', path: 'Images/typo3_orange.svg')}) don’t get processed at all.
Surprisingly, when I call the regular notation first and the inline notation afterwards in the same template, both notations get resolved.
I also experienced that no fluid variables are accessible in the template, e.g. {normalizedParams}, which should be available when you set the request like $message->setRequest($GLOBALS['TYPO3_REQUEST']);
Did anyone experience a similar behavior and has a hint for me?
Here's my implementation in my Controller Action:
$message = GeneralUtility::makeInstance(FluidEmail::class);
$message
->to($email)
->format(FluidEmail::FORMAT_HTML)
->setTemplate('MyTemplate')
->assign('pages', $pages);
if ($GLOBALS['TYPO3_REQUEST'] instanceof ServerRequestInterface) {
$message->setRequest($GLOBALS['TYPO3_REQUEST']);
}
GeneralUtility::makeInstance(Mailer::class)->send($message);
Reference: https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/10.3/Feature-90266-Fluid-basedTemplatedEmails.html
Sounds like a fluid parsing problem. Do you have any { or } flying around in your template that could mess up fluids parsing?
Just run into the same problem with one of my in-house plugins after switching from php7.2 to php7.4 (when switching back to php7.2 the resource path was resolved again correctly).
It turned out that some inline javascript using curly brackets further down the page was to blame (thank you Daniel). Putting it in a separate file solved the issue. It would appear that the use of inline JS is tolerated to different degrees depending on the php version being used.
I am reading the docs about calling clientlibs in sightly.
I am not getting the below syntax
<sly data-sly-use.clientlib="/libs/granite/sightly/templates/clientlib.html"
data-sly-call="${clientlib.all # categories='clientlib1,clientlib2'}"/>
why we are using category here? How does it related to clientlibs?
Lets break this down:
<sly> - is a sightly tag that does nothing :) So when you don't want to use an HTML tag you can use <sly> as a placeholder.
data-sly-use.clientlib="/libs/granite/sightly/templates/clientlib.html - this line references the clientlib.html file that has templates marked with data-sly-template attributes. These templates are reusable piece of markup. Look at them as functions in htl.
data-sly-call - used to call one of the templates from the above clientlib.html
clientLib.all - "all" is the name of the template being called from clientlib.html which is referred using clientLib keyword (-use.clientLib)
# categories='clientlib1,clientlib2 - categories are used to identify cq:clientLibraryFolder that are used for client side code in AEM. If you check http://localhost:4502/libs/granite/ui/content/dumplibs.html it will show you the location of libraries clientlib1 & clientlib2
So in a nutshell, this line calls 2 libraries (containing js & css) with categories clientlib1 & clientlib2 and loads them on to the page/component
I feel like I'm missing something obvious. In working with v0.6.0, the Readme indicates you can use:
{%= partial("partial-name") %}
However, these are just getting printed as plain text. Do I need to use a different engine if I want to have those tags parsed?
Assemble allows using different engines and the example that you have is using lodash with custom delimiters.
To use the default partials helper in handlebars do {{partial "partial-name"}}
Is there a way to set 'basedir' option in jade command line? Or, maybe, another way to use absolute pathing there. Thanks.
Jade has, among other options, the following
-O, --obj <str|path> JavaScript options object or JSON file containing it
So you could write something like this:
jade -O "{basedir:'/home/charlie/Git/ElfSite/Code'}" temp.jade
Or you could create a file called options.json that looked something like this:
{
"basedir": "/home/charlie/Git/ElfSite/Code",
"title": "My Title"
}
And then call jade like this:
jade -O options.json temp.jade
Or like this:
jade --obj options.json temp.jade