EZ xslt
Easy XSLT Stylesheet builder for FileMaker Pro Users

 

Back to Frequently Asked Questions

Why use XML instead of Mail Merge?

Great question!

There are several benefits for using XML over mail merge macros, especially in workgroup settings:

  1. Reduced deployment & support costs.
  2. Easy customer-level modifications, with control.
  3. Wider scope of application.
  4. Easier and faster development cycle.
  5. Results open in any rtf-aware application

 

1. Reduced deployment & support costs

With most mail merge setups, there is some embedded VBA code in each Word template or in a general template, macros must be enabled, and if you want to reduce deployment issues and make it look professional you really need a digital signature certificate for your VBA code. There is either a multiple-step process or a fragile automatic setup that may break fairly easily. Managing the export file becomes an issue, or ODBC has to be used to avoid an export file. For infrequently used reports that can be generated by a trained person, this is OK, but for a work group the support effort seems much higher than it "should" be, both for the initial deployment installation and for general ongoing support.

With XML there are no Word Templates that have to be visible on the network on mounted servers or locally. There is no need to enable Macros. There is no need to setup an ODBC connection or worry about where the export file is located in order to then invoke the import, and there is no need for a digital certificate. There is no left-over export file that should be deleted or that may be confused in a subsequent export, and no local Word template file that has to be kept in sync with other users. New Stylesheets may be hosted on an http server and updated instantly for an entire work group without changing a line of code, and the result of the export function is not an export file but rather a word processing document.

 

2. Easy customer-level modifications, with control

For documents that fit the EZxslt model, an end-user may create updated stylesheets using the same export data without requiring any change in Scripting. All they do is update their Word Stylesheet Template and drag & drop. To install, they put it on the http server that is used. Very simple.

Unless someone has access to the web server to post an updated form, they can't modify the XSLT template and therefore the core template code remains consistent.

 

3. Wider scope of application

With Mail Merge, I've found typically only one or two people in a work group will bother to learn how to use the setup, and it is only used for infrequent, if important, tasks. For example, I've never been able to convince a client to set up their standard ad-hoc letters and memos to merge from FMP unless they also want to store the documents in FMP in which case Word is not used at all, and they put up with the funcky page break and other issues.

With XML, it is now possible, and clients seem interested in, using FMP as their work group rolodex, and quickly generating various new Word documents directly with simple information such as name & address pre-populated. This is a real time-saver and much simpler in many cases than opening a Word template, going to FMP, finding the record, copying the name/addres, and then pasting into Word.

 

4. Easier and faster development cycle.

There are nearly no environmental issues that get in the way. No macros or vba coding. No pathing issues to resolve. I can set up many more documents more quickly using XML/XSLT than using Mail Merge. In fact, now I'm looking at setting up many documents at once rather than just one or two.

 

5. Results open in any rtf-aware application

You don't need MS Word to consume the results of a FMP->RTF conversion. If you choose to deploy Star Office or any other RTF-aware word or text processor, the RTF generated via XSLT should be openable. RTF Reader, TextEdit and other programs will work.