Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have users import their template library instead of providing it #14

Closed
fwgreen opened this issue Sep 12, 2016 · 3 comments
Closed

Have users import their template library instead of providing it #14

fwgreen opened this issue Sep 12, 2016 · 3 comments
Assignees
Labels
Milestone

Comments

@fwgreen
Copy link

fwgreen commented Sep 12, 2016

Providing an implementation of TemplateRenderer is helpful, but importing the template library might harm flexibility. Mustache, for example, is at version 0.9.3 for Java 8 and 0.8.18 for Java 7. A user might want the option to choose depending on requirements.

@fwgreen fwgreen changed the title Have users import the their template engine instead of providing it Have users import the their template library instead of providing it Sep 12, 2016
@fwgreen fwgreen changed the title Have users import the their template library instead of providing it Have users import their template library instead of providing it Sep 12, 2016
@bjansen
Copy link
Owner

bjansen commented Sep 16, 2016

So what you're saying is that I should only provide the view.api module, maybe give a few examples of implementations but not actually put them in modules and release them on Herd?

It could also be possible to override the imported module via an overrides.xml, or any new syntax that might come in the future.

@fwgreen
Copy link
Author

fwgreen commented Sep 16, 2016

It's great that you provide an implementation of the renderer: Some users might not think to wrap the Ceylon collections as Java collections and get into trouble. It's the import of the actually template library jar that, I believe, should be left to the user.

@bjansen
Copy link
Owner

bjansen commented Jan 5, 2017

Here are a few thoughts:

  • net.gyokuro.view.* modules are convenient, and allow users to use a templating engine that Just Works™
  • they are optional dependencies, so they don't clutter up net.gyokuro.core
  • it's pretty easy to add an overrides file to use a different version of the engine than the one automatically pulled by these modules
  • it's also easy to not import any of those modules and instead define a custom (Java)TemplateRenderer or modify one of those provided by gyokuro

As a result, I think I'll keep existing modules as is, and make them import the latest version of each engine. That should cover most of the use-cases, while leaving users with reasonable alternatives.

@bjansen bjansen closed this as completed Jan 5, 2017
@bjansen bjansen added this to the 0.3.0 milestone Jan 5, 2017
@bjansen bjansen self-assigned this Jan 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants