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

Allow Completely Custom Delimiters #55

Closed
joshdickson opened this issue Jan 30, 2015 · 6 comments
Closed

Allow Completely Custom Delimiters #55

joshdickson opened this issue Jan 30, 2015 · 6 comments

Comments

@joshdickson
Copy link

When we upgraded to latest EJS, we lost the ability to do tempting the way we'd set up previously with:

ejs.open = '{{';
ejs.close = '}}';

Is this planning on being supported eventually? Would you consider a PR for this or is there a technical reason that delimiters now work only inside < and > tags?

@TimothyGu
Copy link
Collaborator

It's by design by @mde. No idea though on why he changed it.

@joshdickson
Copy link
Author

Yeah I'd love an explanation @mde. It's confusing if you're using multiple tempting systems server-side. Nicer to just have completely alternate syntax. At quick look I don't see a technical reason why this was removed?

@mde
Copy link
Owner

mde commented Jan 30, 2015

The implementation of delimiters in the old version was one of the two non-standard features (along with filters) that I opted not to port over. There are multiple other (older) implementations of EJS which all implement delimiter customization the same way. AFAIK all the other similar templating engines (ERB, PHP, ASP et al) implement it the way we do now.

The old API for this also required a much more special-case implementation, because it wasn't simple replacement of single character across the entire range of available tags -- note that there are multiple open tags as well as closing tags. IIRC the old implementation didn't handle these. The only benefit I can think of of the old API was making EJS look like Mustache templates, which doesn't seem like a huge practical value given the amount of work that would be required to port and maintain the feature.

Hope that answers your question.

@joshdickson
Copy link
Author

For the case where you're using multiple templating engines, I consider it pretty important. I don't want an EJS template to appear, at first glance, to look anything like another template that we're using, and the ability to do this is why EJS ended up in our code base in the first place. As EJS is going to be server side and it's likely you're using something else client side (Mustache, Underscore, etc) that also might be periodically called on server-side, I think it should have remained as a feature as it had always been in the library.

That said I understand this is a specialized use case. It sounds like you don't want to entertain adding this back, which is disappointing.

@mde
Copy link
Owner

mde commented Feb 6, 2015

Sorry for the inconvenience here. I understand why you might want it, but it would add a significant amount of complexity for a very minor use-case. As far as it "always being in the library," The v1 of the NPM lib for EJS is only one of at least four implementations of EJS that I know of going back to the early 2000s, and none of them ever had anything like this AFAIK. The v1 code also had a non-standard "filters" feature that didn't make the cut. One of my goals with EJS was to bring it more in line with all the other implementations (and other similar templating languages like ERB, PHP, et al), and remove non-standard features, and unfortunately this is one of the casualties. I'm going to go ahead and close this issue.

@timschoch
Copy link

If you want to create asp pages within a yeoman generator this would be very helpfull too. Currently I have to pass two variables aspOpen and aspClose and echo them out <%= aspOpen %>do something<%= aspClose %> - not soooo nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants