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
