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.
Related
Imagine you want to produce a specific static asset for your Next.js web app. An image collage for example, or perhaps a web manifest or site map.
My current strategy for this kind of scenario is to make a script that can produce the desired output directly in my /public folder, but then I have to push the built file along with my source files in my repo, which is less than ideal.
Or, I have to set up a separate parallel asset pipeline to re-create the asset when the source files change and which I would launch whenever I launch next dev. I would also need to run the script when next build is called.
In either case, I then also need to ignore the built file so it's not pushed along with the other files in /public…
This kind of solution feels like I'm reinventing the wheel and losing the zero-config ideal around which the Next.js ecosystem revolves.
I'd much rather provide Next.js with my custom script and just hook into the existing asset pipeline, dev server lifecycle, and build script, letting Next.js do the heavy lifting for me, hence my question:
Does Next.js have a plugin architecture, extensions, or perhaps lifecycle hooks I could tap into to implement a custom asset pipeline?
I see some pluggable loaders exist for Next.js, such as the MDX loader, but it's not clear to me whether this is the way to go for what I'm trying to do, and I'm not finding any documentation about how to write my own loader, so I'm afraid this might not be a recommended approach…
Does anyone know how you version / source control changes in Reddot Cms (OpenText). Also is there any best practice advice for release management of changes from one Reddot environment to another Reddot instance. Any help or advice would be greatly appreciated.
There is best-practice, but as you have probably realised, there aren't too many practitioners of RedDot these days. In case you should come back to this thread (or for someone else's benefit) Versioning is built into the Template Manager, but has to be enabled. There's no Source Control integration last time I checked, but we developed a prototype system that allows for the creation of templates in Visual Studio. The project to complete that has since died due to lack of commercial support, but some of the ideas may be useful for you if you want it.
I split up the answer in two parts: Versioning and migration between stages.
Versioning can only be done with the template history or via an external service that grabs the templates on a regular basis or triggered manually. At least for the Management Server there is no built-in service for a "real" versioning or release of more than just single templates/content classes or even including pages.
There are 3 ways of moving changes from dev to test or prod I have seen often:
Two templates: Using two templates on one server, on called "Development" and the other one "Production". All new development is done on the "Development" template and moved to the other template as soon as finished. If elements are different between those templates they need to be duplicated. This is typically on small installations without staging areas. Nowadays, you will find only very few of those.
Partial tree export: Development is done on a dev server and the changes are exported as partial tree. There is a special area in the project tree where pages are created which templates shall be moved over. These are exported including the templates and imported on the target server to override the existing ones.
Tool support: There are external tools for moving templates and content classes to other servers. There is e.g. SitePort (http://siteport.net , can also move whole templates between RedDot servers afaik) and the Sync Tool (http://www.erminas.de/en/products#synctool , can compare and move single element attributes and/or single lines of templates, please note: this shall not be advertisement as the tool is made by us but I do not know any other like this). Some companies also have custom development tools for this.
I'm currently using Spring Tool Suite (STS) (Version: 3.6.3.CI-B2266066, Build Id: 201411050946, Platform: Eclipse Luna SR1 (4.4.1)) with Spring Integration 4.1.0.
I have a Spring configuration XML file that includes the Spring Integration namespace. I go into the integration-graph tab and go into "manual layout" mode to spruce-up my flow. If I then turn "Enable Automatic Layout" back on the graph reverts back to how it looked before I made my manual edits. If I then go back into "manual layout" mode my edits are still saved. That works as expected.
It appears that the automatic-layout is somewhat tied to the order that elements are defined within the Spring context XML file itself. Meaning that if I change the order of elements within the XML file the layout on the graph will also change. It might be a nice feature to allow someone to perform some manual layouts then have the editor do a best-effort to save those edits to the underlying XML file. We have some decent sized XML files and often use the automatic-layout mode. It's cumbersome to then have to manually move things around in the XML file to make the layout show properly in the graph. I know not all edits would be able to be saved in the XML file (i.e. exact positioning and edits would be lost) but some of the edits probably could be saved (i.e. this channel needs to be defined above this channel in the XML file since it's showing in the manually-edited graph above that channel.
Perhaps there's a way to do that already that I'm missing?
No, there is no way to edit this graph manually... If this is allowed then the layout data needs to be persisted somehow. There is a possibility of adding more layouts to chose from from the GEF Zest project. This could be an alternative for what you are asking. Please submit a JIRA request for enhacement against Spring Tool Suite project :-) (https://issuetracker.springsource.com/browse/)
Just stumbled upon this question today:
"Is there a way to know that MPP published to the project server is not created using a template available on the server?"
Basically this comes from the point that how to find out compliance of the project plans to the standard templates.
I am not aware how it can be done?
Actually there is no way to identify by one field that this project was created using that template.
You may assume that by Enterprise Project Type, but again there is a way to change EPT for existing project.
The only way I know is to compare a template and a project by tasks, by structure, etc. it works like finger print recognition: you select several points which the most probably tell that the project was created from the template.
The worst case I can imagine: a user creates a project by a template and after that removes everything from the project. Formally the project was created by the template but in real there is nothing from the template left in the project.
I'm working on PHP web applications (mainly built on top of CodeIgniter). What is an easy way to deploy such sites? Right now, deployment generally consist of:
Shutting the site down
Doing an svn up
This is fine for the most part. However, I do want to do a few other things:
Attach a version number to the filenames of images, scripts, and style sheets if the one on production site is different from what is in version control (and update all references in the mark up, scripts, etc. to these new file names)
Minify all scripts and stylesheets (and update all references in the mark up, scripts, etc.)
The ability to roll back would be nice, too.
I know about Phing and Ant, but have no experience using these tools. Suggestions?
I only have experience with Phing and not much of it (mainly a Python developer), but from what I've seen, the advantages are:
Ant is more mature, has a lot of plugins, and will integrate readily with the various Java-based continuous integration servers but doesn't understand PHP classpaths.
Phing comes with build tasks for PHP tools like PhpDocumentor but is less mature. However, you don't have to potentially install a ton of extra dependencies and an entire new runtime and SDK just for your build system and you can write new Phing tasks in PHP.
As for minifying, have you considered any of the wrappers that automatically handle compacting and caching page assets as they change?
CodeIgniter and Minify Redux
Frameword agnostic solutions:
SmartOptimizer (GPLed, more than just minification/bundling/gzip)
Minify (Link is to "how to" article)
combine (Just gzipping and bundling, no minify)
Packing Your Javascript w/o Sacrificing Performance using PHP, Caching and Apache
CSS Minification on the Fly
An Update to the Dynamic Javascript include
...and that's just from the first page of results for these Google searches.