Comments (15)
It works provided you escape everything properly. For example:
import groovy.text.*
def text = """
task migrate(dependsOn: 'shadow', group: 'dropwizard', description: "Run migrations using the dev configuration") << {
javaexec {
main = '-jar'
args = ["\\\${shadow.shadowJar.getPath()}", 'db', 'migrate', 'dev_config.yml']
}
}
"""
def template = new SimpleTemplateEngine().createTemplate(text).make()
assert template.toString().contains('["${shadow')
Given that I am dealing with text I need two more \
than I would need in a file. So the question is, is this too annoying to expect from template authors? Should we use something that is not groovy to encourage people outside of the jvm community to use this?
from lazybones.
I personally don't care about the extra escaping (@kyleboon please tell me if I am missing something here).... I do care about the second point though.
from lazybones.
I'm tempted to offer multiple template options here. I can imagine Handlebars templates being equally annoying for Handlebars template files. SimpleTemplateEngine
is also more familiar to people in the Groovy community than Handlebars.
There is a cost associated with increased flexibility, but I don't see the codebase becoming overly complicated by supporting multiple template engines. That said, I don't think Lazybones should have too many dependencies. The core should only include a maximum of 3 engines, preferably only 2. Thoughts?
from lazybones.
I haven't created enough templates to say this is worth it. That said I will likely use 100% groovy for all templates despite any shortcomings.... going to stick with what I know. Some solid documentation regarding escaped characters / gotchas might be worth some time though. Personally I think we should pursue a 100% groovy solution until we get enough complaints to do otherwise.
If we want this to be used outside of java / groovy land, supporting another template engine might be worthwhile. I suspect that might be a pipe dream though 😄
from lazybones.
One compromise I just thought of... make the root script and template engines extensible. Although the lazybones product will only support groovy out of the box, a template could contain jars / groovy files which are added to the classpath before the root script is fired off. After the template is successfully installed, these plugin files are deleted. Can't tell if this reeks of over engineering, but maybe something to keep in mind.
from lazybones.
I mentioned adding ivy
in #36 to enable Grape
. Maybe this could be the first step to support lazybones plugins / different template engines.
from lazybones.
I like the idea of multiple template engines
from lazybones.
I am still unsure this is worth the effort, but if it did happen handlebars seems reasonable to me.
from lazybones.
It looks like the Java Handlerbars implementation will add around 1.5MB to the distribution (mostly because of the dependency on Rhino). That makes it less than appealing as a core feature for me unless there is a great clamour for adding it.
That said, we could provide an SPI for template engines and let template authors include custom ones via Groovy's Grapes mechanism as @tbarker9 points out. The only difficulty is knowing what the SPI should look like with only one current implementation 😄
Is anyone interested in looking at an alternative template engine? That would help in determining what the SPI should look like.
from lazybones.
freemarker is a little less than a meg. No dependencies. Velocity is smaller but has a lot of dependencies. We could also make one of our own for demonstration purposes I suppose. For instance, I think some grails projects will replace anything between @
, while not allowing programmatic configurations.... just find and replace.
from lazybones.
StringTemplate might also be an option, about a third of a meg with dependencies. It does have a dependency on antlr-runtime though. Not sure if that will cause some kind of conflict with the antlr libraries that groovy depends on.
from lazybones.
Groovy has a Template Interface and an Abstract TemplateEngine class. Would we need anything else?
http://groovy.codehaus.org/api/groovy/text/Template.html
We could just load the template engine class based on a registration of file extensions to concrete TemplateEngine.
SimpleTemplateEngine, GStringTemplateEngine and XmlTemplateEngine are in the core groovy distribution so we wouldn't need to have any more dependencies. Then we could add a registerTemplateEngine(String extension, Class templateEngine) method in the Script base to register additional template engines.
from lazybones.
Oh nice.... I didn't even think of that.
So how exactly would this work? By default the SimpleTemplateEngine would handle all extensions and anything registered can override that. Or no matter what someone has to register a template engine? Do you think we should do something to auto discover the templates instead of explicitly adding it?
Right now we are filtering files in place, will that still continue? Or would we use file extensions specific to the template engine? So a file that is processed by the SimpleTemplateEngine might have the extension gtmpl. So assuming we have the build file build.gradle.gtmpl
, it will be processed and deleted, with the final processed file being build.gradle
.
from lazybones.
I would stick to passing an engine instance into the filterFiles()
method. We can leave file extension registration to later if it appears to be a valuable feature. Same goes for auto-discovery. I think it's better for template authors to explicitly declare what files they want filtering.
I think it's nice to support dedicated file extensions for template files. They make it clear what's a template and what's not in the source. The only question I have in my mind is whether it makes sense to support both that approach and in-place filtering. I'd prefer to only support one of them to ensure consistency, but I don't have a strong opinion either way. Thoughts?
from lazybones.
Moving the discussion to the more focused issue #52.
from lazybones.
Related Issues (20)
- "No such property" error HOT 6
- Proxy user authentication not working properly HOT 4
- Create package on bintray with publishAllTemplates: VCS URL mandatory HOT 3
- lazybones-gradle incompatible with gradle 2.14-rc3 HOT 5
- lazybones list: RuntimeException - InvalidAlgorithmParameterException HOT 2
- Add a shorter name too? HOT 2
- Option to clear redirect zip for mappings
- Combining templates/features?
- Interactive command line
- Using lazybones config add bintrayRepositories <repo> after initial installation throws java.io.FileNotFoundException
- Add more default templates
- Best way to inject a variable when packaging template?
- FileNotFoundException with config set on fresh install
- Is project still maintained HOT 1
- Code check failing on clone HOT 1
- Setting cache.dir throws exception
- Possible to ignore certain variables?
- lazybones stopped working with Ratpack HOT 2
- Still supported? HOT 2
- Binaries no longer supplied by Bintray HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lazybones.