基类中定义的常量在子类中不可解析
对于读过我最后几个问题的人来说,我已经成功集成了 CI 和 Propel,并且自动加载运行得很好。现在我要深入了解 Propel 本身的细微差别。
在我的 CI 控制器中,我想通过 Propel 查询表中的所有记录。所以我的控制器中的代码是这样的:
function index() {
$data = array();
$data['policytypes'] = PolicytypeQuery::create()->find();
$this->load->view('policytype_view',$data);
}
在 PolicytypeQuery::create()->find()
的调用堆栈中的某个位置,我们进入 ModelCriteria::__construct()
code>,这会产生以下错误:
constant(): Couldn't find constant Policytype::PEER
这是整个 __construct()
方法:
public function __construct($dbName = null, $modelName, $modelAlias = null){
$this->setDbName($dbName);
$this->originalDbName = $dbName;
$this->modelName = $modelName;
// THIS LINE GENERATES THE ERROR
$this->modelPeerName = constant($this->modelName . '::PEER');
$this->modelAlias = $modelAlias;
$this->tableMap = Propel::getDatabaseMap($this->getDbName())->getTableByPhpName($this->modelName);
}
因此生成的 Policytype 类只是一个存根,并且继承自BasePolicytype,它有更多的内容(但也是生成的)。在 BasePolicytype 中,我们有:
abstract class BasePolicytype extends BaseObject implements Persistent
{
/**
* Peer class name
*/
const PEER = 'PolicytypePeer';
所以...const 是在基类中定义的。 为什么它不能从子类中解析?
更新:
所以,这确实工作:
abstract class ClassA {
const CLASSA_CONST = 'foo';
}
class ClassB extends ClassA {
}
class ClassC {
function __construct($classname){
echo constant($classname . "::CLASSA_CONST");
}
}
$c=new ClassC("ClassB");
两者都在 PHP 下运行5.3.
For anyone that has read my last couple of questions, I have successfully got CI and Propel integrated and autoloading is working great. Now I am getting into the nuances of Propel itself.
From my CI controller, I want to query all of the records from a table via Propel. So the code in my controller is like this:
function index() {
$data = array();
$data['policytypes'] = PolicytypeQuery::create()->find();
$this->load->view('policytype_view',$data);
}
Somewhere down in the callstack for PolicytypeQuery::create()->find()
, we step into ModelCriteria::__construct()
, which yields the following error:
constant(): Couldn't find constant Policytype::PEER
Here's the entire __construct()
method:
public function __construct($dbName = null, $modelName, $modelAlias = null){
$this->setDbName($dbName);
$this->originalDbName = $dbName;
$this->modelName = $modelName;
// THIS LINE GENERATES THE ERROR
$this->modelPeerName = constant($this->modelName . '::PEER');
$this->modelAlias = $modelAlias;
$this->tableMap = Propel::getDatabaseMap($this->getDbName())->getTableByPhpName($this->modelName);
}
So the generated Policytype class is just a stub, and inherits from BasePolicytype, which has a bit more meat to it (but is also generated). In BasePolicytype we have:
abstract class BasePolicytype extends BaseObject implements Persistent
{
/**
* Peer class name
*/
const PEER = 'PolicytypePeer';
So...the const is defined in the base class. Why is it not resolvable from the child class?
UPDATE:
So, this does work:
abstract class ClassA {
const CLASSA_CONST = 'foo';
}
class ClassB extends ClassA {
}
class ClassC {
function __construct($classname){
echo constant($classname . "::CLASSA_CONST");
}
}
$c=new ClassC("ClassB");
Both run under PHP 5.3.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
它是“可解析的”(可见且可访问),但你把名字弄错了。
它是
BasePolicytype::PEER
,而不是Policytype::PEER
。It's "resolvable" (visible and accessible), but you got the name wrong.
It's
BasePolicytype::PEER
, notPolicytype::PEER
.我刚刚遇到了与上述完全相同的问题,但是,就我而言,问题不是 Propel 的错误。这是我的代码中的类名冲突。
我正在向现有系统添加推进力。就我而言,碰撞是一个名为“产品”的表。我已经加载了一个
类Product
。因此,当我尝试使用 propel 时,它根本不会自动加载 propelProduct
类。因此,未定义的常数。它使用了错误的代码。解决方案取决于您的具体情况。我不希望这是一个快速的过渡,并且我不想重构已弃用的代码,因此我在架构中重命名
Product
。在不同的情况下,我可能会重构旧代码以避免冲突。我在阅读这段独白后发现了这一点,谢谢 David Rea 。
I just had the exact same problem described above, however, in my case, the problem was not a bug with Propel. It was a class name collision in my code.
I was adding propel to an existing system. In my case the collision was a table called "product". I already have a
class Product
loaded. So when I try to use propel, it never auto-loads the propelProduct
class at all. Hence, the undefined constant. It's using the wrong code.The solution is dependent on your situation. I don't expect this to be a quick transition, and I don't want to refactor the deprecated code, so I'm renaming
Product
in my schema. In a different situation, I might refactor the old code to avoid the collision.I figured this out reading this soliloquy, thanks David Rea.