Choosing A Webhost:
A web hosting service is a type of Internet hosting service that allows individuals and organizations to provide their own website accessible via the World Wide Web. Web hosts are companies that provide space on a server they own for use by their clients as well as providing Internet connectivity, typically in a data center. Web hosts can also provide data center space and connectivity to the Internet for servers they do not own to be located in their data center, called colocation. more...
|
RE: Document automation with DataPerfect: msg#00004
db.dataperfect.general
|
Subject: |
RE: 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
| |
