hi! you can disable the studio extension using the following config described here. the studio extension code will still live in the server but it won't be imported by jsreport so it will not add execution time when jsreport starts. if you want to don't have the studio code at all then you can just delete the node_modules/jsreport-studio folder before you deploy to your server
Is there any reason that the docx/pptx recipes are quite different to the xlsx and others in the way it works?
as you already know, trying to make dynamic these kind of documents (xlsx, docx, pptx, etc) is tricky, they are static by nature so if you want to generate these files based on some dynamic data you need to go low level in the internals of these files and start to find, update, add things manually.
this is basically the approach that uses the jsreport-xlsx recipe, it lets you modify the internal structure (xml files) of the xlsx using template engine and raw xml modifications, this approach is really powerful because you can do everything you want with the files, but it requires that the developer have to become an expert about the OpenXML spec, which makes simple things harder, complex things even more harder, and in most cases a bit impossible to do it manually. knowing how to correctly modify these xml files is hard, it requires some level of expertise in the OpenXML spec, as you may guess using this approach is not the best for the developer, not everyone will become an expert in the OpenXML spec and we identified that as a major flag in this strategy, and we always thought that using the xlsx recipe is not the best experience with jsreport.
the way that docx, pptx works is our new attempt to fix the developer experience when generating dynamic office documents, instead of let you modify the xml files on your own, we instead handle these manual operations (updates to the xml files) ourselves, you as the developer only need to define the dynamic parts of the office document using handlebars syntax {{}} (which is easy to do when you do it using the visual editors like Word, etc) and we will do the rest of the job in order to modify the xml files. this approach is not powerful from the start, because it is always limited to what we expose and support, but we think is a great experience for the developer to define dynamic content in this way intead of going to low level in xml internals. it will eventually become more powerful, we will continue adding support for more complex things the developer try to do, we just need bug reports and use cases to continue improving the extensions.
Not in a rush to use them, but was trying to understand if we'll end up with a similar model where we can edit the script within Studio and use that to update a bare bones template (more so for docx than powerpoint)?
it is still too early stage for docx, pptx. so far we don't let you modify the xml files on your own, so you can not use an script to modify the template content in this way. however this can be possible in the future, we can expose some kind of api for scripts which can let you modify the template the way you want, but as i said we are in early stage and we are still looking for more feedback to discuss what good solutions can look like for each use case.
I spent some time today trying to build a template for a table in Word which will have a variable number of columns as well as rows and while this has been fairly easy to achieve in chrome-pdf (including switching from portrait to landscape if the number of columns exceeds a certain threshold) and loading the data into an xlsx sheet ... I've got nowhere productive with the docx setup (and having to edit the template in Word and upload has made it more time consuming!)
i see, have you tried to create the docx template as a linked asset? i mean, when you create an asset, you have a "link to existing file" checkbox, if you select it you can pass there a path to your docx file and the asset will always read that file directly from the filesystem and treat it as the source of truth. using that approach you won't need to uplodad the docx file every time you make a change to the docx template.
I delete the comments from ReportEditor.css in the node_modules/jsreport-reports/studio folder
yes, this is an issue that we have fixed in master branch of jsreport-reports, not released yet, so that issue will be gone soon and you won't need to delete the comments manually.
But I get the following errors:
ERROR in ../jsreport-scheduling/studio/ScheduleProperties.js
Module not found: Error: Can't resolve 'cron-builder' in 'C:\dev\lib\jsreport-extension-starter-kit\node_modules\jsreport-scheduling\studio'
ERROR in ../jsreport-scheduling/studio/ScheduleProperties.js
Module not found: Error: Can't resolve 'cronstrue' in 'C:\dev\lib\jsreport-extension-starter-kit\node_modules\jsreport-scheduling\studio'
ERROR in ../jsreport-scheduling/studio/ScheduleProperties.js
Module not found: Error: Can't resolve 'ordinal-number-suffix' in 'C:\dev\lib\jsreport-extension-starter-kit\node_modules\jsreport-scheduling\studio'
ERROR in ../jsreport-assets/studio/AssetEditor.js
Module not found: Error: Can't resolve 'react-copy-to-clipboard' in 'C:\dev\lib\jsreport-extension-starter-kit\node_modules\jsreport-assets\studio'
yes, this is an issue that we have with some extensions that specify its dependencies a bit differently. however you only get this errors on console because the current jsreport-studio-dev that it is specified in the package.json of the extension starter kit is a bit old, that version tries to build all extensions (including the ones from jsreport), instead of just the one that is being developed, that was bad and we changed it in new versions of jsreport-studio-dev (now it builds just the extension that is being developed by default).
i have updated the extension starter kit (updated deps, and some small changes) and you should not have these errors on console anymore when you start a new project.
i see, hmm when i see this kind of errors usually i "fix" it by increasing/reducing the margin - bottom of the pdf page (which you can do on the chrome pdf properties of studio). in most of the cases i'm able to fix those problems by doing that, i think it can be a good workaround for the chromium bug
i think this is an old problem when mixing table elements (like tbody) and page-break-inside, so far i did not found any good solution for this that does not break the layout of the header or other part of the table
if you find a solution, let us know, it will be helpful for other users
PD: here is a more detailed explanation of why this does not work, and the solution described there does not work today 😔
unfortunately, there is no way to reset the credits in this case. I understand that you were consuming the credits just for testing but this is the limitation of the free plan.
if you want to test jsreport client integrations the best for you will be to start a jsreport locally just for your testing purposes (so you don't consume the credits of your account), then when you know that everything is working, you just need to update the serverUrl and Authorization to talk the the jsreportonline, basically two lines change and you avoid wasting the credits for testing purposes.
i think you are getting confused about the right sdk to use, it looks to me that you are trying to execute this in the browser but the code you are using looks like the node.js sdk which does not work in the browser, you need to use the browser sdk for this, we have an example here that includes some code to download the file.
according to the browser sdk api your code should be like this:
// somewhere before sending the request you need to configure that you want to use jsreport at specific url and credentials, in this case your jsreportonline url
jsreport.serverUrl = 'https://your-account-name.jsreportonline.net/api/report'
jsreport.headers['Authorization'] = "Basic " + btoa("youraccountname:youraccountpassword")
jsreportClient.renderAsync(requestData).then(function(res) {
this.$store.commit('setLoading', {
show: false,
});
res.download('myfile.pdf')
})
are you able to replicate the issue every time you upgrade the jsreport? i mean, if you go back to your previous jsreport/jsreport:2.0.0-full image with the same data folder that you have at that time, and then try to upgrade to jsreport/jsreport:2.6.1-full, does the issue continues to happen every time? if this is something you can reproduce every time you try to migrate from jsreport/jsreport:2.0.0-full to jsreport/jsreport:2.6.1-full then best will be that you share with us the data folder that you have on jsreport/jsreport:2.0.0-full so we can inspect what is happening, since the addition of folders entities to jsreport (v2.3.0) there is a migration step that we run at jsreport startup that tries to migrate entities to folders, it can be the case that this migration is causing this issue by duplicating the shortid, however we never saw this before.
grep -r A05ha9 ./
.//data/assets/config.json: "shortid": "A05ha9",
.//data/assets/global helpers.js/config.json: "shortid": "A05ha9"
hmm i'm not sure that this is really printing you a duplicate, because the data/assets/global helpers.js/config.json can contain this (which is valid, not a duplicate)
{
...
"folder": {
"shortid": "A05ha9"
}
}
you should verify by opening the two files and checking that the top level property "shortid" does not duplicate in both files.
{
// if there is a bug about duplicated shortid, then the two files should contain the same
...
"shortid": "A05ha9"
...
}
your config should be:
"extensions": {
"chrome-pdf": {
"launchOptions": {
"args": ["--no-sandbox"]
}
},
"html-to-xlsx": {
"chrome": {
"launchOptions": {
"args": ["--no-sandbox"]
}
}
}
}
or just shared chrome config
{
"chrome": {
"launchOptions": {
"args": ["--no-sandbox"]
}
}
}