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: | There has to be impelmented FEQ fro PHP DataObject | ||
---|---|---|---|
Product: | php | Reporter: | Petr Pisl <ppisl> |
Component: | Code | Assignee: | 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
Reassigning to Radek, please verify. Thanks. 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. I agree with Radek now. RFE in short term not planned any effort in this area |