In some projects I have to work with Perl and Template Toolkit and in others with PHP and Smarty templates. Can you somehow configure both to have a common subset of each language, so you can use the same templates in smarty and in template toolkit? Sure there are language properties which cannot be mapped to the other, but if there is a common intersection, you could limit yourself to this part. A useful addon would be a validator that checks for absence of language-specific template features.
P.S: A pointer to some template language that is supported in both Perl and PHP, like Template Attribute Language, but with syntax similar to Smarty and Template Toolkit, would also be helpful.
I now found XSlate, a template engine for Perl that can handle multiple syntaxes. With Text::Clevery you can use a large subset of Smarty syntax, so templates can be shared between Perl and PHP. So a better move from Template Toolkit to XSlate.
Related
I'm learning Go but I can't find this answer anywhere. Is there any official standard for file extensions in web development? I've seen multiple conventions like .tmpl and .gtpl, which is what? Thanks.
There's no fixed standard, but there are some fairly common practices. For templates on web projects, I use the extension appropriate for the type of file it is, e.g. .html, .css, etc. That's what's done in the widely-read-and-cited Writing Web Applications blog post on the official Go blog, which makes it fairly standard. I find it useful for easy syntax highlighting without changing my editor's settings/config, and processing by other tools. I put these templates in a /templates/ directory to keep them separate from non-template files.
I've seen and used .tmpl before, it's in official docs for both html and text template packages, which makes that fairly standard too, and I think it makes sense if you're making a file-type-agnostic template, or you don't have any associations that are useful by more specialized file type.
For Go code files, I always use the .go extension, which works well with the Go toolset. It's what you generally see in official Go documentation, such as this introductory document on How to Write Go Code. For executables, I don't append any file extension. The default result when you go build <name>.gois an executable called <name>, and so that makes it a common practice.
Everything works fine except template files. If there are some HTML in the code breakpoints just don't add.
How do I debug PHP code in template files?
I have PHPStorm 9.0 and Xdebug 2.2.3
Somewhere along the line of code execution, a template engine is called from your controller or framework. That would be where you would set a breakpoint; then use step into... to see how your template file is being handled by the template engine itself. This is a tedious process, but depending on the framework you're using, may be your only alternative.
Having said that, I would actually recommend separating concerns by executing all PHP code in your controllers or source files; and then passing those values on to the template as simple variables or code snippets for rendering. This follows a similar convention to "dependency injection" and will make your template files easier to compose and troubleshoot.
When working with Nunjucks templates which requite rendering or compilation is there a standard naming convention to be used to have them processed? i.e. file.nunjucks, file.nunjucks.html, or file.njs etc.
I know that when working with other template languages it's common to use their name as the extension such as file.liquid, file.ejs, etc, but I've not seen much in reference to Nunjucks.
I personally prefer the extension '.njk', its also something that they have as an example on the Nunjucks docs.
File Extensions
Although you are free to use any file extension you wish for your Nunjucks template files, the Nunjucks community has adopted .njk.
If you are developing tools or editor syntax helpers for Nunjucks, please include recognition of the .njk extension.
Jon Buckley's nunjucks plugin for
wintersmith supports template naming convention
*.html
*.nunjucks
See https://github.com/jbuck/wintersmith-nunjucks/issues/8 for proof
So this naming convention is common everywhere wintersmith site generator is used. Especially the *.html seems to be fairly common also elsewhere.
Nunjucks's own documentation uses the *.html in examples of using {% include ..%} and {% extends ..%} tags and it says
...overview of the templating features available in nunjucks. Nunjucks is essentially a port of jinja2, so you can read their docs if you find anything lacking here...
and jinja's own documentation in turn says
...A template is simply a text file. It can generate any text-based format (HTML, XML, CSV, LaTeX, etc.). It doesn’t have a specific extension, .html or .xml are just fine...
My in-house site generator applies the nunjucks preprocessor also to files with extensions: *.md, *.markdown, *.htm, *.html, *.php, *.css, *.js, .htaccess but it can not be considered "common convention".
It might be possible to find out nunjuck's usage statistics and examples of used naming conventions using Google or GitHub or Wolfram Alpha computational knowledge engine or IBM Watson Analytics service...
I think that you can use any naming convention as long as you are able to refactor (rename) it anytime later
I have used T4 to generate partial classes from some input file (XML, etc) and then hand code additional partial bits onto those generated classes.
Is it possible to go the other way? To hand craft partial classes, and use T4 to template boiler plate bits to them?
Obviously I can't use reflection to look for the classes since it's not compiled yet, but I see Visual Studio inspect uncompiled code for different utilities. Perhaps Visual Studio offers some feature to support this I don't know about. Long shot, I guess.
Thanks
Also, you can use T4 with VS's CodeModel to read the code in your project without compiling and then generate from that metadata.
There's some pointers to examples here: http://blogs.msdn.com/b/garethj/archive/2009/09/25/dte-and-t4-better-together.aspx
Actually, T4 is used this way frequently. Yes, it requires reflection, but partial classes compile even if bits of them aren't generated yet. I would look at examples for generating strongly typed views as described here for examples of using reflection to generate new files.
Last year I wrote a Language Service for Visual Studio which added syntax highlighting for NHaml files: http://github.com/snappycode/hamleditor.
To clarify, NHaml is a html template language that can mix in code elements like an aspx file can. This plugin adds support to the IDE for editing NHaml files, but basically only adds syntax highlighting.
I was wondering if anyone knows how to add inline c# intellisense to the service like you get now in an aspx file. I'm hoping that would be possible without doing the whole c# grammar myself specific for the plugin.
Has anyone written a language service that mixes languages?
UPDATE:
It looks like the spark view engine guys have made some inroads here, I am investigating their implementation
I checked the Spark View Engine, and they seem to have made a generic ATL stuff (called SparkLanguagePackageLib), that in fact seems to be not containiag anything Spark specific. It seems to be just a generic C# intellisense library that needs the following:
The original code
The C# source that gets generated from the original code
The position mappings between the two (for example the code on line 2 pos 5 gets mapped in the output to line 4 pos 10, etc.)
Some other things, like Paintings(?)
And after that you can call:
events.OnGenerated(
primaryText, // original source code
entry.SourceCode, // generated sourcecode
cMappings, // mappings between the two
ref mappings[0], // ?
cPaints, // ?
ref paints[0]); // ?
I've tried to find Spark-specific stuff in that C++ library, but I couldn't find anything: everythig spark-related is split to a separate C# code file. I think this is good, because:
You don't need to edit the C++ files
If the spark view engine's intellisense support is installed it can be used by other view engines too
You only need to create a class, that maps between the original nhaml file and it's generated C# counterpart.
Btw. Are you still working on this NHaml Intellisense library? If not I'll try to patch their implementation in hope it can be converted to NHaml easily.
this looks like it might help
http://www.codeproject.com/KB/recipes/VSLanguageService.aspx
I finally managed to modify the code to support NHaml. It wasn't that hard at all. Unfortunately the original NHaml library doesn't support everything that was needed, so I had to create a new parser for NHaml. It doesn't support all of the constructs, but it supports most of them (enough to make NHaml programming easier)
Download: http://github.com/sztupy/nhamlsense
Screencast: http://www.youtube.com/watch?v=8jTZ2zC9eYc
You can easily add keywords by creating or modifying a usertype.dat file. Check here for some directions on attaching to specific file extentions. That might get you at least part of the way, without redoing the complete c# syntax.
(In fact, I'm not sure what you mean exactly by 'syntax highlighting' in this context. I'm sure, for instance, you get brace-match highlighting for free in the editor).