I have a set of templates as files, like base.html, login.html, profile.html, header.html and so on. They are structured in folders.
It's fine to have them as separate files during development but when I deploy the app, I'd like to have them all embedded as strings or parsed and compiled templates ready to use from the code as usual.
How should I better make these templates as Go code? So that I don't have to have a templates folder in production, but everything in the single executable file?
With Go 1.16 there would be official "embed" package and the following would be possible (is possible if you read this after February 2021):
//go:embed "mytemplate.tmpl"
var myTemplate string
This code embeds mytemplate.html at compile time and it becomes available as a string (or as []byte or as a FileSystem, if you wish). No 3rd-party tools or libraries needed.
The most simple solution is to embed templates in string literal inside Go source code.
There is a tool that can help, see go-bindata.
I used go generate in some of previous projects for this type of operation, see blog post on go generate command for introduction.
As of the Go 1.16 release, there is the //go:embed comment directive.
This allows you to directly embed files in your binary.
Link for draft design of the go:embed comment directive
Link for the Github issue for go embed with some updates
In addition to go-bindata which was already mentioned, there is go-bindata-assetfs which you can use to serve static files from a webserver. It's good for Javascript, CSS, etc.
Related
Apologies for somewhat of a basic question, but I haven't been able to find the technical reason anywhere I've looked.
Basically, if I do npm run build I get a static html file and a bunch of css and javascript files in the build folder. I would think that I should then be able to open up that index.html file in the browser and have it work, just as would be the case for some static HTML built without React.
So, my question is: what is it that react is relying on that requires to be served up with a static file server like serve or webpack dev server?
It uses Ajax internally. The Same Origin Policy prevents it reading file: scheme URLs in most browsers.
I have a ZF2 project where I generate, minify, etc... my assets via gulp. For example I generate a styles.css file which gets included with the ZF2 headlink view helper:
echo $this->headLink()->appendStylesheet($this->baasePath('assets/css/styles.css));
Now I have the problem, that the file gets cached by the browser and does't notify any changes. Does anyone know a way to handle that? Maybe add a version number to the generated css file, but then I really don't want to edit all the ZF2 templates which inlcude that file.
Thanks for any reply.
There's a load of ways to do this, but one option is to use Assetic - a well known asset manager package. Tere's a few ZF2 modeules to help integrate this library into the framework too. A quick google search throws up some:
https://github.com/magnetronnie/zf2-assetic-module
https://github.com/kriswallsmith/assetic/
This module will help manage assets such as CSS/JS, and also has some "cache busting" features where by you can change the url based upon the file modification date to ensure if changes when ever the file is re-downloaded by the browser.
Recently started using Grunt as a build tool for a web app I'm hobbyist developing. I have a series of HTML files (to be used as templates), in a single folder, that I'd like injected at a particular point in the main HTML file.
Ideally, I could also wrap each file in a tag, but having to manually include this in the template files themselves is acceptable.
Is there an existing Grunt module to perform this?
EDIT: I may have worded my problem poorly before. Essentially, I have a single HTML file where the app will run (Single page app, business simulation game). In a separate folder, I have a series of HTML templates. Each of these template represents a dialog, or custom info page, something of that nature. As the app is developed, more and more templates will be in this folder.
Rather than manually including each one in my page, I'd like a way to automate injecting them that I can manage through Grunt.
I may be late to answer this question, but for anyone that end up here, I found this grunt-plugins, maybe they help you too:
grunt-replace.
grunt-html-build.
grunt-processhtml.
I have been reading tutorials and guides concerning this but have not found a straight forward answer to this.
I currently have an existing website running on a node.js platform, locally on my computer.
Goal: Now I want to try and write a simple hello world in Dart, export it to plain JavaScript and see it work in my existing website.
Reading the documents, I read that I should create a new "Web Application" and to create some sample code up and running, I check the "Generate sample content" box.
And my project is now created in Dart Editor:
I can run the sample in Dartium, see it work, etc.
But the problem is that I have now a .html file in the Dart-project, while I have a real .html file for my existing node website in a totally different path. I don't want that. I want to try and use the existing .html instead, since.. thats my real website.
But when trying to create a new Dartium launcher, I can only refer to .html files within my Dart-project:
So my big question is; How do actually start using Dart with my existing developed website?
How do I create that bridge?
On the second image above in your original question, there is an option just below the HTML file, called URL - is this what you're looking for? You can set that to any arbitrary URL.
You'd also need to copy the helloworld.dart file into your node.js server path, and copy the bits inside the <body> tag into your existing HTML page. You'll also need to copy the packages\browser\dart.js file somewhere to your node.js server, too.
If you wanted to run the JS version, you'd also need to use the editor menu option to Generate JavaScript and copy the .js files into your node.js server path.
The script tag that refers to dart.js automatically detects if the browser supports Dart natively, and will either load the .dart version of your app, or the .dart.js version of your app (from the same folder location).
So what you're likely after is something like:
c:/nodejs_server_root
/existingIndex.html // containing the two script tags from helloworld.html
// and other tags referred to in helloworld.dart
/helloworld.dart
/dart.js
/helloworld.dart.js
And in the "URL" path in the launch configuration, you'd put something like http://localhost:<port>/existingIndex.html
https://pub.dartlang.org/packages/dev_compiler can compile Dart to Node.js modules with the --modules=node option.
See also https://github.com/dart-lang/dev_compiler/issues/291#issuecomment-176687849
I have a basic web application packaged as an EAR deployed on GlassFish.
The web module has some html files.
The html files have a common footer, an html file, that I would like to extract out and make an include.
When I do, and put:
<!--#include virtual="insertthisfile.html" -->
in an html file, it does not work.
Should this work?
This is a technique called Server-Side Includes (SSI). It may not be enabled on your web host. If it is, sometimes they force a .shtml extension to be required for included files, so try renaming your file insertthisfile.shtml.
If that doesn't work, you might be able to enable SSIs in a .htaccess file (assuming your web server is Apache). You can find instructions on how to do this by googling. There's a decent set here.
If that fails, I would contact your web host and see if they have SSIs enabled.
Should this work?
Perhaps, at some special settings, with some experienced programmer, this could be useful.
In my case the include statement seems to be ignored.
I could include some text with
(embed src="include.shtml")
(/embed)
Above, I type () instead of angular brackets.
With the "embed", the setting in the header of the page does not apply to the included text; it should be repeated again, and, by default, the result is ugly.
It looks strange, as if the designers of the html did not build-in the very basic tool, the include command. For short articles, the include could save an order of magnitude in the size of files.