Mail Merge Specification: Technological Req'mts

WORK IN PROGRESS

THIS PAGE IS WORK IN PROGRESS!

NOTE: Please refer to the Terminology for the exact definition of words and phrases!

Selection of Technology

Investigations into technologies that will be needed for supporting the key features of the implementation of Mail Merge in OpenPetra are to be undertaken.

Technology: Definition

With the term 'technology' we mean in this specific context a solution for the implementation of Mail Merge in OpenPetra which provides the Key Features of the Mail Merge implementation (perhaps minus the creation of the Mail Merge Data Set).

Technologies could be made up of...

• a single product that provides the solution
  • Example: word processor that can be automatically 'driven' by OpenPetra through some means to fulfil the requirements and that is capable of replacing Placeholders with data from the Mail Merge Data Set
• multiple products that work together to create the solution
  • Example: a WYSIWYG editor that can be used for the *creation and parameterisation of the Mail Merge Document* that is capable of saving the document in a way that can be read by a library that is capable of *producing the Merged Documents for the individual recipients out of the underlying Mail Merge Data Set*, perhaps with the help of OpenPetra-specific plug-ins that provide the *customisable control logic for the creation of the Mail Merge Data Set*.

A technology that will be suitable for the implementation of Mail Merge in OpenPetra will need provide features that make it possible to meet the required outcome.

Key Features

The key features that the technologies will need to provide are:

• the creation of the Mail Merge Document;
• the parametrisation of the Mail Merge Document through Placeholders and perhaps other means;
• the production of the Merged Documents for the individual recipients out of the underlying Mail Merge Data Set;
• support for all the output options by some means that should (preferably) be fully automatic.

Optional Features

The technologies could optionally also provide:

• Customisable control logic for the creation of the Mail Merge Data Set
  • the customisable control logic could be programmed either
    • in a programming or definition language that the technology supports and that will be capable of working with data that is passed either in memory (e.g. using a .NET-serialized ADO.NET DataSet) or some temporary file.
      • that is so that the OpenPetra DB doesn't need to be queried directly from that technology as we want to have the capabilities of OpenPetra's powerful RDBMS Abstraction Layer retained! (OpenPetra would get the required data out of the RDBMS and pass it on to the technology in a suitable format.)
    • with the help of OpenPetra-specific plug-ins, preferably written in C#.
• other supporting means for the creation of the Mail Merge Data Set

Likely Candidates for Technologies That Should be Investigated

• Microsoft.Office.Interop.Word
  • .NET Interop Wrapper libraries supplied by MS for MS Word Automation through COM
• Possibly: standalone native .NET implementation for support of the MS Word Format (doc/docx).
  • Requirement: Open Source licence, or at least Freeware
• AODL .NET Library
  • standalone native .NET implementation for support of the OpenOffice/LibreOffice OpenDocument Format.
• Possibly: different standalone native .NET implementation for support of the OpenOffice/LibreOffice OpenDocument Format.
• Possibly: standalone WYSIWYG Editor that allows use of Placeholders
  • Requirement: Open Source licence, or at least Freeware
• Possibly: standalone native .NET libraries that allow replacement of Placeholders in Mail Merge Documents with data from a Mail Merge Data Set.
  • Requirement: Open Source licence, or at least Freeware
• Possibly: standalone software (not a word processor) that is purpose-written for performing Mail Merge and that is capable of meeting the Key Points
  • Requirement: Open Source licence, or at least Freeware
• TODO (to be extended by MarkP if he finds some other likely candidate)

Base Technologies that Should be Avoided

• Anything that requires Java to be installed on either Client or Server.
  • Reason: We use solely .NET for OpenPetra and don't want to introduce a dependency on a different technology platform.