How can I change the default templates path?
The initialization function takes path relative to "projectroot/snaplets/heist"
Which is heistInit "templates". So I end up with templates located in "projectroot/snaplets/heist/templates"
I would like my templates in "projectroot/resources/templates" instead.
Is this possible? How do I pass it to the initializer?
Thanks
You can't. Snaplets have to use that directory hierarchy otherwise they won't be fully composable...i.e. what would happen if your app was sub-snaplet of another application. When we first released snaplets, we actually did it the way that you're asking for here. It seemed fine until we tried more complex snaplet hierarchies. If you want to simplify the default as much as possible, you can use heistInit "", which will as you noted store your templates in snaplets/heist.
If you REALLY want to put your templates there, you could add that to the Heist snaplet as another template location using the function addTemplatesAt. But you can't prevent the Heist snaplet's initializer from also looking in snaplets/heist.
Related
Anyone that can point to any documentation on howto reuse code in lit-element.
The problem now is that if I declare an element, in my case a close-button and I want to reuse it by importing it into 2 or more lit-elements, there will be an error in the browser about the close-button being declared more than once.
Understandable enough, but how do I reuse a component, I could of course move the button to a separate file and add it to the document, but then there would be dependencies on that for other components to work.
Any suggestions
If close-button self-registers itself, with a call to customElements.define('close-button', ...), then you should be able to import its defining module and not have any errors due to the module caching behavior of JS.
You must have multiple customElements.define('close-button', ...) calls, so I'd make sure that 1) it's self-registering and you're not registering it again in each component that uses it, and 2) you're using standard JS modules.
After investigating a bit more, I concluded that sharing HTML templates might be the way to do it.
I’m building an electron app. In it, I have a webview with a preload script. Inside said script, I’d like to use sweetalert.
I installed sweetalert with npm install --save sweetalert. Inside my script I load it with require('sweetalert') and call it with swal("Hello world!");. I now notice it doesn’t look right, as the alert is missing its required CSS file. But I’m loading it with require('sweetalert'), which is great since sweetalert can just remain in its directory inside node_modules and I don’t have to care for it, but its CSS is an integral part of it, and is not getting pulled the same way.
Now, what is the recommended way of solving this? Keep in mind I’m inside a javascript file and would like to remain that way. Do I really have to go get the CSS file and inject it in some way? And how would I do it correctly, since it is inside node_modules? After testing it, it seems like it can’t be done in this particular case due to Content Security Policy.
Either way, that seems so clunky in comparison to the require statement, it’d seem weird for a simpler solution to not be available.
You'll have to include it like you would normally do in a browser, for example in index.html. Copy it out of the module folder into your css folder if you have one and link it with the link tag. It depends on if you're using plain electron or some other boilerplate template with there is a gulp/grunt workflow on where to stick it but that's it really, electron is just a browser that's running your JS/html so it's really the exact same process. require only loads the JS module but not the styles.
if you wanted to include it dynamically you could use the same techniques as a regular browser for example (ex. document.write/create element).
I'm not familiar with sweetalert, but hopefully this helps.
Your syntax for require should be something similar to this.
var sweetalert = require('sweetalert')
You should then be able to access methods on the sweetalert object using the following syntax.
sweetalert.someMethod()
Remember requiring just returns a javascript object. Those objects usually have methods that will allow certain functionality. If you want to add sweetalert to your page, you will either need to inject it within the html, or the javascript within the sweetalert module will need to dynamically create html where the css is included. I hope that clarifies some things and helps you get a better sense of some of the inner workings.
First off, I'm very new to Snap and Heist :)
In all templating engines that I have used, there is always a way to pass a variable from the render function to the template. The template can then display the variable in its place. Now, I do understand that Heist is particularly strict, but I'm not even trying to do a loop or an if/else here, just display a random number. I imagine this is a pretty basic thing, but I haven't found anything in the docs that shows how this can be done without using splices.
So in short, is it possible to have a Snap handler that generates a number, then passes it to a Heist template to render, without using splices? If yes, please give me some example code, if no, please show me the simplest way it can be done.
Splices are the way that you pass Haskell information to a template. That's the way you have to do it.
I've been on a mission to learn everything about Yesod, and I'm (somewhat) stuck on the routing system and it's relation to subsites and cross-route linking in general. The first thing I would like to address is the "ResourceR" pattern found throughout the route definitions and Hamlet links.
I notice that the "type" itself (ResourceR) is never addressed or referenced outside of Yesod's TH DSL's. Does this mean that it's only really used as a dummy type, meant only for leveraging Haskell's type safety in referencing Yesod links? I also notice that the functions getResourceR, postResourceR etc. are vital for the app to work, yet it's not explicit where their definitions are used in boilerplate app code. Does Yesod simply reduce the calls to #{ResourceR} to the appropriate function?
I keep feeling like I should be defining ResourceR myself as a datatype, when in fact it's generated and reduced internally by Yesod.
So my question is: do the "resource types" referenced in Hamlet and Route code get automatically generated and reduced by Yesod's DSL's?
Thank you in advance!
Yesod indeed expands what it sees in the the routes file (or what you type in the parseRoutes function in a quasiquotes section), and gives the server the appropriately named get or post function (by prefixing "get" or "post" to the resource name). All that you need to do is create the get/post function, and the framework will use the routes to call the function for you. You need only specify the path and request type.
Centralizing all path information in one location like this makes it easy for you to debug where an individual request will go (think of what the alternative spaghetti code would look like). The forced name standards also keep your code understandable, and code generation removes some of the repetition (ie- it helps you adhere to the dry principle).
I´m trying to understand how the use of the stash plugin will affect the URls of my site.
The traditional way:
I have a template group called site. Within the TG site I have the templates articles, about_us, etc.
The URl will for a single entry be
www.mysite.com/index.php/site/articles/title_of_respective_article
URL for the About-us-page:
www.mysite.com/index.php/site/about_us
Both will reflect the template_group/template structure and thus be SEO-friendly and give users a hint where they are on the site.
But when I use stash I will have 2 wrappers (one for the homepage and one for the rest of the site.
Partials will be used for header, main content and footer.
As far as I understand it, I´ll use the template_groups layout for the wrappers and partials for the main content.
The templating look like
Two wrappers build the TG "layout" Both are hidden, since they should´nt be called directly.
layout
.homepage
.site
Three partials in the TG partials
partials
header
main_content
footer
And by the way shouldn´t those not also be hidden, since they aren´t complete HTML-pages either.
This is what confuses me. How do I get my nice URLs back?
A URL like
www.mysite.com/index.php/site/about_us
will not match the TG/T concept anymore.
Any help?
To expand on both their answers above, and just to be specific to your www.mysite.com/index.php/site/about_us request:
You'd create a template group called "site" and then you may alternatively have something like this code in the /index template
{embed="layout/.site"}
{exp:channel:entries limit="1" disable="categories|member_data|pagination"}
{exp:stash:set name='title'}{title}{/exp:stash:set}
{exp:stash:set name='maincontent'}
<section>
<h1>{title}</h1>
<article>{content}</article>
</section
{/exp:stash:set}
{/exp:channel:entries}
The embed calls the .site layout and the interior simply pulls your specific channel:entries data.
As you can see, it's still using the traditional templategroup/template ways of building URLs, it's just pulling data differently.
When using Stash and the template partials approach (which I don't use personally), the files you mention are all embedded. You still use the same template groups and template files as before.
The Stash-based approach is simply a different way of doing things within your existing templates - not a replacement for them.
Exactly as Derek says. The way to think about it is this - with the template partials approach, your templates contain mostly (if not only) the entries logic (channel entries loop, its parameters, what custom fields are in play for that channel, etc). The outcome of the logic gets stores as stash variables. The stash variables then get called upon by your embedded layout templates to display the content you've stashed. So your URL structure remains the same, but you have considerably less duplication of effort since the more you constrain your templates to logic (i.e. very little if any formatting/display markup) the cleaner they are and the easier it then is to manage your templates.