Hi all, I was going to send this as a private message to Laurie as I had a recollection she had document automation as part of her DP application, but I thought it might be of more general interest, and so I jhave expanded it a little.
In the past I have used WP5.1 for DOS as a high quality print engine for DP, exporting a secondary merge file from DP and merging it with a WordPerfect primary file. It is a very powerful and flexible process, however one of the issues with conventional merging is the problem of merging relational data, ie multiple related tables. A simple invoice where there are multiple items lines on the one invoice can be quite a challenge. Fortunately there are ways to do with this WordPerfect using its merge/macro language by creating loops to loop through the fields that make up the item lines, but it is not for the fainthearted. But, alas, it is now pretty well impossible to base a system on the merging of data with WordPerfect, dare I say it, WordPerfect is dead or at least on its death bed. Most people now use Microsoft Word, but merging data with Word is not very satisfying. You either jump from simple merges which do not have anywhere near the power of WordPerfect or else you take a leap and use VBA or VB.NET and Automation (which is essentially programming the control of one program from within another program). With Word Automation there are a variety of ways of populating a document with data, eg searching for bookmarks and replacing them with the variable data, inserting document properties and using the results in fields, or even dynamically writing out the document. All possible but very time consuming, therefore expensive, requiring good programming skills, and basically putting most of the document creation into the hands of experts. There are various 3rd party tools for assembling documents, and mostly they are quite expensive, and not easy to use. Mostly these solutions involve using Word at the client end, ie on the user's desktop. Server side creation of documents in this fashion is not recommended as Word requires a larger amount of user interaction, and cannot handle concurrent Automation sessions, so is single user throughout the document creation process, which makes it totally impractical for server side work. >From Word version 2003 onwards, Word has been able to read and save its >documents in an XML format. This has some great benefits, especially since the >documents can be read by other applications, and therefore data can be >extracted from it. Normally once data went into a Word document it could not >be easily extracted, but by attaching XML Schemas to the document you can >enforce various structures to the document, making each document's content >easily accessible to another application. Another benefit which I have been looking into is the creation of documents by using a Word documents using XML. Although many documents are now programmitically created from XML the major method employed is either using Word Automation, and/or using WordprocessingML to build documents from XML fragments. Curiously, although tools are available, it seems only a handful of people seem to be doing much work with using XSLT to create Word documents. XSLT is the main method of transforming XML into HTML documents, so I am surprised it has not had more traction. Since a Word document can be saved in XML it can be converted to an XSLT template, which can be used to "transform" XML data to create a "merged" document. The real advantage of this over more conventional merging is that the data can be relational, so taking the previous example of an invoice where one invoice can have many line items XML makes this very easy. In fact extremely complex data structures can easily be incorporated into the "merged" or "styled" result document. I have been using Microsoft Access and also dabbled with SQL Server 2005 to create the XML document. You really have a battle when using Access as Access does not understand XML Namespaces which are a critical component of using the data in Word. SQL Server allows you to do a little more, as it understands Namespaces. Neither owever allow you to directly associate a style sheet (XSLT template) to the XML data. With Access you need to transform the original output from Access into a new XML document which includes a Namespace for your data, additionally you might need to do some very serious programming work with Access as the inbuilt ExportXML is very rudimentary. SQL Server removes this step so you can you can created SQL statements that create the XML The way this is used in Word is that you open the XML Data sheet and then browse for a Stylesheet (ie the Word template) and then the document is "transformed" and you can view the document on screen. In this scenario Word is the XSLT processor, but it need not be. In fact any XSLT processor can be used, giving rise to immense flexibility. Although DataPerfect doesn't itself understand XML, because you can create whatever text output you want you can easily write complex XML output. Since everything is in your control you can add one or more Namespaces to the output, and if you like you can specify an XSLT template. If an XML document specifies a Word XSLT template then Word will open the document and transform it automatically without the user needing to browse for the template. This already makes the output from DataPerfect easy to use than output from Access or SQL: Server. If you are using a different XSLT processor, then you can create the final Word document without even using Word, which means it makes it easy for server side production of complex documents. Even though the final result document is in XML format if you give it the the file extension, .DOC then Word opens it, sees that it is XML and treats it like an ordinary Wiord document. Similarly, if the file has a .DOT extension Word opens it as though it were open a new template, which is handy since it will not get a filename and the user can save it however they please. DataPerfect then become a perfect accompaniment to creating Word documents. It can be used in its normal desktop mode, or it can be use in the web enabled mode, delivering completed Word document across the Internet or organisations Intranet. You can even deply the final document to users who only have the free Microsoft Word 2003 viewer. Writing the XSLT template is the hard part, but Microsoft has made that easier with a free download called the WordProcessingML Transformation Inference Tool , which has very scant documentation but which does a very good job. With simple XML documents even very basic users can create long complex documents templates quite easily, but with more complex XML documents or more complex formatting then some knowledge of XML , XSLT , XPath and Schemas will be very helpful. The documents themselves can be very rich. You can use almost any Word feature in the document except perhaps embedding data from other applications, unless you know those applications will be available. So for instance if you used Excel to graph something, and embed the results in a document it might be more prudent to use MSQuery and MSGraph to bind a graph to a table in word. You can start the creation of a new template either by starting a new document based on an XML sample, or you can take an existing document and attach an XML Schema to it. I hope this information is useful and perhaps can give you some ideas to give new life to your DataPerfect applications. By the way, I am about to try a complex VoIP PBX routing application using XML from DP, Access or SQL Server. The gist of the application is that customer service staff after creating an incident with a client, will have that client's incoming phone calls routed to the correct person dynamically. So instead of preprogrammed route being established in the PBX, the information for the phone routing will come dynamically based on the caller ID. In theory all that is required is to pass the phone number in the query string of a URL, to a CGI program in front of DataPerfect customer service application. eg http://www.mydpserver.com?phone=2159999999 and use the application to decide who should answer that call. Of course the VoIP PBX software has got to support that type of interface. Regards Brian
_______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/mailman/listinfo/dataperf
