[MNT-477] Cannot retrieve cm:title from an avm node in freemarker (if persisted with actual type as MLText) Created: 11-Jan-10  Updated: 31-Aug-16  Resolved: 12-Apr-10

Status: Closed
Project: Service Packs and Hot Fixes
Component/s: ZZ_Archive
Affects Version/s: 3.1.2
Fix Version/s: 3.2.1

Type: Service Pack Request
Reporter: John Jaquette [X] (Inactive) Assignee: Closed Bugs (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive testing.zip    
Issue Links:
Related
relates to MNT-3927 Impossibility to upload file if Descr... Closed
Bug Priority:
Category 2
ACT Numbers:

15268, 16063


 Description   

Using this webscript:

*********
testGetTitle();

function testGetTitle()

{ var uniquePath = args.uniquePath; model.avmNode = avm.lookupNode(uniquePath); }

**

<testing>
<name>${avmNode.properties["cm:name"]}</name>
<title>${avmNode.properties["cm:title"]}</title>
</testing>
***********

You will get this error:

500 Internal Error An error inside the HTTP server which prevented it from fulfilling the request. Wrapped Exception (with status template): Error during processing of the template 'Error on line 4, column 14 in foo/testing/foo.title.get.xml.ftl Expecting a string, date or number here, Expression avmNode.properties["cm:title"] is instead a freemarker.template.SimpleHash'. Please contact your system administrator. org.alfresco.web.scripts.WebScriptException - Wrapped Exception (with status template): Error during processing of the template 'Error on line 4, column 14 in foo/testing/foo.title.get.xml.ftl Expecting a string, date or number here, Expression avmNode.properties["cm:title"] is instead a freemarker.template.SimpleHash'. Please contact your system administrator.

All works well if you remove the title reference and there is indeed a title property on this node.

This can be worked around by getting the title in the jscript first:

*************
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<testing>
<name>${name}</name>
<title>${title}</title>
</testing>

**
testGetTitle();
function testGetTitle()

{ logger.log("path: " + args.uniquePath); var node = avm.lookupNode(args.uniquePath); logger.log("node name: " + node.name); logger.log("node title: " + node.properties.title); model.name = node.name; model.title = node.properties.title; }

************



 Comments   
Comment by Scott Ashcraft [ 12-Feb-10 ]

Bumping the priority. Customer (ACT 16063) would rather not resort to using javascript in his webscripts to accomplish this.

Comment by Scott Ashcraft [ 16-Feb-10 ]

More comments from the customer in ACT 16063:

=====
This has extensive cross-cutting implications for virtually all aspects of our portal, involving changes to all of our freemarker templates. Moving forward, it seems to me we would need some kind of conversion utility to get the strings from node.properties.title and store these as hashed values in the localized cm:title hash under "en_US," along with an update to our freemarker templates to access the hashed and localized avmNode.properties["cm:title", "cm:locale"] (I'm guessing at the syntax).

=====
Changing the FreeMarker templates to deal with a dictionary-based object is not that difficult. The main problems are:

1) the JavaScript API and the FreeMarker API are inconsistent. The JavaScript API still returns a string as we expect in our code; however, the FreeMarker API is now returning a dictionary object (key is the locale).

2) The FreeMarker API currently does not provide a way to access the legacy string value (I refer to that as the default locale). The JIRA Scott mentioned describes using a work around whereby the JavaScript builds a separate model just for titles and descriptions. I would rather seek out a fix from Alfresco than add hack code to our web scripts and potentially impact performance.

My hope would be for Alfresco to create a separate property for internationalized values or to create a method where the locale(s) (the browser can specify multiple locales) are passed in. The method might return the value for the top matching locale if it exists, otherwise return the default locale value. This would maintain backwards compatibility and keep the API simple for customers that do not use i18n.

Comment by Dave Ward [X] (Inactive) [ 18-Mar-10 ]

This is something to do with accessing MLText properties through TemplateNode. Please investigate.

Comment by Steve Rigby [X] (Inactive) [ 31-Mar-10 ]

For retest in 3.2 sp1 b486

Comment by Steve Rigby [X] (Inactive) [ 13-Apr-10 ]

For retest in 3.2 sp1 b495

Comment by Alfresco QA Team (Inactive) [ 17-Apr-10 ]

Successfully validated in Alfresco 3.2.1 EE b 495 using Windows 2008 SP1 x64, Tomcat 6.0.18, Mysql 5.1.34, JDK 6u16 x64.

Comment by Derek Hulley [X] (Inactive) [ 31-Aug-16 ]

The component originally used was not a supported, recognisable system component with an associated component owner. Either the component never existed (it was fictional) or it has reached end-of-life.
The issues will be closed. Reopen and assign to an existing system component if necessary. Use labels appropriately.

Generated at Fri Apr 23 11:19:04 BST 2021 using Jira 7.13.15#713015-sha1:7c5ddd2c3e1709974ae9c48c17df8edd3919fe2c.