Great news, many thanks...
Posts made by ThomasJReiter
-
Async function won't show component call
We have a report which contains more or less an "optional" component template. If the template exists on a specific path we print it, if not, we don't want to get an error in the report
throw new Error(``Component ${path} not found``)
Therefore we created a handlebar conditional which returns the
options.fn(this)
if the template is found and we call thecomponent
helper to print the component.
Up to jsreport 4.2.x this just worked fine and the component content was printed, since jsreport 4.3.0 the component block just returns a string (I guess an object reference).{{#componentExists "./components/student"}} {{component "./components/student" classRoomDetail=(findClassRoomDetail classRoom)}} {{/componentExists}}
const jsreport = require('jsreport-proxy'); async function componentExists(componentName, options) { const component = await jsreport.folders.resolveEntityFromPath(componentName, 'components'); return component ? options.fn(this): options.inverse(this); }
I'm thankful for any advice why this is happening and/or how the original behavior can be recreated (printing the component content).
Here's a running example of our report setup. The works in jsreport 4.2.x
https://playground.jsreport.net/w/ThomasJReiter/~ejVYSVP -
RE: Regarding schedule to generate jsreport overnight
We're doing this via a build pipeline during master build, but could also be scheduled, and use the jsreport api to export all reports we have and publish them to an artifactory. We're using gitlab and our pipeline has following jobs. Would this be a solution?
build jsrexport: stage: build image: name: <jsreport-docker-image> script: - echo "### BUILD JSREPORT EXPORT FILE" # all our jsreport templates are in the folder 'templates' and it's sub folders # the jsreport working directory is app/data in our case - cp -r templates /app/data - cd /app - jsreport export $CI_PROJECT_DIR/export-full.jsrexport artifacts: expire_in: 3 days paths: - '**/export-full.jsrexport' publish jsrexport: stage: publish image: name: <some docker image with curl> script: - curl --fail -u ${USER}:${PASSWORD} -X PUT https://<where_we_put_it>/export-full.jsrexport -T $CI_PROJECT_DIR/export-full.jsrexport
-
RE: Error when loading fs-store@3.1.0 in jsreport 3.3.0 and 3.4.0
Hi,
Are you running jsreport directly in WSL2 or with docker/podman?
I had a similar problem with a rootless podman installation, and therefore changed to a simple docker solution. Then I was able to mount the automated mounted folders in WSL "/mnt/c/..." to my docker container and enable the direct synchronization.Docker in WSL
https://dev.to/bowmanjd/install-docker-on-windows-wsl-without-docker-desktop-34m9Docker Command
docker run -e "licenseKey=$LICENSE_KEY" -p 5488:5488 -v /mnt/c/.../templates:/opt/jsreport/data jsreport/jsreport
-
RE: Localization Helper in 3.3.0
For me it would be fine to stay with your current implementation and document the use-case somewhere in a how-to.
Currently our complex case is implemented like this.
async function translateWithFallback(key) { const template = jsreport.req.template const templatePath = await jsreport.folders.resolveEntityPath(template, 'templates') const folderPath = templatePath.substring(0, templatePath.lastIndexOf('/')) return jsreport.localization.localize(key, folderPath + '/translations') .then(translation => { return !translation ? fallbackTranslation(key) : translation }) .catch((e) => fallbackTranslation(key)); } function fallbackTranslation(key) { const defaultDataPath = "translations/en.json"; return jsreport.folders.resolveEntityFromPath(defaultDataPath, 'assets') .then(function(resolvedValue) { return JSON.parse(resolvedValue.entity.content.toString()); }) .then(function(data) { var v = data[key] return !v ? "[" + key + "]" : "*" + v; }) }
Of course neither capable of special translation folders nor any other fallback language then English.
-
RE: Localization Helper in 3.3.0
Thanks for the clarification.
What I meant was that we fallback for each translation individually. If not found in the given language we search in english and if we don't find it there we return the [key] instead of undefined. Outlined in reportB of the example.
https://playground.jsreport.net/w/anon/K78DqxIW -
RE: Localization Helper in 3.3.0
Thanks for the fast response, works well.
Just out of curiosity, are you considering a fallback to a default localization if no language is found? Currently an exception is thrown and the whole report won't build.
Edit: I added our fallback handling in the playground example from above.
-
Localization Helper in 3.3.0
Hi,
Our template structure looks like this
Besides other functions we have a
translate
function in ourglobal-helper.js
since all our localization is located in a sub-folder translation, it''s quite handy in a report templates to write{{translate "text"}}
.const jsreport = require('jsreport-proxy'); function translate(key) { return jsreport.localization.localize(key, "translations"); }
Since the upgrade to jsreport 3.3.0 we face the following error message with our setup.
Report "reportB" render failed. Error when evaluating engine handlebars for template /reportB/reportB localize helper couldn't find asset with data at translations/en.json Error: localize helper couldn't find asset with data at translations/en.json at Object.localize (/app/node_modules/@jsreport/jsreport-localization/lib/worker.js:44:17) at async /app/node_modules/@jsreport/jsreport-core/lib/worker/render/executeEngine.js:133:40 at async Promise.all (index 0) at async executionFn (/app/node_modules/@jsreport/jsreport-core/lib/worker/render/executeEngine.js:132:9)
Are we doing something wrong? Was this changed from 3.2.0 to 3.3.0 and if so, is there a possibility to fix this? Is there another way to solve the situation?
The release notes of 3.3.0 state "fix not resolving relative path correctly when calling asset code from another asset". Is this maybe the reason?
You can find a setup here
Thanks in advance for any advice.