TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Show HN: Templating engine to make life simpler

1 pointsby ryan21030about 10 years ago

1 comment

xrstfabout 10 years ago
A few things I noticed while reading through the readme:<p>* For me to consider using a PHP library in 2015, it <i>must</i> support Composer.<p>* Currently, a lot of the API is static. This makes it hard to inject the template engine as a helper into some other code. Personally, I would prefer a non-static API.<p>* The template and cache paths seem to be fixed to the location of the library. If this becomes a Composer package, they must be configurable.<p>* From looking at the syntax, how does your library compare to Twig? Sure, the setup process for Twig (initializing the environment, template loader, cache and stuff) is a bit more work, but after that, it&#x27;s as easy as ``$twig-&gt;render(&#x27;mytemplate.twig&#x27;, [...data...])``. (Plus, Twig has some nice syntactic sugar, like an else-clause for loops.)<p>* Is there automatic HTML encoding? This is one of the most compelling reasons for me to use a template engine. Whether or not stuff is automatically encoded, this should be mentioned prominently in the readme so that users don&#x27;t create insecure templates.<p>* On a really completely personal note: I don&#x27;t like ``.tpl`` as a file extension. It&#x27;s too generic. It&#x27;s like naming my PHP class files ``.class`` -- IMO the extension should indicate the file syntax&#x2F;type, not the file&#x27;s purpose. Plus if I look at your roadmap, using .tpl might be a problem when you support JavaScript as well.<p>[Edit] I just noticed how negative this all reads. Please take it as constructive cristicism rather than me bashing your work. :)
评论 #9346399 未加载
评论 #9351855 未加载