Home Forums General XMetaL Discussion XMetaL 9 tab customizations Reply To: XMetaL 9 tab customizations

Derek Read

Reply to: XMetaL 9 tab customizations

There are no plans at this time to alter the behaviour but let me try to explain the reasoning behind that.

The software displays the full file name (now) in order to provide you all the information you might need to identify it. If a file name is in a non-human-readable form, or mostly in a non-human-readable form (in your case containing a GUID) there is no way for XMetaL Author to know what portion of the file name to display (the start, the end, the middle, something else). Though the old logic may have been good enough for your needs it does cause issues for other clients as file naming conventions vary widely. There is no logical way for our software to guess what portion of a long file name will be meaningful to a particular person.

In your case, because you have no control over the file naming convention used by SDL, you cannot give shorter meaningful names to your files. That would be the general recommendation for anyone not using a CMS, or where the CMS allows you to name the file.

Any partner (including SDL) can alter their connector's behaviour so that what is displayed as the text for a tab in our UI meets your specific requirements, or specific requirements that make sense for all users of that particular CMS system. The text displayed could be anything. It might be the first few characters of the file name, the last few characters, some other subset like the first 10 letters after the last digit, or something else entirely — including a portion of the XML markup itself (like a title element or attribute value).

The one API required to do this is ActiveDocument.Title though you may need to use others to build the string itself.

Here are some examples. Keep in mind that these are not real-world examples and almost certainly should not be used as written. They merely show what might be possible.

[code=Simple Example with Hard Coded Value]//XMetaL Script Language JScript:
var strDocTitle = “testing”;
ActiveDocument.Title = strDocTitle;[/code]

SDL should be able to integrate something like this into their solution:
[code=Example that Builds String from First Character Up to First Equals Sign in File Name]
//XMetaL Script Language JScript:
var strDocTitle = ActiveDocument.Name.substr(0,ActiveDocument.Name.indexOf(“=”));
ActiveDocument.Title = strDocTitle;

[code=Example that Builds String from First 10 Characters of File Name]//XMetaL Script Language JScript:
var strDocTitle = ActiveDocument.Name.substr(0,10);
ActiveDocument.Title = strDocTitle;[/code]

[code=Example that Builds String From Last 10 Characters of File Name]//XMetaL Script Language JScript:
var strDocTitle = ActiveDocument.Name.substr(ActiveDocument.Name.length-10,10);
ActiveDocument.Title = strDocTitle;[/code]

[code=Example that Builds String from Text in First “title” Element Found in Document]// XMetaL Script Language JScript:
var rng = ActiveDocument.Range;
var strDocTitle = rng.Text;
ActiveDocument.Title = strDocTitle;[/code]

The final code that is decided upon should be run as soon as possible after opening a document (so that the user sees it) but obviously after the document has been fully opened so that the Document object is available (used in these examples as ActiveDocument). The particular event used may need to be different depending on what the CMS integration is doing in their other code.

None of the scripts above check to see what it is doing is safe. At minimum it probably should confirm that the document is open in Tags On or Normal view as most of the APIs used here will not function in other views.

ActiveDocument.Title is merely the string displayed in the tab only and does not affect anything else in the system (the real file name or anything else).

Depending on the capabilities of the CMS system it might also be possible to pass an additional meaningful string in from the CMS itself (perhaps some metadata stored about the file. How difficult that would be I cannot say but I think it is a possibility in most cases.

Anyone using a CMS system that requires this type of feature should contact the vendor that provides the connector for that CMS. Clients not using a CMS will probably not need this feature but they can still use this API in any Application-level or Document-level customization of their own making.