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.
| Summary: | The "encoding" FreeMarker variable is always UTF-8 for XML files | ||
|---|---|---|---|
| Product: | platform | Reporter: | Andrei Badea <abadea> |
| Component: | Data Systems | Assignee: | Andrei Badea <abadea> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | apireviews, jglick, jtulach, kfrank, tzezula |
| Priority: | P2 | Keywords: | API, API_REVIEW_FAST |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | 129775, 130881 | ||
| Bug Blocks: | 129454 | ||
| Attachments: |
Proposed change
Changes in apisupport and freeform project types Proposed change (update 1) Proposed change (update 2) |
||
|
Description
Andrei Badea
2008-03-10 17:52:19 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?
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 |