Plutext

In current SVN, I've changed the way you make a content control a repeat or a conditional.

I've updated the convention document[1] to version 2 to reflect this new approach.

In a nutshell, the reasons for the changes are:

1. content in the sdt tag is minimised, which is desirable since Word restricts the tag content to 64 characters

2. supports conditions made up of boolean expressions (though docx4j currently only processes conditions equivalent to those supported in v1)

3. supports interactive processing (ie user gets asked questions) via appropriate software; v1 only supported non-interactive processing

To set up the bindings, there is now a Word Add-In you can use. Please note that you will need to install .NET Framework 4.0 ("full" - the "client profile" is not enough). It is currently a little rough around the edges, but it works. Some notes on how to use it are at [3]

The next release of docx4j (probably later this month or early next) will only support this new format. If you have docx documents using the v1 convention format, you can convert them using the main method in [4], which I've developed for this purpose.

cheers .. Jason

[1] http://dev.plutext.org/svn/docx4j/trunk ... tions.html

[2] http://dev.plutext.org/opendope/setup.exe

[3] http://dev.plutext.org/svn/docx4j/trunk ... hrough.pdf

[4] svn tip version of http://dev.plutext.org/svn/docx4j/trunk ... ePart.java

I've published v2.1 of the convention.

There is an important change: a repeat xpath must now point at the element to be repeated, not its parent container. This was done for ease of integration with other systems. Existing docx will need to be manually updated.

docx4j svn trunk implements this (1276).

The Word Add-In can now inject a macro into the docx which processes repeats/conditions interactively. This macro implements v2.1 of the convention.

For further details, see the updated docs referenced in the previous post.

Hi Jason,
The conventions document doesn't state how you can use boolean expressions in a condition..
Can you specify an example?

(BTW - docx4j is a great library!)

Thanks.

See http://dev.plutext.org/svn/docx4j/trunk ... itions.xsd

But evaluation of "complex" ie conditions made up of boolean expressions isn't supported in docx4j yet - sorry about that. I'll expect to implement this over the next couple of weeks; I'll add some examples then.

Do you have any plans to support conditions like -
/invoice/items/item/price > 100
(xpath, operator, value)

Absolutely. I plan to support XPath expressions such as that. I've updated the conventions document to cover this.

In fact conditions like that work in docx4j 2.6.0 for non-interactive processing (ie where the XML part already contains all the data), which is the use case docx4j supports out of the box.

Its a bit more complex for interactive processing, which the convention supports (but for which you'd need to write additional code on top of docx4j to support in Java). Here you first say, "ahh, i need to inject a value into /invoice/items/item/price" (or whatever node(s) are part of the expression), and only after doing that, evaluate the expression.

cheers .. Jason

Thanks. Currently I added 'operator' and 'value' attributes to Xpathref and calling my ConditionEvaluator.
Did you consider registering custom handlers to OpenDoPEHandler?
Something like -

Code: Select all

processBindingRoleIfAny..
List<Object> = getHandler(tag.getVal()).handle(wordMLPackage, sdt);

That could definitely be done - great idea! (I'd like to do something similar in the HTML and PDF export as well, so a content control with a particular tag would get special handling. This could be adding a particular @class val in the HTML output, or something more complex)

I'd like for the vanilla convention to cover the most common use cases though, so most people can do what they want without having to add a custom handler.

So please, anyone with requirements which aren't currently handled, pls suggest, so we can discuss the most appropriate way to handle.