Question, i'm trying to precompile my .handlebars files to templates.js.
So far it's working for all files in source dir, but not for files in a subdirectory (where i keep the partials).
The command i'm using:
handlebars -m resources/views/handlebars/> resources/assets/js/handlebars/templates.js
How can i make this recursive, so that it iterates all directories?
The solution was very simple:
handlebars resources/views/handlebars/ -f public/js/templates.js
Note, this also precompiles all partials that reside in a subdir.
To make these accessible in templates, add this line in beginning of your code:
Handlebars.partials = Handlebars.templates;
Since partials are also templates, this seems like a harmless solution, albeit not the most memory friendly one. If anyone has a suggestion for this..?
Now i want to delve into precompiling custom helpers... documentation is not very clear about that. I'll properly concat these with elixir.
Related
I'm writing a single-page JavaScript application and I'm using Atom as my text-editor. (It's an Electron application, but that's besides the point.)
I'm also using the linter-jshint plugin for Atom. This is great, as it shows immediately in the text-editor when I make a typo in a variable, among other useful things.
Lately, my app has been getting very long. Naturally, I want to try and split it up across multiple files. After doing some research on StackOverflow, I've determined that I can use Grunt to automatically concatenate JavaScript files together. This is great because I don't have to refactor my code - I can just copy paste my existing functions into separate files. Easy!
However, once I do this, Atom fills up with warnings and errors from JSHint, because it can't find variables and functions that are located in the other files!
Now, I could just abandon the JHint plugin in Atom altogether and use the JSHint plugin for Grunt after the concatenation has already occured. But that sucks! I want the code that I'm going to be writing to be checked on the fly like a real IDE.
Is there a way to tell Atom/JSHint to assume that a bunch of JavaScript files will all be concatenated together? Or am I just approaching this problem completely wrong?
You can split your electron application with Node Common Modules, and use require('./state.js'); within your application.
Although I don't use Atom, that should allow for it to understand how you're using your variables and functions in other files.
Also this should eliminate your need for concatenation as the single-page app will have all it's dependencies accounted for.
I'd like to have something likes this:
app.import('path/to/file.js');
app.import('path/to/file.css');
And it would concate everything. Is there a way using Grunt?
This is documented in the sample gruntfile on the Grunt site.
http://gruntjs.com/sample-gruntfile
Use the standard grunt file specifications. How to specify files is here:
http://gruntjs.com/configuring-tasks#files
Note that you do not have to add files one at a time. That's why they allow wild cards. You specify entire directory trees if you want. And mostly this is what you want. Study the file glob patterns on the grunt site. There are lots of examples too.
Is there a way to tell the sbt-onejar SBT plugin to produce a JAR in such way that the .class files of my project are in "expanded" form and not under lib/myproject.jar?
Alternatively, is it possible to tell sbt-onejar to produce a JAR that, when it's loaded, it actually unpacks/expands the nested JARs into a temporary folder and loads them from there, so that things like getResource(...) return paths to physical files as opposed to jar:file:... URLs?
Alternativel, I'd also happy with any vanilla OneJar solutions that help me produce a fat JAR wherein my own .class files would be directly under the fat JAR as opposed to under lib/myproject.jar.
I'm asking because Jetty does not seem to be able to load JSP files from inside of nested JAR files. There does seem to be a workaround by using a custom resource loader (see http://dev.eclipse.org/mhonarc/lists/jetty-users/msg01174.html for a report of the same problem and the workaround) but I don't seem to be able to get my servlets to actually use the overridden getResource method provided in the workaround.
After having read sbt-onejar's source code:
packageOptions in oneJar ++=
Seq(sbt.Package.ManifestAttributes(
new java.util.jar.Attributes.Name("One-Jar-Expand") -> "some-file.txt"))
However, I've realized using OneJar with Jetty is quite a problematic beast due to how Jetty loads JSP files—doesn't seem to work with nested JARs—so I'm looking into alternatives now.
EDIT: I've found https://github.com/xerial/sbt-pack and it seems to achieve the same effect as OneJar with the difference of being standard and thus free of problems, much faster, more customizable, and allows defining of convenient custom program entry points.
For the sake of clarity, and because SublimeText isn't bright enough to know the difference between lots of different flavors of ".html", I thought about using .handlebars as the extension to my handlebars-templated files. Meteor seems to only accept files with with .html extension, and I'm wondering if there's a way I can get it to accept .handlebars files too. Thanks
This may be more complicated than you'd like, but one way you can accomplish this is by making your own version of the templating package.
make a copy of the subtree,
rename the package,
edit plugin/compile-templates.js and at the bottom in the call to registerSourceHandler, replace "html" with "handlebars".
put your new package into your project's packages and add it using meteor add yourpackagename.
The comment left by Hubert OG was the simplest solution. Use .handlebars.html files. The SublimeText plugin for handlebars now recognizes that file extension too.
i have this tree structure:
repository/modules/module1
repository/modules/module2
repository/modules/module..
repository/apps/application1
repository/apps/application2
repository/apps/application..
where the applications are using some modules.
now, I'd like to put some resources inside a module (like a very colorfull icons inside a widget used by several applications) but.. something gets wrong.
inside the module CMakeLists.txt if I use only:
set(${MODULE_NAME}_RCS
colors.qrc
)
...
qt4_add_resources (${MODULE_NAME}_RHEADERS ${${MODULE_NAME}_RCS})
no qrc_colors.cxx are created anywhere. so I've tried to add:
ADD_EXECUTABLE (${MODULE_NAME}
${${MODULE_NAME}_RHEADERS}
)
but.. I get this weird error:
CMake Error at repo/modules/ColorModule/CMakeLists.txt:51 (ADD_EXECUTABLE):
add_executable cannot create target "ColorModule" because another
target with the same name already exists. The existing target is a static
library created in source directory
"repo/modules/ColorModule". See documentation for
policy CMP0002 for more details.
(I've changed the path of the error of course)
so.. don't know what to think because i'm new both to cmake and qt..
what can i try?
EDIT:
if I add the ${MODULE_NAME}_RHEADERS and ${MODULE_NAME}_RCS in the add_library command the qrc_colors.cxx is created BUT it is in repository/modules/module1/built and not copied in the application built directory...
There is at least two errors in your code.
1) It is usually not necessary to use ${MODULE_NAME} everywhere like that, just "MODULE_NAME". You can see that the difference is the raw string vs. variable. It is usually recommended to avoid double variable value dereference if possible.
2) More importantly, you seem to be setting ${MODULE_NAME} in more than one executable place, which is "ColorModule" according to the error output. You should have individual executable names for different binaries.
Also, the resource file focus is a bit of red herring in here. There are several other issues with your project.
You can cmake files as CmakeLists.txt instead of CMakeLists.txt which inherently causes issues on case sensitive systes as my Linux box.
You use Findfoo.cmake, and find_package(foo) for that matter, rather than the usual FindFoo.cmake convention alongside find_package(Foo).
Your FindFoo.cmake is quite odd, and you should probably be rewritten.
Most importantly, you should use config files rather than find modules.
Documentation and examples can be found at these places:
http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages
https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/master/show/buildsystem
When you would like use a find module, you need to have that at hand already. That will tell you what to look for, where things are, or if they are not anywhere where necessary. It is not something that you should write. You should just reuse existing ones for those projects that are not using cmake, and hence the find modules are added separately.
It is a bit like putting the treasure map just next to the treasure. Do you understand the irony? :) Once you find the map, you would automatically have the treasure as well. i.e. you would not look for it anymore.