Posts made by bjrmatos

this is fixed now, it is going to be part of next release

update: we improved the error message to include the most likely problematic text in the docx template. it will be part of next release

hi! thanks for the bug report, yes both syntax should work since this is what handlebars supports, we will check what is happening.

@WadeBenz using colsWidth=["500px"] is not a valid way to pass an array to a handlebars helper, in the pptx you need to have something like this: colsWidth=colsWidth, and your data should contain the value colsWidth: ["500px"]

after you fix this, the colsWidth works as expected.

okay that is what i figured when playing around with the xlsx recipe. just to clarify, this recipe allows generating dynamic cells from EITHER horizontal or vertical but NOT both?

yes, we recently introduced the support for vertical loop, so it is matter of time to introduce the mode to produce cells in both directions and have fully dynamic cells support.

hi! this is not possible right now.

to be able to do what you want, we will need to generate dynamic cells from both directions, right now you can generate cells horizontally (using the each loop, just like in your example), and generate cells vertically (using {{#each items vertical=true}} and placing the end of loop vertically)

support for generating the cells from both directions is not yet possible, you can subscribe here for updates about this feature, we will try to increase the priority for it, but no promises

yes, i get that the template gets too verbose, but we always choose to throw error on invalid usage. this way you have the reason why something does not produce the expected output while developing the template.

your use case is exactly why scripts exists, if there is some transformation or normalization you need to do to your data, beforeRender script is the place, and as far i can see your use case is well covered by just using the script.

allowing to wrap the docxHtml will be a complex task, and not sure yet if possible, because we need to know the paragraph containing the docxHtml call, and without the convention of checking for an exact name like docxHtml we will need to take more complex approaches.

1. If the data is null docxHtml return error, so for start return null or blank and do not fail the entire document

right now, if you pass null to the content hash parameter of docxHtml it throws an error, so you mean that you don't want that, right? you want instead for the render to continue with just an empty part. if that is the case you have two options that does not involve wrapping a helper.

• you can normalize your data in a beforeRender script, just check your data fields there and set empty space '' directly there.
• if you don't want to alter your data in script then you can call docxHtml with a handlebars subexpression like this {{docxHtml content=(normalizeEmpty html)}} without needing a helper wrapper. then you just need to create the normalizeEmpty

function normalizeEmpty (value) {
  return value == null ? '' : value
}

try to create html for a table from json and then embed it in the word template

i think for this case you can also use a handlebars subexpression, to do what you want, {{docxHtml content=(jsonToHtml json)}}, you just need to ensure your jsonToHtml helper takes the json and converts it to an HTML string and you are good to go.

hi!

generally speaking it depends, sometimes we check for the specific call in the document, so we expect the same name of the helper to be there. in the case of docxHtml we search for the exact call to happen in the document, so if you wrap it with your own, it wont work because we wont be able to find the call.

what is your use case for this? what do you want to do in your own wrapper?

hi! please share the template that it is giving you these errors

Since you mentioned that using a promise with a URL as the "src" is expected behavior, I think we can keep our current implementation as is

it depends from where the promise comes from, as i said if the promise comes from async handlebars helper it is fine, but if the promise is not coming from handlebars helper then it is just a coincidence that it works right now. i would let the promise behaviour only to handlebars helpers, for other execution like in scripts, just await the value.

I do have one additional question: when adding promise-based properties to the template’s "data", are there any limitations on what can be passed? Specifically, does the data need to be JSON-serializable, or can it include any JavaScript variable?

you can use any javascript value, jsreport wont complaint, unless you pass a value when another type was expected, but this depends on the libs you use, etc.

hi!

I suppose this is due to using the waitForAsyncHelper inside the docxImage

yes, this is the main reason, we want that user is able to get src image from async executions, like HTTP requests. so that waitForAsyncHelper, makes this to work:

{{docxImage src=(getImageFromServer) ...}}

async function getImageFromServer () {
  const result = await makeYourRequestHere()
  // result should be a base64 string representation of the image
  return result
}

Would it be reasonable to rely on this feature of the 'src' property, or is it better to strictly follow the documentation and provide a string value?

we expect this to work correctly when the async execution happens between handlebars helpers, in the example, getImageFromServer is an async handlebars helper, so this is expected to work.

as long as you do the async work from an async handlebars helper, it will work.

what is your use case? or what code are you trying to make it work by passing a promise?

hi!

yes, the introspect endpoint is a requirement when using HTTP requests to the jsreport HTTP API. right now there is no other way to authenticate the token against the authorization server.

i am opening a new issue to check what MS is recommending in this case (validate with the token signature and issuer validation in the OpenID discovery document). you can subscribe in the issue for updates about the feature, however we don't have am exact time when we will check this.

thanks, sounds like a good idea. i have created a new task for it. lets see when we get to it.

hi! there are no plans to support more engines for docx. the complexity there is already high, we don't want to complicate it more.

What makes using handlebars tricky for us is inability to address results of the function like
getData(this.order).name
I understand that by handlebars ideas data should be prepared beforehand, but it really overcomplicates things for us.

not sure if you are aware but, handlebars supports subexpressions, which will simplify your calls to this {{lookup (getData order) "name"}} (the lookup helper is a handlebars builtin helper FYI)

i have checked both templates, i will try to explain why each template does not work as expected.

in both of your templates the table is defined with text wrapping enabled

when this option is enabled it causes the XML of the paragraphs around the table (both the the one at the top and at the bottom) to be affected. what does this mean?

it means that visually the representation of the nodes in the template is like this:

• previous paragraph (visually the one at the top of the table)
• table
• next paragraph (visually the one at the bottom of the table)

however, internally the real representation in the XML is like this:

• previous paragraph (visually the one at the top of the table)
• table
• next paragraph (visually the one at the bottom of the table)

this behavior produces different results on each of your templates

for template v2

the template produces tables overlapping because this is the normal behavior of a table with text wrapping enabled when there is no text around. if you put two tables with text wrapping enabled and there are no paragraphs around them, the tables will overlap.

in this case the loop in the XML is represented like this

• paragraph 1 (start of loop {{#each}})
• table
• paragraph 2 (empty one)
• paragraph 3 (end of loop {{/each}})

in our docx processing if we detect paragraphs with no more text other than the handlebars calls, then after processing the template, these paragraphs are removed in order for them to not affect layout, so based on this the final result of the loop is this:

------ iteration 1 -----------

• table
• paragraph 2 (empty one)
  ------ iteration 2 -----------
• table
• paragraph 2 (empty one)
  ------ iteration 3 -----------
• table
• paragraph 2 (empty one)
  ------ ...continues... -----------

this is why the final result is overlapping tables, because for sibling tables (that have text wrapping enabled) to render correctly in MS Word the internal representation should be like this

• table
• empty paragraph
• empty paragraph
• table
• empty paragraph
• empty paragraph

how to fix the template v2?

you have two options:

• you can either disable the text wrapping in the table
• or prevent the paragraph that contains the end of loop to be removed, if you go with this option then you only need to put a leading space in the paragraph that contains the end of loop. so it should look like this <empty space here>{{/each}}

with either of these solutions you should be able to produce the expected result

for template v2.1

in this case the loop in the XML is represented like this

• table
• paragraph 1 (start of loop {{#each}})
• paragraph 2 (empty one)
• paragraph 3 (empty one)
• paragraph 4 (end of loop {{/each}})

as you can see, the problem is clear, the loop does not wrap the table, there is only empty paragraphs in the loop body, so this template does not produce anything meaningful

how to fix the template v2.1?

you have two options:

• you can either disable the text wrapping in the table
• or you can put the start of loop in a paragraph that is not around the table, you can create a new paragraph before the paragraph 1 and there put that start of the loop, just similar to the template v2

i hope this clarifies the reason of the results, we don't plan to do something to change the output when tables with text wrapping is enabled, as described there is easy solution for this just by changing the template. applying a solution that might try to "fix" this automatically will cause side effects on other cases.

this was recently added on master, not released yet.

hi!

for template v2.1 is clear that the issue is that the loop does not output anything, for template v2 what is the issue?

it is the that the rows are overlapping each other, right?

i have added to the backlog to check this case, we will get to it.

yes, i have it implemented in my local, i am now working on adding it to docxTable too for feature parity

i took a look today and this usage was never intended to work. as the docs shows, you should either use pptxTable as a row loop, or a vertical column loop.

you are trying to use the helper in two rows and this is not supported, you should try using the dynamic columns variation to get your desired layout.