I just upgraded my project from ServiceStack 5.1 to 5.5.1. Now where I am using TemplateContext from ServiceStack.Templates it tells instead to use TemplateContext. Needless to say, this is likely a mistake in the description for the Obsolete attribute. What is the appropiate replacement for TemplateContext now in ServiceStack 5.5.1?
The depreciation message should’ve said to use ScriptContext instead.
In the latest ServiceStack v5.5 Release ServiceStack Templates has been rebranded to #Script.
The section on Migration to new Script API's explains how to migrate in more detail:
Migrating to the new APIs is fairly straight forward:
Change using ServiceStack.Templates; to using ServiceStack.Script;
Any classes with TemplatePage* has been renamed to SharpPage*
Any other class with a Template* prefix has been renamed to Script*
This change doesn’t affect any of your existing #Script source code whose existing syntax and available filters/methods remains unchanged.
New Terminology
The primary rationale for the rebranding was so we’re better able to label, describe and document all of #Script different features easier, so when referring to Templates View Engine we’re now calling Sharp Pages which is a better corollary to “Razor Pages” which it provides an alternative to.
Other re-branded features:
API Pages are now called Sharp APIs
Web Apps are now called Sharp Apps
Template Filters are now called Script Methods
Template Blocks are now called Script Blocks
The collection of methods you inject in your scripts like TemplateRedisFilters and TemplateDbFilters are now referred to as “Scripts” where they’ve been renamed to RedisScripts and DbScripts.
Related
I am using ODM 8.10 and want to automate building rule app files. The code is currently configured in the old Classic Rule Project, and we are trying to avoid migrating to Decision Services at this time. I have found build jars for Decision Services but nothing so far for Classic Rule Projects. There must be a way to do this as the rule app jar files are created in the eclipse IDE when you deploy/export a ruleApp. I am trying to find out the jar files the IDE uses and the commands it calls to execute the rule app builds.
Re: "There must be a way to do this"
But you will not necessarily have access to it. The ODM product developers have experience, source code, documentation, and other tools that you do not have access to.
Having said that, there is an build/deploy API that you may be able to access via ANT. I haven't used it since switching to Decision Services when that became feasible in ODM 8.7. Standard practice before that time was to automate deployments via Ant and a "headless" version of Eclipse. If the latest online docs don't describe it, you might try the older docs.
WARNING: Classic Rule Projects are a dead end! Not only will all your effort building them in a non-standard way be wasted, I believe that it will likely be more trouble than just migrating to Decision Services (which is not usually that difficult).
I am trying to override the a template Entity.java.ejs in my custom blueprint to add some extra functionality. Unfortunately JHipster uses its default one if generate an entity. I don’t want to overwrite the whole writing. Is there a possibility to override only certain ones and use JHipster default templates for the rest?
Helo friend,
in this period I see an application jhipster with a partial custom .ejs defining a default for others components.
The problem is that the overriding is very huge, and cabled only for a specific version 6.9.1 of jhipster.
If this is a good idea to custom a particolar application with a particolar version and with a specific cabling code ok, but is not good if you want a generic custom generator jhipster context, where you can "inject" only custom files, giving overriding of all scope original generator.
I try to search some answers searching on web, and your question is anyway a good clue to define a better solution that I see now.
The problem that I see is that jhipster environment dont have a "handling" approach about .ejs templates, when is very strong and straighweird when you use .jdl file .
An easly customization of templates of any jhipster application created with command "jhipster", ad example.
And searching I see this link https://github.com/jhipster/generator-jhipster/issues/1749
an issue of original jhipster generator where someone consider a good idea to use "subgenerator" using yeoman to modulerize this templates and with all benefits.
This is a another clue to understand somethings.
good luck and thanks
Since the generated java code doesn't fit all my needs, I would need to modify the templates (mainly in server). Small modifications are pretty straightforward but I was wondering if there is some tool to go from existing java code to this template.
We did modules for this use case, and I even did some specific ones for some clients. So this would be my favorite solution.
Then, I clearly see in our stats that many people are forking JHipster and modifying it - this is probably easier at first sight, but of course you'll have trouble when we release new versions, as you will have to sync your code with each new release.
i'm newbie in JHipster and i'm trying to figure this, when i create a new entity JHipster generates several files, angular, html and java classes, now if i want a common code for all this generated code i must edit each time that i use the yeoman generator? what i want is:
Custom Index template, and pages, is secure to edit them?.
Customize the entity tables, entity forms using angular, maybe extending yeoman generators
Customize generate java classes, maybe i think using AOP
So i need to edit each time for each generated code? and is a good practice this or what i want? for clarify more i want to use a Custom Bootstrap/angular Dashboard template like Minovate, i see how to customize bootstrap in the documentation but not about what i'm asking for, Thanks.
JHipster is just a code generator, once generated the code is yours.
For angular screens I would say do as much as you can in CSS/SASS.
But it's very likely that you will need to build some screen mixing several entities and change the structure of entity screens.
So you should rather consider them as a starting point and do your own stuff in another folder so that it does not get overwritten by next re-generations.
This way you can still update your entity definitions in .jhipster folder and re-run yo jhispter:entity <entity name> on the entities you modified.
Customising java Entities is usually much simpler and you can easiliy achieve this by merging generated code with git and defining your service classes.
AOP seems overkill here.
Extending a yeoman generator is a lot of work.
I suggest to use some VSC (git, subversion or whatever you like) have a branch dedicated to plain jhipster generated code and another one where you make customization.
Eventually regenerate on jhipster branch and merge back on yours.
You should at least reduce manual intervention.
Does anyone have experience, information or some (coding) examples about a solution to establish a connection between the appserver of progress and node.js!? The aim is to create REST-Services to the db which can be accessed by the web like an angular-app.
Thanks for any advice
Christian
Starting with 11.2 (and enhanced in later versions) you can create REST-based applications utilizing the AppServer as a platform. ProDatasets are used as output (they convert easily to xml and/or json).
This is all explained in the Web Services part of the documentation. I'm providing a link below.
Basic steps
You need to consult the manual for all these steps...
Create an ABL program with input parameters (could be a parameter, a temp-table or a dataset) and and a single output parameter (could be a temp-table, a dataset or a single character or longchar parameter).
Add ABL-specific REST annotation to the program
Map the parameters in OpenEdge Studio
Setup REST agents with the restman utility
Export a "WAR-file" and deploy your webservice.
Calling the web service from node.js should be no greater problem than calling any REST based web service.
In versions prior to 11.2 you can "fake it and make it" utilizing WebSpeed. You can create a webspeed program that read parameters from the query-string (using get-field()) and then writes a response to the "webstream". Use either the WRITE-XML or WRITE-JSON methods on a temp-table or a dataset for writing the result. Don't forget to add a good MIME type though... This might not be as robust and customizable but it will work...
OE 11.4 Product Documentation - Web Services See chapter "II Creating OpenEdge REST Web Services"
These might also be useful:
OE 11.4 Product Documentation - Working with XML
OE 11.4 Product Documentation - Working with JSON