[ 
https://issues.apache.org/jira/browse/FREEMARKER-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15738305#comment-15738305
 ] 

Daniel Dekany commented on FREEMARKER-41:
-----------------------------------------

A quick googling has revealed this from xalan-dev, 
http://marc.info/?l=xalan-dev&m=119617593514050:

{quote}
The DOM Element node named "root" in this case has three DOM Text nodes. 
However, the XPath data model does not permit two text nodes in a tree to be 
adjacent - the XPath data model views those three DOM Text nodes as a 
single XPath text node.

The XPathAPI class returns nodes from the original DOM tree that 
correspond to the nodes selected from the XPath data model instance.  If 
the node to be returned is an XPath text node that represents multiple 
adjacent DOM Text nodes, only the first such DOM Text node will be 
returned.
{quote}

So I guess in the case of Xalan it's practically safe to assume that XPath 
queries will only ever return the first of adjacent text nodes, which means 
that it's safe to unite them with the following sibling text nodes. It remains 
to be seen if there are some implementation gotchas though...

> XPathSupport executeQuery doesn't handle text() in models that isn't 
> normalized
> -------------------------------------------------------------------------------
>
>                 Key: FREEMARKER-41
>                 URL: https://issues.apache.org/jira/browse/FREEMARKER-41
>             Project: Apache Freemarker
>          Issue Type: Bug
>          Components: engine
>    Affects Versions: 2.3.25-incubating
>            Reporter: Per Olsson
>
> XPath expressions that contains text() doesn't evaluate to the correct value 
> when the model isn't normalized and includes multiple text nodes. This will 
> happen when the xml-parser creates multiple text nodes due to performance or 
> memory reasons and is a fully normal behaviour.
> The solution in the function executeQuery with the NodeIterator (files: 
> freemarker/ext/dom/SunInternalXalanXPathSupport.java and 
> freemarker/ext/dom/XalanXPathSupport.java) doesn't handle adjacent(siblings) 
> textnodes. The problem probably also exists for CDATA nodes. I don't know if 
> the jaxen solution behaves in the same manner. 
> {code:title=...XPathSupport.java|borderStyle=solid} 
> synchronized public TemplateModel executeQuery(Object context, String 
> xpathQuery) throws TemplateModelException {
>   ...
>   NodeIterator nodeIterator = xresult.nodeset();
>   Node n;
>   do {
>       n = nodeIterator.nextNode();
>       if (n != null) {
>           result.add(n);
>       }
>   } while (n != null);
>   ...
> {code}
> Sample code to reproduce
> {code:title=Reproduce.java|borderStyle=solid}
>     Configuration cfg = new Configuration(Configuration.VERSION_2_3_25);
>     cfg.setDefaultEncoding("UTF-8");
>     ClassTemplateLoader ctl = new ClassTemplateLoader(App.class, "/");
>     cfg.setTemplateLoader(ctl);
>     // --- sample.ftl ---
>     // <#ftl>
>     // Text:${model["//root/text()"]}
>     // Node:${model["//root"]}
>     Template temp = cfg.getTemplate("sample.ftl");
>     // --- Model --- 
>     // Element:root
>     //     |- TextNode:SA
>     //     |- TextNode:MPLE
>     DocumentBuilderFactory docFactory = DocumentBuilderFactory.newInstance();
>     DocumentBuilder docBuilder = docFactory.newDocumentBuilder();
>     Document doc = docBuilder.newDocument();
>     Element rootElement = doc.createElement("root");
>     doc.appendChild(rootElement);
>     Text text = doc.createTextNode("SA");
>     rootElement.appendChild(text);
>     text = doc.createTextNode("MPLE");
>     rootElement.appendChild(text);
>     Map<String, Object> model = new HashMap<String, Object>();
>     model.put("model", doc);
>     StringWriter sw = new StringWriter();
>     temp.process(model, sw);
>     System.out.println(sw.toString());
>     // --- Actual output ---
>     // Text:SA
>     // Node:SAMPLE
>     // --- Expected output ---
>     // Text:SAMPLE
>     // Node:SAMPLE 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to