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.

Bug 129685 - The "encoding" FreeMarker variable is always UTF-8 for XML files
Summary: The "encoding" FreeMarker variable is always UTF-8 for XML files
Alias: None
Product: platform
Classification: Unclassified
Component: Data Systems (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Andrei Badea
Depends on: 129775 130881
Blocks: 129454
  Show dependency tree
Reported: 2008-03-10 17:52 UTC by Andrei Badea
Modified: 2008-12-22 10:37 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Proposed change (7.29 KB, text/plain)
2008-03-21 15:52 UTC, Andrei Badea
Changes in apisupport and freeform project types (9.57 KB, text/plain)
2008-03-21 15:53 UTC, Andrei Badea
Proposed change (update 1) (7.27 KB, text/plain)
2008-03-23 15:56 UTC, Andrei Badea
Proposed change (update 2) (11.59 KB, text/plain)
2008-03-25 14:05 UTC, Andrei Badea

Note You need to log in before you can comment on or make changes to this bug.
Description Andrei Badea 2008-03-10 17:52:19 UTC
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.
Comment 1 Jesse Glick 2008-03-11 15:48:15 UTC
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?
Comment 2 Andrei Badea 2008-03-12 11:02:51 UTC
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 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.
Comment 3 Jaroslav Tulach 2008-03-13 08:12:05 UTC
Btw. Charset.displayName() or Charset.displayName(null) may delegate properly.
Comment 4 Andrei Badea 2008-03-13 15:33:37 UTC
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.
Comment 5 Andrei Badea 2008-03-21 15:52:40 UTC
Created attachment 58849 [details]
Proposed change
Comment 6 Andrei Badea 2008-03-21 15:53:58 UTC
Created attachment 58850 [details]
Changes in apisupport and freeform project types
Comment 7 Andrei Badea 2008-03-21 15:58:39 UTC
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.
Comment 8 Jesse Glick 2008-03-21 17:50:56 UTC
apichanges.xml <summary> looks wrong.
Comment 9 Andrei Badea 2008-03-23 15:56:22 UTC
Created attachment 58895 [details]
Proposed change (update 1)
Comment 10 Andrei Badea 2008-03-23 15:58:00 UTC
Thanks, fixed.
Comment 11 Ken Frank 2008-03-25 02:04:50 UTC
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)
Comment 12 Andrei Badea 2008-03-25 10:21:12 UTC
No, I don't know of any.
Comment 13 Andrei Badea 2008-03-25 10:23:09 UTC
Unless there are any more comments I will commit later today.
Comment 14 Jaroslav Tulach 2008-03-25 11:15:35 UTC
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 
Comment 15 Andrei Badea 2008-03-25 14:05:36 UTC
Created attachment 59015 [details]
Proposed change (update 2)
Comment 16 Andrei Badea 2008-03-25 14:25:50 UTC
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.
Comment 17 Andrei Badea 2008-03-27 00:35:48 UTC