469,890 Members | 2,316 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,890 developers. It's quick & easy.

Trying to create completely server side, document merge

I was given the task of designing a complete web based
document prep system. In simplest terms (using a msword
explanation) create a database of merge fields, and a
library of templates. Allow the webuser to select the
template, merge his DB record, and produce a formatted
document that can be printed or downloaded.

We need to do this without specialized software on the
client, since it will be universally available to
webusers. We considered using PDF, but the creation of the
templates were painfully slow, and the datamerge had
severe space limitations (the form could not adequately
adjust for long or short field data). We need it to
function entirely within a webbrowser.

The forms or templates in "phase one" of the roll out will
be text based documents, Simple business forms, contracts,
etc. We will probably have to integrate more highly
developed forms later, such as Gov't Docs etc.

I believe that XML could be my answer

My requirements are that template creation must be doable
by a secretary level user, not a programmer. A lot of cut
and paste. For example, taking txt legal documents,
applying formatting (fonts, margins, tabs, allignments)
and merge fields to the Doc and saving it as a template. I
assume that using Office 2003, we can save a correctly
formatted word doc to XML and put the correct datafield
links in it.

I need confirmation that what I understand "above", is
true AND that it is absolutely attainable. Not in theory
but in Practice.

RIchard Fritzler
Nov 12 '05 #1
3 5180
Yes XML and more precisely XSL is what you want. I recently completed a
system where the user could design a document and place mapped fields within
the document. This was a wysiwyg editor written for IE 6.0. Based on the
documents design the system generated an XSLT transformation document that
would transform the db fields into the document. It is very fast and
efficient and is also very very easy to learn.

Your situation is almost identical and what you need is something like this.

1. Define an XML document that is used when designing documents. The xml
document tells the 'designer' how to map the fields in your database to the
xml representation of that data, as in
<data>
<field externalName="First Name" dbfieldMap="users.fname"
datatype="varchar" size="100" xpath="//users/fname"/>
..next field
.. ext
</data>

When the user is typing there document and whish to insert a field into it
they could say click on a button and would see a list of fields where you
would use the enternalName attribute as the display name. When they insert
the field you could display, if using the editing features of IE for example
<span class=xslfld dbFieldMap="users.fname">First Name</span>. The user
would only see 'First Name'. When the user chooses to save the document you
parse the document based on the class xslfld and replace it with the
appropriate xsl command. In this case it would be:

<xsl:value-of select="//users/fname"/>

If you are not familiar is xsl it is very easy to learn and exists within
html if you want. Will find information on xsl and xpath at
http://msdn.microsoft.com/library/en...asp?frame=true.
Read up of XML, XPATH and XSL. Probably the most difficult aspect is
learning how schemas work.

2. Define your database data as a standardized xml file that can easily be
retrieve. For example:

<data>
<users fnamedbid="10">
<fname>John</fname>
<lname>Henry</lname>
<workhistory>
<workitem></workitem>
etc..
</workhistory>
</users>

In the above case the table users has a related table called workhistory in
the db where there are multiple workitems stored. It is very important to
understand how to map your database to your xml and make it consistent. One
of the nice things about an implementation of this type is that you can
easily express new data by updating your designer xml document when you
relationships are defined within your db and consequently your data xml
file.

It sounds fairly simple and it is but it can get fairly complex based on the
number of child relationships you have and what sort of formatting you wish
to support within your wysiwyg designer. A single denormalized table is
easy but providing for child relationship formatting can be more difficult.

If you are running against a database with large amount of data you need to
be able to create the data xml file based on criteria. The nice thing is
with some though you can use the 'designer' xml file to define your SQL
statement before getting your data. Like anything else it takes some
tweaking and optimization as you go along but if you plan it out well it can
work like a charm!

Hope this helps

Regards
Keith Chadwick

"Richard Fritzler" <ms********@owelesstax.com> wrote in message
news:05****************************@phx.gbl...
I was given the task of designing a complete web based
document prep system. In simplest terms (using a msword
explanation) create a database of merge fields, and a
library of templates. Allow the webuser to select the
template, merge his DB record, and produce a formatted
document that can be printed or downloaded.

We need to do this without specialized software on the
client, since it will be universally available to
webusers. We considered using PDF, but the creation of the
templates were painfully slow, and the datamerge had
severe space limitations (the form could not adequately
adjust for long or short field data). We need it to
function entirely within a webbrowser.

The forms or templates in "phase one" of the roll out will
be text based documents, Simple business forms, contracts,
etc. We will probably have to integrate more highly
developed forms later, such as Gov't Docs etc.

I believe that XML could be my answer

My requirements are that template creation must be doable
by a secretary level user, not a programmer. A lot of cut
and paste. For example, taking txt legal documents,
applying formatting (fonts, margins, tabs, allignments)
and merge fields to the Doc and saving it as a template. I
assume that using Office 2003, we can save a correctly
formatted word doc to XML and put the correct datafield
links in it.

I need confirmation that what I understand "above", is
true AND that it is absolutely attainable. Not in theory
but in Practice.

RIchard Fritzler

Nov 12 '05 #2
if your input person is going to be running Word then some thoughst -

these relate to pre Word 2003. If your create in word 2002 or previous and save as web file you will find that you get several outputs including a CSS and htm file. These are not clean. They hold all the w3c standards plus MS own stuff. But they do hold all you eed to collect the formatting styles, fields, headers footers they have used. You will need a process to capture and parse these files to enable loading into a database. Once there pretty straight forward as per previous reply.

Disuade your user from having headers and footers or TOC's. Its too early to use these with reliablity given the variety that users rightly expect. You will have fun with multi page docs if the user is firm on the formatting

************************************************** ********************
Sent via Fuzzy Software @ http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET resources...
Nov 12 '05 #3
Hi,

Check out XpertDoc at www.XpertDoc.com. I believe this tool fits all
of your requirements:

- Templates are very easy to design and maintain since they are
created directly from within MS-Word.

- No limitations on the MS-Word formatting features that you can use:
Header, footer, tables, footnotes, graphics, etc.

- Safe for operating from a Web site. XpertDoc has its own merging
module, allowing it to generate genuine MS-Word documents without
requiring MS-Word to be installed on the server.

- No special client-side module required. All the users need is
MS-Word or any other software that can read RTF files.

A large HR consulting company currently uses XpertDoc to generate up
to 300 000 documents a month through a Web site accessed by 150 000
users. It really works!

Check it out at www.XpertDoc.com...
greg austin (ga*****@proposalheaven.com) wrote in message news:<up**************@TK2MSFTNGP09.phx.gbl>...
if your input person is going to be running Word then some thoughst -

these relate to pre Word 2003. If your create in word 2002 or previous and save as web file you will find that you get several
outputs including a CSS and htm file. These are not clean. They hold
all the w3c standards plus MS own stuff. But they do hold all you eed
to collect the formatting styles, fields, headers footers they have
used. You will need a process to capture and parse these files to
enable loading into a database. Once there pretty straight forward as
per previous reply.
Disuade your user from having headers and footers or TOC's. Its too early to use these with reliablity given the variety that users rightly expect. You will have fun with multi page docs if the user is firm on the formatting

************************************************** ********************
Sent via Fuzzy Software @ http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET resources...

Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

16 posts views Thread by datactrl | last post: by
8 posts views Thread by Franck | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.