Hide Forgot
Help Desk Ticket Reference: https://na7.salesforce.com/500A0000007ASa2 Workaround: Workaround Exists Workaround Description: Use Java binding with a HashMap instead of using the DomModelCreator: <jb:bean beanId="item" class="java.util.HashMap" createOnElement="response/item"> <jb:value data="response/item/*" /> </jb:bean> Then, use the 'unsafe_expr!default_expr' (${item.personalnummer!"not available"}) syntax inside the Freemarker template. project_key: SOA Let's suppose we have the following input document: <response> <item> <titel>Prof. Dr. med.</titel> <anrede>Herr</anrede> <vorname>Max</vorname> <nachname>Mustermann</nachname> </item> <item> <personalnummer>124545</personalnummer> <titel>Dr.</titel> <anrede>Mr</anrede> <vorname>John</vorname> <nachname>Doe</nachname> </item> </response> processed by a DomModelCreator on the 'item' element, and then passed to a Freemarker template. Inside the freemarker template the ${item.xxx} syntax is used. This fails for the 'personalnummer' element here, as it is missing on the first record. Using ${item.personalnummer!"not available"}, as shown in the Freemarker docs [1], fails with the following error: Caused by: freemarker.core.NonStringException: Error on line 2, column 3 in personFrag.ftl Expecting a string, date or number here, Expression item.anrede is instead a freemarker.ext.dom.NodeListModel [1] http://freemarker.org/docs/dgui_template_exp.html#dgui_template_exp_missing_default
I think there actually is a solution to this within FreeMarker, but it's a bit ugly. Read this... http://freemarker.org/docs/xgui_imperative_learn.html Anyway.. the freemarker syntax for nodemodel would be something like... ${item.personalnummer[0]!"not available"} Note the [0]
Candiate, not commited. Can we deal with it in Smooks? Or if it requires an update to freemarker, then we need to punt. Tom C to investigate
This can not be fixed within Smooks. It's a FreeMarker issue. There is a workaround however (see comment above).
Ooops... sorry... shouldn't have closed that
No ESB change or Freemarker change required here, the resolution should be to follow the steps outlined by Tom F and the workaround.
No change, no verification needed.