This document assumes migration from DLXS 11/11a to DLXS 12/12a. 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.
Read the DLXS, Getting Started documentation, and this document, completely, before proceeding.
Image Class requires, as of release 12, that each collection have a media table. Previously the media table was optional. Data preparation is considerably easier with DLXS 12/12a, making it more reasonable to require a media table.
DLXS 12/12a 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/12a Image Class middleware is compatible with DLXS 11 Image Class data.
DLXS 11 Image Class middleware is compatible with DLXS 12/12a 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.
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.
Only the first field mapped to a cross collection field is used for sorting.
DLXS 12/12a 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.