Questions & Answers

[king]

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?

[Peter_Jodeleit]

You say the very same template expression is working in one template but not in an other? Your are sure that all parameters are equal? You checked it for the paramter "contentId", but also for "ssNewsDetail"? And if so, are there any messages in the log? Does the error occur in preview or site generation or both?

And please, could you provide the complete FirstSpirit version you are testing.

[king]

Dear Peter,

enclosed the answers to your questions:

- You say the very same template expression is working in one template but not in an other?

  Answer: in the 1st scenario the expression is used in a format template (we also tried with/without "#" for system object "content"), in the 2nd scenario it's used in a link template

- Your are sure that all parameters are equal?

  Answer: yes

- You checked it for the paramter "contentId", but also for "ssNewsDetail"?

  Answer: yes, we even hardcoded the value of "ssNewsDetail", here "pageref:news_detail_page"

- And if so, are there any messages in the log?

  Answer: no, see output below:

INFO  02.09.2014 10:58:33.432 (de.espirit.firstspirit.server.scheduler.GenerateTaskExecutor): generating 'lap_feed_news_bgn_update' (id=5745299), language EN, template set 'html'
INFO  02.09.2014 10:58:33.433 (de.espirit.firstspirit.generate.SiteProduction): creating output stream for /en/_technical/search/feeds_1/lap_feed_news_bgn_UPDATE.xml

- Does the error occur in preview or site generation or both?

  Answer: site generation

Interesting hint, the below expression retrieves the selected data record id (here: "content" system object is used WITHOUT a "#" although the expression is used in a format template):

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

It's strange that the below expression did not return the expected result, based on the upper one:

$CMS_REF(pageref:"news_detail_page",contentId:newsId)$

[Peter_Jodeleit · Accepted solution]

Thank you for clarification.

One detail: Did you also check the type of the variable "newId"? The assignment looks a bit strange. Perhaps you try this code:

$CMS_SET(newId, content.external_link.lt_entity.getDataset().getEntity().getValue("fs_id"))$

[king]

Dear Peter,

interesting is, when using your suggestion, we could retrieve the correct expected result

But shouldn't the other way, we used before, work too? According to the ODFS in "CMS_SET" (see help/odfs/Template-development/Template-syntax/Instructions/CMS_SET/) it might be possible to use:

$CMS_SET$(xxx)$

BODY

$CMS_SET()$

where the BODY might contain any $CMS_...(...)$ expression, e.g. $CMS_IF(...)$,$CMS_REF(...)$, $CMS_SET(...)$ and $CMS_VALUE(...)$

The type of return value you asked for:

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

is "java.lang.Long"

[Peter_Jodeleit]

In most cases the result of the two forms of CMS_SET look similar, but behind the scenes they are quite different. The short form keeps the type of the assigned variable, the long form creates a variable of type "template fragement". It' more like a closure. If you don't need this functionality I recommend using the short form.