Hi,
I'm looking through the forum to find data on XML and nested tables. There seems to be a lot of queries around this and many of the replies seem to state that this is not currently supported but may be in future.
Could you let us know what the current state of play is with this issue?
/Mcoy
Hi,
Thank you for considering Aspose.
I'm not sure what feature you mean by "XML and nested tables". Do you mean nested mail merge regions? If so, they are indeed unsupported at the moment but will be surely supported later. If you are interested in somewhat else, please specify in what exactly.
Given some XML like the following:
Gallagher
212
120305
Thompson
32
120505
Is it possible to use xpath within mailmerge to identify fields like:
<><><>
Thank you for your interest in Aspose.Word.
The current way we are planning to support nested mail merge is to rely more on DataSet, DataTable and DataRelation classes.
We plan that the customer will create an appropriately shaped, sorted and filtered DataSet before passing it to Aspose.Word mail merge. Aspose.Word will examine the DataRelation and DataTable objects in the DataSet and attempt correlate them with mail merge regions defined in the document.
From my point of view it is a generic enough solution given DataSet and DataTable are cornerstones of ADO.NET (not sure if DataRelation is used by many developers). Also, .NET provides some nice features that allow to load an XML file into a DataSet either with a schema or by inferring a schema. I would try to avoid building a very custom reporting engine if possible and would prefer to rely on .NET technologies and patterns familiar to many .NET developers.
Your mentioning of XPath does sound interesting and I will keep this in mind when designing nested reporting engine further, but right now I cannot see how it will fit with what I've just described.
Actually, I would like to open this dicussion up for all customers to solicit as much requirements and feedback about what features and capabilities you would like to see in a reporting engine. This approach works well at Aspose, one of the recent examples is the support for copying content and formatting feature discussed here.
Please feel free to post your requirements, ideas and concrete examples.
Looking at your example, it strikes me that you want to put the filter into the document template. So far I thought it will be the responsibility of the customer's code to filter the DataSet before passing to Aspose.Word mail merge. What do you think of these two different approaches?
Hi Roman,
thanks for the reply. I agree that with enough thought this problem can be overcome with some coding effort up front before we pass the data set into mailmerge. I'll just explain where I'm coming from with this. We are currently using another publishing system to automate our document publishing. For them, we defined a working XML which we would pass into their which they would then use to populate variable fields and select which documents should be selected at which point. For a number of reasons, we are evaluting whether to replace this current system with other vendors.
The sample XML I quoted above is obviously just a contrived version of this XML which we pass to the existing publishing system. It's structure (which can of course be altered to suit) did highlight that the behaviour for handling multiple rows within a table (or nested XML as I was calling it) did not match what I had been expecting. I had thought I would be able to use XPath or something similar to identify the specific rows within a table. This feature is important as we only want text to be inserted for a given row if certain conditions are matched. With ExecuteWithRegions I found that every row was printed out for the table.
/Mcoy
Even though Aspose.Word does not support XPath expressions to select or filter data for mail merge like that, I can see there is a potential for a feature like this.
At the moment Aspose.Word's reporting engine allows to put only field names in the document, but I think the way its heading is to allow placing more report-syntax constructs in the templates:
Sorry cannot help more right now, you will need to perform that filtering before calling Aspose.Word mail merge.
Just getting back to the original question so. Do you have an inclination as to when this xpath searching/filtering will be started and/or delivered?
Sorry no comments at this stage. We will consider xpath filtering when working on the next round of mail merge enhancements. No dates.
The issues you have found earlier (filed as 39) have been fixed in this update.
The issues you have found earlier (filed as WORDSNET-50) have been fixed in this .NET update and this Java update.
The issues you have found earlier (filed as ) have been fixed in this update. This message was posted using BugNotificationTool from Downloads module by MuzammilKhan