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 124989

Summary: There has to be impelmented FEQ fro PHP DataObject
Product: php Reporter: Petr Pisl <ppisl>
Component: CodeAssignee: rmatous <rmatous>
Status: RESOLVED WONTFIX    
Severity: blocker CC: tmysik
Priority: P3    
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on:    
Bug Blocks: 123767, 125927    

Description Petr Pisl 2008-01-09 21:24:33 UTC
There should be an implementation of FileEncodingQuery for php DataObject. This implementation should return appropriate
encoding for files with phtml extension, if there is the encoding defined through a metatag. For .php file this
implementation should return null and then the default project encoding will be used.
Comment 1 Tomas Mysik 2008-04-07 14:13:50 UTC
Reassigning to Radek, please verify. Thanks.
Comment 2 rmatous 2008-04-10 10:37:08 UTC
Current state: FEQ just provide default project encoding. Metatags in html are not taken into account. The same behavior
have our rails support for rhtml, I think.

I believe, that its enough for FEQ, even more I think our current state is transparent, unambiguous, unified. All the
php files in the project are stored in the same encoding. I'm not sure if its a good approach to mix encoding for
individual  files, or use different encoding for individual files than is set for the whole project. Maybe there are
reasons for doing it, but maybe only because of hotfixes, backward compatibility, corner cases(true?). 

There are thousands of ways how to mix encodings, and thus get into troubles: <?php echo "charset=$charset";?>, texts
from database, configuration in php.ini, .. which we cannot predict, handle anyway.

Maybe we could try to choose, opposite or other approach: when new files are generated from templates - put in code that
reflects project encoding or/and implement  hints checking the known patterns related to encoding if it is in conflict
with project encoding. 

Keeping P3 for next evaluation, until we get to final conclusion.
Comment 3 Petr Pisl 2008-04-10 14:33:42 UTC
I agree with Radek now.
Comment 4 rmatous 2008-06-23 16:55:51 UTC
RFE 
Comment 5 rmatous 2008-10-15 14:03:59 UTC
in short term not planned any effort in this area