The XML data object should provide or at least use FileEncodingQuery to read
store in correct encoding.
The best solution is not to overide loadStreamToKit and saveKitToStream and
provide implementation of the FileEncodingQueryImplementation which detects an
encoding inside the XML file when available. This allows not only editor but all
other features like search and other which works directly on FileObject level to
read the file in the correct encoding.
The minimal change for NB 6.0 should be to use FEQ in case when no encoding has
been found in the loadFromStreamToKit or saveFromKitToStream. (When no encoding
is inside the HTML file the project encoding should be used.)
if xml file has encoding tag, does it override the encoding provided by this issue ?
or is the xml file encoding tag used just for runtime ?
Can this (and 107911) be done for nb6 ?
Most other project types, especially all those in core
areas, have implemented this and it seems
important for consistency to user that xml
files be done in same way.
As to 107911, the new xml file created would use
the project encoding value (or default fallback encoding)
for the value of the encoding tag put into the file)
What about for other project/file types that create an xml file
> in which
> currently the template and implementation assumptions is that UTF-8
> is to be used
> for encoding ?
> (like various xml files, vwp page files, tag files, various other xml
> for many projects like control files/config files or like for soa or
> in which the xml file is the file that also has the design or other
> views ?
---> shouldn't these stay as using utf-8 vs the feq value ?
or does it matter ?
another question is - should there be separate issue for how encoding is handled by
wsdl files, xsdl from database, dtd entities, xsl stylesheet, jaxb binding -- or are all of those
considered xml data objects ?
If separate issues needed for file types above, let me know and they can be filed.
please reply to questions and comments below - all other feq related project and file encoding handling
is done or almost done for all project types all for jsp and html files - thus for consistency
it seems it will be good if xml files can be done as well.
please answer for 107911 also.
also, if this will be done, need answers since am writing an overall spec/info for docs team and for qe testing spec.
now this has been done for jsp and html files; and developer in other area was asking about this
one and 107911 related to issues in their areas (that is, they need to fix some encoding problems
but approach might be different once these are implemented.
I changed the priority to P2 because it blocks my P2 issues
*** Issue 107911 has been marked as a duplicate of this issue. ***
Now the correct encoding is read for BPEL and WSDL files.
You can see comments in the Issue #111955.
I suppose the new FEQ approach isn't used by many modules yet.
And it can come to variouse strange I18N behaviours.
The new XmlFileEncodingQueryImpl class is located in the XML Core module
and it can be used easily by other XML related modules.
But it requires some efforts of authors of corresponding modules because
it's sometime dufficult to do in a code which is written by somebody else.
new revision: 1.2; previous revision: 1.1
new revision: 1.38; previous revision: 1.37
new revision: 1.23; previous revision: 1.22
/cvs/xml/core/nbproject/project.xml,v <-- project.xml
new revision: 1.14; previous revision: 1.13
/cvs/xml/schema/src/org/netbeans/modules/xml/schema/SchemaDataObject.java,v <-- SchemaDataObject.java
new revision: 1.4; previous revision: 1.3
/cvs/xml/schema/nbproject/project.xml,v <-- project.xml
new revision: 1.9; previous revision: 1.8
The way it works is, first it tries to read the encoding from the file. If found, returns it, if not, returns the
project level encoding.