Zend Framework

Should not be modifing case of classes

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.5.1
  • Fix Version/s: None
  • Component/s: Zend_Db
  • Labels:
    None

Description

Lines 239 and 240 of Zend_DB are:

$adapterName = strtolower($adapterNamespace . '_' . $adapter);
$adapterName = str_replace(' ', '', ucwords(str_replace('', ' ', $adapterName)));

This means that any database adapter that isn't in a camel case path structure cannot be loaded by the system. In most cases this isn't a problem however recently I worked on a project when there company initials where used as all upper case as their framework name.

As this is perfectly valid within PHP I think that the fact everything is strtolowered then ucworded is a bug or at the very least an annoyance that should be altered.

The workaround I'm currently using (and why this is only minor) is to symlink with the required case version. The autoloader is happy to load the class despite the case differences to the classname as function names, and so classnames, are case insensitive.

Issue Links

This issue duplicates:
ZF-5606 Zend_Db::factory normalizes characters in namespace, so ZendX libraries are not found N/A Resolved
This issue is duplicated by:
ZF-4705 Zend_Db::factory() is very strict on the string format for 'adapter' and 'adapterNamespace' Major Resolved

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ralph Schindler added a comment -

At current, this is not necessarily a bug. In fact, it is inline with the current coding standard on class & method nameing conventions. While this will be discussed within the next few months, it is important to know that the current coding standard states that Classes and Methods should NOT maintain their acronyms as all caps. Instead, acronyms should simply be treated as "Words" and proper care should be taken to only Cap "words" within a name to indicate word-separation.

So something like SomeXmlNode is correct, where SomeXMLNode is incorrect. If you were to translate this to a different word-separation scheme (like dashed lower), then you would be the correct version of "some-xml-node". The incorrect version would read as: "some-x-m-l-node".

We will discuss in the near future our stance on acronyms and camelCasing rules. But in the mean time, this is correct behavior for the current naming standard.

-ralph

Show
Ralph Schindler added a comment - At current, this is not necessarily a bug. In fact, it is inline with the current coding standard on class & method nameing conventions. While this will be discussed within the next few months, it is important to know that the current coding standard states that Classes and Methods should NOT maintain their acronyms as all caps. Instead, acronyms should simply be treated as "Words" and proper care should be taken to only Cap "words" within a name to indicate word-separation. So something like SomeXmlNode is correct, where SomeXMLNode is incorrect. If you were to translate this to a different word-separation scheme (like dashed lower), then you would be the correct version of "some-xml-node". The incorrect version would read as: "some-x-m-l-node". We will discuss in the near future our stance on acronyms and camelCasing rules. But in the mean time, this is correct behavior for the current naming standard. -ralph
Hide
Permalink
Luiz Fernando Furtado added a comment -

The current naming standard don't permite use with ZF extras, like ZendX_Db_Firebird.

The extras broken the naming standard with the "ZendX" prefix and the code must be changed to reflect this.

Do this broke BC?
If the developer used a AdapterNamespace with diferent case from the real file/class name, YES.

One solution (I think not the best) is to add after line 247 (v1.7.0) the folowing line:

@Zend_Loader::loadClass($adapterNamespace . '_' . $adapter);

-Luiz Fernando

Show
Luiz Fernando Furtado added a comment - The current naming standard don't permite use with ZF extras, like ZendX_Db_Firebird. The extras broken the naming standard with the "ZendX" prefix and the code must be changed to reflect this. Do this broke BC? If the developer used a AdapterNamespace with diferent case from the real file/class name, YES. One solution (I think not the best) is to add after line 247 (v1.7.0) the folowing line: @Zend_Loader::loadClass($adapterNamespace . '_' . $adapter); -Luiz Fernando
Hide
Permalink
Ashley Kitson added a comment -

Still broken in 1.8.2

My app prefix is UUllll_ (i.e. 2 upper case characters followed by lowercase ones.)

Everywhere that I use it with what is now quite a large ZF based system, there are no problems. I recently had to write a variant of the pdo_mysql adapter to get around the problem of the describeTable() not bringing back UNIQUE column info . Following the ZF documentation, I amended the creation of the adapter to add the adapterName

$params['adapterNamespace'] = 'ZWare_Object_Db_Adapter';

Doesn't work. Gets converted to Zware_Object_Db_Adapter and of course falls over.

1/ the documentation is incorrect. It explicitly shows a mixed case example name
2/ This is out of line with the rest of ZF, despite the above comments on 'the coding standard'

There is a work-around. You simply have to catch the adapter type you want to instantiate and do it directly instead of using the factory class if you need to use your own instead of the Zend one. Not very elegant, but it works. I agree with other commentators, This shouldn't be necessary.

Show
Ashley Kitson added a comment - Still broken in 1.8.2 My app prefix is UUllll_ (i.e. 2 upper case characters followed by lowercase ones.) Everywhere that I use it with what is now quite a large ZF based system, there are no problems. I recently had to write a variant of the pdo_mysql adapter to get around the problem of the describeTable() not bringing back UNIQUE column info . Following the ZF documentation, I amended the creation of the adapter to add the adapterName $params['adapterNamespace'] = 'ZWare_Object_Db_Adapter'; Doesn't work. Gets converted to Zware_Object_Db_Adapter and of course falls over. 1/ the documentation is incorrect. It explicitly shows a mixed case example name 2/ This is out of line with the rest of ZF, despite the above comments on 'the coding standard' There is a work-around. You simply have to catch the adapter type you want to instantiate and do it directly instead of using the factory class if you need to use your own instead of the Zend one. Not very elegant, but it works. I agree with other commentators, This shouldn't be necessary.
Hide
Permalink
Ralph Schindler added a comment -

Fixed with solution for ZF-5606

Show
Ralph Schindler added a comment - Fixed with solution for ZF-5606

People

Vote (2)
Watch (6)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Zend Framework. Try JIRA - bug tracking software for your team.