General topics: how to include original names of linked files

<< Click here to display Table of Contents >> Navigation: Axiell Designer > General topics:

How to include original names of linked files

Contents

By default, when you upload a media file in an image or application field (often labeled Reference), the greyed out text <<New>> will appear in the field. At this point, the uploaded file only exists in a temporary holding area. Now, only when you save the record will the uploaded file actually be processed further: only then will the file either be copied from the original location to the file system (often the \images sub folder of your Collections system) or written to an optional Digital Asset Management System (DAMS), depending on the file storage system used by your application, at which point a new, unique file name will be generated and stored in the record to prevent it from accidentally overwriting any earlier linked files with the same name. By default, Collections will generate a GUID (Globally Unique Identifier) file name first, under which name the file will be stored in either the file system or a DAMS: in the case of the file system this initial GUID file name will become visible in the Reference field, while in the case of a DAMS, the DAMS may generate its own GUID (which is also associated with the stored file) and returns it to Collections after which that second GUID file name will be stored in the field in the media record. So by default, the name of the uploaded (copied) file will be changed and the record will link to that the file with that new name, the original file name being lost for Collections.

However, this GUID file name is not based on the original file name and sometimes you would like to register the original file name in the media record (too), because the name contains an indication of what the image portrays or because you’d like to be able to search on the file name. Axiell Collections can indeed automatically register the original file name in the media record if you make the proper settings. You have the choice between: 1. only registering the original file name (instead of the GUID file name), although this option may not be supported by your DAMS, and 2. also registering the original file name in a second field next to the GUID file name.

Option 1: only register the original file name, if possible

The default behaviour as described in the top paragraph of this topic applies when in the Collections settings.xml the <SessionManager><UseOriginalMediaFileName> setting is missing, hasn't been set or is set to false. However, from Collections 1.7.19350.2 you can set this option to true to store an uploaded file under its original name in image or application fields. Then, uploading a file will still initially put the text <<new>> in the field, but upon storage of the record, Collections will store the file under its original name, either in the file system or in a DAMS. If the DAMS returns a GUID file name (which will also be associated with the stored file), it'll be that name that will be saved in the Reference field. The file system however, will generate no GUID so the original file name will also be stored in the Reference field. If the file name of the uploaded file does already exist in the target location, that won't be a problem for a DAMS but the file system will return a warning saying A media item with the id ... already exists, after which the record is not saved, but left in edit mode. In the latter case the user will have to rename the file in Windows Explorer before they can try to upload it again in the Reference field in Collections - the user may have to empty the field first if it still contains <<new>>.

Option 2: besides the link to a new GUID file name, register the original file name too

If you don't mind that the copied file will be renamed and that the link is made to that newly named file as long as the original file name will be stored in the media record too in a different, non-linked field so the user can search on it if needed, you’ll have to configure your Collections application accordingly first if your application version is older than model application 4.5.2: versions 4.5.2 and up already have this functionality implemented. However, 5.0a and newer have a different implementation than 4.5.2 up to and including 5.0. The older implementation still works but has been overtaken by a newer (functional from Collection 1.11), more efficient implementation which is now the recommended one. Proceed as follows to implement this yourself for the image reference field in object and media records (using a recent version of Designer) in an application older than 4.5.2, using the recommended method:

In both the Collect and Media database table structures (.inf's), define a flat (meaning non-linked), text field of sufficient length to contain each conceivable file name. In Collect, the new field should be repeatable and be part of the same field group as the linked image reference field (which usually has tag FN). The fields should be writable, so don’t make them read-only here. In model 5.0a, the field definition is as follows:

OriginalFileNameField

2.	If you’d like the new fields to be visible on screens as well, then place them there (near the FN field for example) as repeatable, read-only fields (so that users won’t change the value them-selves).

In collect.inf, on the Linked field mapping properties tab of the linked image reference field (usually tag FN) add a field mapping from the new field in media.inf to the new field in collect.inf in the Copy fields from linked record mapping and create the reverse mapping in the Write fields to linked record mapping. This way, Collections can write the original file name to a newly created media record or retrieve it if you choose to display the field on the Reproductions screen of object records.

Since Collections doesn’t know which tags you have used for your new original file name fields, you must make some settings. Simply look up the image field definition (usually for tag FN) in collect.inf and media.inf and set the Original filename tag property on the Image properties tab to the new field for the original file name: original_file_name (tag ob) for example.

DSMediaTypeTagProperty

5.	You can repeat the above steps for other image and/or application fields of course.

Now check the Collections settings.xml for conflicting settings. This file should NOT contain the <UseOriginalMediaFileName>true</UseOriginalMediaFileName> setting (although it will be ignored by Collections once you set the Original filename tag, but still...). The file should also NOT contain settings like:

<Field Tag ="FN">

</Field>

as such settings pertain to the old implementation. (They will still work if you don't use the Original filename tag property for fields, but when you use the recommended new property, then use if for all fields that were previously configured in settings.xml for this purpose and then remove the section from settings.xml, although the field properties will take precedence over the relevant settings.xml section if you left it there accidentally).

The now deprecated 4.5.2 - 5.0 implementation for option 2

For reference only, we include here the required full settings.xml sections for 4.5.2 and 5.0 model applications (which still also require the relevant fields to be defined in the .inf's and on screens, but without the Original filename tag setting).

- Required original file name section for 4.5.2 settings.xml

When installing a model 4.5.2 Axiell Collections application, the settings.xml file needs to contain the following standard sub section of the <AlmSettings> node. Do change <Application Name="master"> to the actual name of your application, <Application Name="xplus"> for example.

- Required original file name section for 5.0 settings.xml

When installing a model 5.0 Axiell Collections application, the settings.xml file needs to contain the following standard sub section of the <AlmSettings> node. Do change <Application Name="master"> to the actual name of your application, <Application Name="xplus"> for example.