search

yosssi / ace

HTML template engine for Go
MIT License
835 stars 89 forks source link

The API is complicated. #43

Closed omeid closed 6 years ago

omeid commented 9 years ago

First of all, thanks a lot for this package, as someone who really likes Jade I totally appreciate this project.

But the current API is over complicated. A similar api to the original http/template would be great, or at least something with the similar level of abstraction.

If I want to compile a template, I just want.

ace.Compile([]byte, map[string][]byte) *html.Template

And I would be happy.

And when working with Go templates, something like this would be ideal.

ace.Template(*template.Template, string. []byte)

And I would be happy if you parsed/compiled my []byte and stick it in the template.Temlate under the name supplied by string.

Of course, the map[string][]bytes holds the includes.

yosssi commented 9 years ago

I'm so sorry for the late reply. I'll think about it later. Thanks!

omeid commented 9 years ago

Not a problem. I managed to get it working but it is far more cumbersome, than for example how gcss is handled.

omeid commented 9 years ago

Any updates on this?

monomadic commented 7 years ago

I completely agree - file streams or a byte buffer is all that's needed - why does the library need to know about file locations as strings? Carry around the least amount of baggage you need, not the most! :) There could be available convenience wrappers over the top of the library to allow for string based instantiation but they seem to go right down to the core. Imo an API clean up would require a complete rewrite as it seems to be threaded all throughout the library.

@yosssi your gcss library as infinitely cleaner, as it just takes an io.Reader and io.Writer object, basically what @omeid suggested, I'm wondering why the change in style for ace? Perhaps it's an older project?