Specifically, I have an XSLT macro that modifies some content. I have this in my Template above a call to a .net Macro.
My .net macro uses the Page_Load event and it can't see what changes in the XSLT macro. (If I refresh, then the XSLT work has been completed and the .net macro sees what I expect it to. But the first run through always fails.)
I think that this is related to timing of the page life cycle and the XSLT macro isn't performing it's work until after the Page_Load event of my .net macro.
With further testing, I can confirm that umbraco runs the XSLT macros after all .net macro Page_Load events - regardless of their order in a template.
So don't do something in XSLT and then expect it to be done in .net "later" in the template. It won't be there.
I'd love to provide a reference form the Umbraco source, but don't have it at the moment.
Related
We are creating a microservice bootstrap project with a code-generator using a Backstage application directory - allowing users to create a starter microservice project using the backstage app wizard.
This means we have some java application code that was then templatized using nunjucks.
However, if other developers want to modify or evolve that template code, they would have to render the template to java code (a spring boot app) then develop on it: modify, test, debug. And then when they are done, they would have to re-templatize the code before committing the template code back to backstage.
My question is how can we automate or simplify that re-templatizing step back to nunjucks. Maybe we can preserve some of the templating info in comments so that we can automatically re-apply templating to those areas? Is there another simpler way to automate or assist turning the code back into a template?
Since multiple developers will be working on this over a long period of time, I think it would be unrealistic to expect users to update back template expressions everywhere if they become interspersed throughout the code.
We currently use T4 templates to generate C# code files based on C# Code (Entity POCO's) and the EDMX (in older applications)
Moving to ASP.NET 5 with a view to support cross platform development, are there any code generation tools available that can read a projects class & meta data structures, and to generate C# files at design time, similar to T4 templates?
You can try Scripty - it is Roslyn based scripting.
Syntax highlighting for *.csx files works out of the box;
VS extension exists to process scripts on save;
MSBuild task exists to process scripts during buld process;
Script allows you to traverse a hierarchical model of the project;
Multiple files generation from single script is supported;
yeoman seems to be a good option. There exist some generators already for scaffolding asp.net 5 apps and you can create your own generators
It is cross platform and can be used on linux/mac/windows.
Even tt templates weren't supported earlier in asp.net-5 projects. It has been added recently (in Visual Studio 2015 Update 1).
The discussion is here: https://github.com/aspnet/Home/issues/272
And in the thread, Eilon said the Roslyn is the way to analyse the code and generate new ones... And he again said the ASP team has no immediate plan. So currently we have no solution from Microsoft.
But I did some search and didn't find any cross platform community tool to generate codes based on other codes. :(
Scriban worked for me as an alternative to replace T4 templates for generating unit test code. But it's a pure templating engine.
The new LeMP preprocessing engine for C# can be used as an alternative to T4 templates. May I ask what specifically you mean by "projects class & meta data structures"?
For this purpose I created a simple python
script called "autogen".
How it works: the script takes jinja template file (instead of T4) and data file (json) and generates one or multiple output files (e.g. C#, or any format) based on the template.
How it can be used (example): describe interface (methods, parameters) definition in json file, create *.j2 template files for C#, Java, Python, etc.. Then run autogen.py script and files for proxy/stub for all languages will be created.
This can help to create lot of similar code without copy/pasting and make code changes by simply changing single json file.
Moreover it can be integrated with build pipiline, msbuild (.net, .net core) and is cross-platform.
I have been looking into this same sort of thing, although not specifically with ASP.NET MVC but across project types as I move to .Net Core. I kept my T4 relying on EDMX early on. Which works out since EF7 moves beyond the file format in favor of code. Where I was planning on going with my code generation was a combination of ScriptCS and C# REPL. Roslyn complicates things for me a tad since there are no design time assemblies from what I understand. So the trick may be to understand and introspect cs files from within the project.
I am curious if doxygen itself can be used to automatically add doxygen comment stubs to my partially documented C++ project.
I use the DoxygenToolkit in vim, but :Dox above each function in a rather large project is rather taxing. I'd rather spend that energy actually writing documentation.
I am not asking about a plugin to an IDE for newly written code, such as:
Automatic generation of function stubs
but massive amounts of preexisting code.
No, Doxygen cannot modify your source. This is an editor feature.
If I am going to develop using Coffeescript I will need to know what browsers are supported by the coffeescript JS code - I'm sure there will be a webpage somewhere on the subject :)
CoffeeScript's motto is "It's Just JavaScript." That means that if you write CoffeeScript code that invokes a feature that only exists in newer browsers, the JavaScript output will depend on that feature. CoffeeScript's own syntactic features, such as class inheritance and array comprehensions, generate code that's compatible with all major browsers going back to IE6.
Update: I now realize you were specifically asking for browsers which support the Coffeescript compiler. I have no detailed information about that, but considering the wide usage of Coffeescript my answer would be most of them.
No browsers support Coffeescript directly, although there may be some magic javascript snippets available that could compile Coffeescript to Javascript on the fly when a browser loads the page.
The usual workflow however is to compile Coffeescript to Javascript, and then only feed the browsers the resulting Javascript files. "Compile" may not be the proper word either, as it is more or less translating one set of source code (Coffescript) to another set of source code (Javascript), which is then parsed and sometimes JIT-compiled to execute in the browser (Spidermonkey, V8 etc).
we all agree that when we use GWT, we compile our application on the server, several javascript file are created. Normally, when deploying, we would use the obfuscated mode.
Now modifying a javascript file in obfuscated mode is almost impossible. Now what happens if we want to make some modification in our GWT application.
Do we have to go back again in Java, modify the file, compile, and then deploy again??
I'd say yes... If you use a code generator you should avoid modifying the generated code by hand.
No, no, no.
You don't "go back" to the Java code to modify it. You simply debug, test and modify the Java code. You ignore the code in the compiled javascript files except to deploy it. As far as you are concerned, GWT source code is Java code, not javascript, written within the environmental restriction of the browser.
Your question is like asking, "I have a C application that gets compiled to object code. Do I modify the object code or go back to the C code to modify it?" !!!
You simply treat the generated javascript as "native code".
No doubt you can include javascript using jsni, and so can you include assembly code when using C. So except for those assembly code you inject and similarly except the javascript code you include, you leave the "native code" alone.
When you try to modify the object code generated from C, that is called hacking. Hacking is an interesting hobby but when you wish to create an application and your main task is not "hacking", hacking would only be your extra-curricular activity not connected to your main employment or project.
Go back to the beginning: http://code.google.com/webtoolkit/overview.html
...Write AJAX applications in Java and
then compile the source to highly
optimized JavaScript that runs across
all browsers
When you're ready to deploy, GWT
compiles your Java source code into
optimized, stand-alone JavaScript
files that automatically run on all
major browsers, as well as mobile
browsers for Android and the iPhone.
While debugging: if you are running in development mode you may not even have to redeploy while in dev.
Thanks to the GWT developer plugin,
there's no compiling of code to
JavaScript to view it in the browser.
You can use the same edit-refresh-view
cycle you're used to with JavaScript...