CMS_REF used in a non-content-projection page to determine the path of a FirstSpirit record referenced in a table template

Author: king
Publication Date: 9/1/2014 17:11

Dear e-Spirit community,

we currently have the following situation:

(1) a table template allows the selection of a data record via link template ($CMS_INPUT_LINK using a LINKEDITOR named "lt_overlaylink_news") that nests again a "FS_DATASET" input component (named "lt_entity")

(2) in a non-content-projection enabled page, the path of the selected record value of (1) has to be retrieved. Here, the following FirstSpirit template code failed:

$CMS_REF(ssNewsDetail,contentId:content.external_link.lt_entity.getDataset().getEntity().getValue("fs_id"),abs:setAbsolute)$

Interesting is that the following FirstSpirit instruction worked and returned the FirstSpirit ID of the selected data record:

$CMS_VALUE(content.external_link.lt_entity.getDataset().getEntity().getValue("fs_id"))$

In contrast, we tried using it in the following condition:

(1) a page owning a section template (not a table template!) and integrating the same link template (using LINKEDITOR "lt_overlaylink_news") allowing to choose a data record via a "FS_DATASET" named "lt_entity"

Here, the chosen data record value and its path can be retrieved successfully in the link template HTML output channel:

$CMS_REF(ssNewsDetail,contentId:lt_entity.getDataset().getEntity().getValue("fs_id"),abs:setAbsolute)$

Here, "ssNewsDetail" contains the content project page of the underlying project. That's why it works here.

The big question:

- why does the path resolution not work when integrating the data record selection via CMS_INPUT_LINK into a table template. In contrast it works fine when just using a section template. Both cases use the same link template "lt_overlaylink_news".

- does the HTML output channel in the link template prevent the re-usage in another context of another section template?

Hint: even by setting a "#" character prefix for the "content" system object, the problem could not be solved! According to the FirstSpirit documentation this syntax should only be used in FirstSpirit format templates.

Have we found a bug here?

Tags: 5.1, firstspirit, templatedevelopment