|
Hi Tony,
But I have to say that having open formats based on
standards of sorts is a better way to have documents. XML documents are far
easier to work with and mean that data is not locked up in a proprietary
format... WP for DOS was great, and I am sure had it survived its abysmal
transition to Windows, that it probably would have gone down the XML route and
would have done it far better than Microsoft. Microsoft rarely has depth in its
products, only what marketing understand they can readily sell makes it
in...
I would like to see in the information about
production of RTF documents.
The main benefit of XML over RTF is that you would
not have to create the entire document inside DP, which is quite limiting. When
you use external stylesheets, it means that the DP XML output is incredibly
simple... I should post an example...
Regards
Brian
----- Original Message -----
Sent: Wednesday, December 05, 2007 5:24
AM
Subject: RE: [Dataperf] Document
automation with DataPerfect
Hello Brian ... quite a dissertation. :) Thanks for
sharing.
FWIW, Bruce Conrad and Thom Boyer taught me how to produce .rtf
documents through DP which I used regularly between 2001-04 in sending trip
proposals, confirmations and invoices as Word documents. If you or
anyone else in the group want to hear more about this, I'll dig out my notes
and samples.
It is really a shame to see WordPerfect "drift into the sunset".
There's no question about it being a far superior wordprocessor than Word with
all of those nifty tools such as macros and reveal codes. If someone has Bill
Gates' ear, they should convince him to buy it and incorporate it into the MS
product line. It will far improve their
wordprocessor.
All
the best,
Tony
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
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
Dataperf-Ii8YPGKeNuMyuW1uK6fEew@xxxxxxxxxxxxxxxx
http://lists.dataperfect.nl/mailman/listinfo/dataperf
|
