Hi Piotr,
The first thing to do is to get a basic understanding of XML. Don't go rushing
to buy big books on the subject, for what you need directly out from DP to
starting doing useful things is very easy. There is a good tutorial at
http://www.w3schools.com/xml/default.asp an even more basic follow the example
below
Basically DP is very useful for producing XML files, as the structure of
reports in DP makes it easy and flexible. Combining the two aspects, easy and
flexible, DP is probably one of the best databases around for producing XML.
Some databases maybe be easier, but lack flexibility, some maybe more flexible
but are more difficult to use.
As a quick example try this.
a.. Create a report in a DP application, and direct its output to a file with
the file extension XML.
b.. In the DP report's First Page Header enter this text <?xml
"version=1.0"?>
a.. this is called the XML declaration. You can also declare the encoding
but for now do not worry
b.. tags in the form <? ?> are called processing instructions are for the
benefit of the technology processing the file and are not themselves XML data
c.. In a new line under the XML declaration enter this text <myroot>
a.. this is the opening tag for the root element of the document. A
document can only have one root element
d.. Go the the reports Final Footer and enter this text </myroot>
a.. this is the closing tag for the root element. of the document. Every
element must have an opening and closing tag (except noted below) in the form <
>... </ >. Each tag must be closed in exacly the same reverse order to that it
was opened.
b.. An empty element is of the form < /> if you think about HTML the
<br> doesn't have a closing tag but this would be illegal in XML, so to make an
HTML document XHTML compliant the <br> tag would be written <br /> The space
before the slash is a workaround for older browers which do not like <br/>
without a space, but in just XML either is ok
e.. Depending on what your panel is about, at the start of the Report Body
enter an opening tag named to reflect the I will use a fictious Customer panel.
so I would enter the opening tag as <customer>
f.. So that I get the order of the opening and closing tags right I would
enter a new line under the opening tag and put in my closing tag </customer>
a.. XML element names (tags) are case sensitive so <customer> <Customer>
would produce an error and the file would not work in an XML application
g.. Open up a new line in between the opening and closing tags you just
entered.
h.. In the new line enter an opening and closing tag to represent some data
from your application, eg <company> </company>
i.. Place the cursor in between the opening and closing tag and with the F4
key select a field from the panel.
a.. Your first problem may occur here, but I will come back to that soon,
but suffice to say that if the data in the field you select contains an
ampersand & or a couple of other special XML characters you will get an error
in an application that uses this file. For this exercise pick a field which is
less likely to give you problems
j.. After the company element open a new line and similar enter another
element and data. Its is a simple pattern <company>blah
blah</company><address>blah blah</address> etc etc
k.. Repeat this step for each piece of data that you want.
l.. Run the Report
m.. Open the resultant XML file in Internet Explorer, Firefox or your
favourite browser.
n.. XML usually ignores whitespace so do not worry if your tags have newlines
before after or inside of them
If everything went ok, then the file will open, and you should see plus or
minus symbols on the left of your elements containing other elements which you
can click to either open up or close (fold) the elements. If you have an error
the browser should give you a warning.
Ok back to the issue of special characters, which are the " (double quote) the
< (less than) and & ampersand symbols. Because these have special meaning in
XML (called an entity) they needed to be converted. Fortunately Lew made this
change so the DP does the conversion for you. However it only curiously works
on Alphanumeric fields, so you have to fool DP into think you are working with
an alphanumeric field.
a.. For any field that has the potential to contain a special XML characters,
store the value into a Report Variable, (I usually do that immediately before
the element I am using if for.
b.. In the example above where the customer data might contain characters
like an & you would go back and store the company name in say RV1
c.. Delete the DP field between the <company> and </company> and in its place
output the Report Variable RV1, giving it the format A0A0;;W
a.. This is a very important aspect, the A0A0 means that DP thinks you are
working with an alphanumeric field, and so allows you to use the output format
;;W which converts the special characters into the entity descriptors,
b.. eg an & becomes & the < become < the " becomes "
c.. in fact all entities have the format ampersand something semicolon and
they never contain spaces
d.. There is another way to handle data like this, and that is to use what is
called a CDATA section. to wrap up the data. we could have left the original
field and entered the text so the elemet would have looked like
<company><![CDATA[ DPfield ]]></company>
a.. the CDATA starts with <![CDATA[ (less than exclamation open square
bracket CDATA open square bracket) then the data and the closed with ]]>
b.. CDATA sections are more often used when there is lots of text with lots
of special characters. A reall good example is say if you had a DP alphanumeric
field which contained either web pages or snippets of HTML. For example a
product catablog, might have snippets of HTML to represent graphic images, or
links to a manufacturers webpage or other unstructured HTML data, and these are
certainly better handled with a CDATA Section. But generally the previous
method of handling fields which may contain a special XML character is better.
Sometimes the CDATA section can just not be used at all as it would not be well
formed.
>From where you are now you could easily create a simple XML document using DP
>that could be used with Word 2003 or later to create a simple merge using the
>XSLT Inference Tool and the notes that I liked to.
Just some additional points to help you along your way.
a.. XML Elements can contain text, other XML elements, or mixed content with
both text data and other XML elements.
b.. So far I have only talked about simple element data. you can also have
attributes to elements, similar to HTML attributes. you might have had
<customer><name>Bloggs & Co</name>....... </customer> but you could have
also used the name as a attribute of the customer element as in <customer
name="Bloggs & Co">....</customer> but this type of data is not so easy to
use with Word.
c.. You should plan the look of your XML data, so that you have a design
pattern. In the early stages you can probably do this on the fly but as you XML
gets more complex then it needs to have a thought out structure.
d.. You can create DP Subreports to get data from child panels. Just remember
three things.
1.. You must be careful about the opening and closing and nesting of tags.
2.. you add an additional level of complexity to the Word merge, and the
documentation from Microsoft has a couple of inaccuracies which will have you
(erroneously) thinking that Word doesn't work with this type of document,
3.. you will need to understand the concept of XML Schemas, which are
special files which describe the structure on an XML document, they generally
have an XSD file extension. When you get to this stage you will probably need
to acquire an XML editor so that it can do the dirty work of creating an XSD
based on an example file. Personally I have not ever written a Schema from
scratch, however I often write a DTD which is much easier but less powerful,
and use XML editor software to create a Schema from it. Schemas are a powerful
thing, but for document automation with Word you only need a simple Schema.
4.. Incidentally en exporting Microsoft Access tables or queries to XML it
(optionally) creates a Schema file for you. However that Schema file does not
work when trying to do document automation with Word 2003 and the WML2XSLT.EXE
Transformation Inference Tool, otherwise Access might be a lot easier to use
than it is, but certainly no where near as flexible as DP.
e.. You can comment your work very easily. For complex XML (I have one DP web
report which is made up of 42 subreports) to enter a comment enter <!-- This is
a comment --> (ie less than exclamation hyphen hyphen comment hyphen hyphen
greater than) Comments are ignored in XML processors so they are just for your
own benefit, esepcially in complex reports they are a god send
f.. I tend to do the XSLT processing in another application other than Word.
By this I mean I design the document in Word (or generally ask my client to
create a smaple of the document as an example with all the formating, graphics
etc that they want, then I add my XML markup and then save it as XML as a Seed
Document. I do not use Word to later generate my documents, but instead prefer
to use something lik xsltproc (open source)
http://www.zlatkovic.com/pub/libxml/libxslt-1.1.23+.win32.zip save to disk open
and read the readme.txt for install instructions and then look at
http://xmlsoft.org/XSLT/xsltproc2.html for instructions on how to use it.
g.. When I am creating Word Documents you can give the output name a normal
.DOC extension and Word know how to handle it. But usually I give it a .DOT as
Word opens it like a new document and give the user the options of where they
want to save it and it defautls to the more usual Word .DOC or whatever is the
users default format.
Good luck, I hope this gets you started. By the way, I might post up an DP
XML/XSLT application that I use for documenting DP applications. It shows the
richness of what you can simply do with DP and XSLT
Regards
Brian
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
