This document assumes migration from DLXS 11/11a to DLXS 12. Migration from 10 to 12 should be possible, just be sure to read the Migration to DLXS 11 documentation. Migration from an even earlier version requires review of the documentation that was packaged with the software.

Summary of Middleware Changes That Affect Data Preparation

Read the DLXS, Getting Started documentation, and this document, completely, before proceeding.

Media Table Required for MySQL Collections

Image Class now requires that each collection have a media table. Previously the media table was optional. Data preparation is considerably easier with DLXS 12, making it more reasonable to require a media table.

Character Encoding

DLXS 12 expects all data to be Unicode UTF8 encoded. The user interface will fail (assertion errors) if the XSLT engine used by the middleware encounters non-UTF8 characters.

If all data is ASCII or UTF8, DLXS 12 Image Class middleware is compatible with DLXS 11 Image Class data.

DLXS 11 Image Class middleware is compatible with DLXS 12 Image Class data. UTF8 data not translatable to ASCII or latin1 will not behave properly.

Data preparation/loading scripts expect UTF8.

Existing MySQL tables can be converted to UTF8 as long as the charactset of the data is known. See MySQL "alter table" documentaion for more information. Tables containing strictly ASCII need not be converted. Please read the DLXS Unicode documentation for more information.

Searching "Anywhere in Record"

ic_all is now the lone preferred field mapping for searching "Anywhere in Record". The collection specific counterpart, in the form collid_all, is only necessary for backward compatibility of bookmarked search results pages. Here is the recommended usage of ic_all:

First of all, do not change the configuration of legacy MySQL collections that do not already have an ic_all field in the data table unless you are prepared to reload the collection's data.

Otherwise...

• In the Collmgr field field_admin_maps (not field_xcoll_maps!) map ic_all to the collection specific fields to be searched when the user chooses "Anywhere in Record." This causes an ic_all field to be created in the data table as a concatenation of the collection specific fields plus the collid. This happens when the data is loaded.
• Include a label for ic_all in CollMgr field field_labels.
• Use ic_all, not collid_all, in Collmgr field dfltsrchflds.
• If backward compatibility for bookmarked results page urls is desired, map collid_all to ic_all in the CollMgr field field_xcoll_maps.

Sorting on Cross Collection Fields

Only the first field mapped to a cross collection field is used for sorting.

User Interface Migration

DLXS 12 introduces a complete change to the way the user interface is handled. The middleware prepares XML and applies XSL to it in order to generate XHTML. HTML template files (.tpl) are gone, and the Image Class middleware is not backward compatible with existing HTML templates. Class, group, and collection specific interface customizations previously done in the Perl code, or HTML templates must be revisited and likely redone completely.

The good news is that the XML/XSLT combination is extremely versatile and powerful. All Image Class interface functionality has been maintained if not enhanced. And the vast majority of interface customizations that previously required Perl code modifications can now be done with XSLT. This is true of Image Class, Text Class, and FindAid Class.

If your previous use of Image Class did not include template based interface customizations, no special action is required.

Migration of template based interface customizations requires analysis and scrutiny of previous changes and reapplication in XSLT. In general, customizations are much easier in XSLT once basic familiarity with the new implmentation is attained.

See DLXS User Interface documentation for details.