This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
When creating an XML file using DataObject.createFromTemplate(), the "encoding" FreeMarker variable is always UTF-8. This happens because of the Charset targetEnc = FileEncodingQuery.getEncoding(output); call in ScriptingCreateFromTemplateHandler, which always returns a charset for XML files (see XmlFileEncodingQueryImpl in xml.core). The name of this charset is always UTF-8, and SCFTH uses it as the value of the "encoding" variable. This effectively prevents the use of the variable in the template as a means to set the encoding of the created XML file. SCFTH cannot reliably use the name of the charset. Yarda suggested to make available a "project.encoding" variable through CreateFromTemplateAttributesProvider. This name has a slight mismatch with the freeform project, where the encoding is source-folder specific. But since everyone thinks in terms of a per-project encoding, I will keep this name.
So what is the proposed new behavior in case FileEncodingQuery.getEncoding(output).getName() is different from ${project.encoding}? Is it up to the template to decide which to use?
Yes, it is up to the template. It is not nice that we would have two encoding variables, and the template authors will need to understand the difference between them. Moreover, ${encoding} is not reliable for some file types (at least XML, but probably also JSP), and this won't be clear to authors either. My initial idea was to use the encoding of the new file's parent folder as the value of ${encoding}. That would be simple to document and understand, but OTOH the notion of the encoding of a folder is not well defined. Since Charset.name() is almost never reliable when the Charset was retrieved through FEQ (it will almost always -- or always? -- be a ProxyCharset), perhaps another alternative would be to define a way to detect that the charset is a delegating one (like ProxyCharset or the XMLCharset returned by XmlFileEncodingQueryImpl). When computing ${encoding}, we would delegate to the project encoding when the charset is delegating.
Btw. Charset.displayName() or Charset.displayName(null) may delegate properly.
The Javadoc of Charset.displayName() says "concrete subclasses of this class may override this method in order to provide a localized display name.", so it doesn't look reliable either.
Created attachment 58849 [details] Proposed change
Created attachment 58850 [details] Changes in apisupport and freeform project types
Attached the API change which introduces the project.encoding variable, as well as the necessary changes in apisupport and freeform to provide this variable. The similar changes in the Java SE and EE project types are covered by issue 129775. Please review. Since the code freeze is close, I want to shorten the review a bit and commit March 25.
apichanges.xml <summary> looks wrong.
Created attachment 58895 [details] Proposed change (update 1)
Thanks, fixed.
besides 129454, are there any other user scenarios related to other project or file types or templates, that this issue or the ones listed in depends on -- fixes ? or are there other project/file/template types that have similar kind of problem that are not fixed by these ? (we can file separate issues if needed) ken.frank@sun.com
No, I don't know of any.
Unless there are any more comments I will commit later today.
Y01 The provider of project.encoding shall not be in templates module, as that module is completely independent from projects. There is another provider in projectui or projectuiapi or elsewhere that shall imho be used to provide this property.
Created attachment 59015 [details] Proposed change (update 2)
Re Y01: agreed. I moved the API change to projectuiapi. The patch needs to be applied on top of the one in issue 130881. Commit target date is March 26.
0cef353a7e2d b4020517e1fe