Hi Brian,
As always it is really great to here your prospective on things, I
always learn something and or it gives us ideas to implement. I would
like an example. Again, thank you for your willingness to share your
ideas.
Michael Shadel
Brian Hancock wrote:
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
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
|
