PHP的爽与不爽
分页: 1/2 第一页 1 2 下页 最后页 [ 显示模式: 摘要 | 列表 ]
早上在编译PHP的是发现了一个PHP的bug...

早上编译php 5.2.6总是说我的mysqlclient没有装,我很奇怪,然后就去找了发现/usr/lib64下确实有.so啊为什么? 后来想想是不是愚蠢的php不知道/usr/lib64啊(因为操作系统是64位版本) 于是我把lib64下的so cp到lib下居然发现一切ok了!!!

实在要鄙视PHP这东西的,早就说过了php用过了就会有冲动自己写脚本编译器去的,事实很多次证明了这东西,但是这么垃圾的东西还有那么多人用(包括自己)实在想不通,看来生命就是在于折腾啊...呵呵

diszus估计是目前最流行的论坛了, 他的程序自然是大家都觉得还不错的, 可是事实呢? 不客气讲这也叫程序? 估计大群粉丝要开始骂我了,包括那些热衷于收购dz论坛的vc们,呵呵,那就来举个例子看看吧.

大家都知道最简单的就是通用登录,有人说了他不是有usercenter么?usercenter?我不敢用也不会用,你能保证你的程序也是php吗?他就没有考虑这点,其实解决这个问题太简单了,做一个数据网关就好了,如此简单的思维都没有,dz的构架师是要付全部责任的,特别是这样一个2007年开始发展的项目.

好了,回过来继续,那么uc这条路不通,我又搞不懂dz这个写得那么好的uc范例,那么直接调用吧,dz里负责这些事情的地方叫logging.php,这个文件打开之后就目瞪口呆了:

if($action == 'logout' && !empty($formhash)) {
...
}

所有所谓的动作就是这样通篇ifelse出来的,换句话说如果我要include你都没办法调用你,而它的所有逻辑都在这个代码里,我的妈呀!我忍不住又重复一次,你这也叫程序?你侮辱我了,真的.最起码的你要写一个类里边放些static方法吧,也好歹可以装B下叫做focade模式,可你这个算什么?换句话说我include一点没有价值,而这种思路我坦白说在我们公司的程序里也比比皆是,只要一个改动就完全没有办法调试,调试效率低下到了极点.

可是我又真的不想重构你,因为你的程序经常升级不太想改除了模板以外的部分,但这意味着某些时候我要妥协你了,当然妥协很简单,只要参数和你一直就好了,伪装下.

前几天我闹了笑话,我一直以为$_GET是一个只读变量但是在PHP5.2.5下居然可写的,实在令我无法理解php.net的思路,这样的做法只会把php带去一个更不需要讲求封装的低级世界,真可怕.

震惊过了,牢骚过了,该做的还得继续,但这不断让我膨胀的自满感,对我绝对不是一件好事,因为真实水平远远没有独孤求败,只是环境有些低而已,世界在进步,你进步慢就是退步了,呵呵,要自我清醒才行.

突然又想到了,这个问题,不要说我为什么老是用别人的标准来衡量它,道理很简单,因为我要用,最近在对zend framework做一次构架改造,遇到了需要覆盖成员和重载的难题,但是很可惜php是不支持的,只能写很多不同名方法,这看起来也不错,但是仔细想想这样代码的冗余度是极高的,也不利于接口应用。

说道这个问题,就要说说我很早以前发现的php bug,最后的结论php具有执行的不确定性,当它找不到默认构造的时候的时候(也就是写入一个参量不存在的php构造方法),这个时候php依然执行了它的默认无参数构造,而这在程序中会引起很大的问题。这个问题我当时从php的bug report得到的回答这是对的,我是错的,我不知道我对对象的理解是否有问题,我只知道它执行了一个我不期望的方法,但这被认为是对的,原因就是当在没有重载概念时当然是对的,为什么不对?因为只要参数不违法就能执行,php似乎对参量控制都很松(这种松是我无法忍受的),php最大的问题就是false是没有值,不是null就是空,这是一个很奇妙的问题,等于在php中机会不会出错的,这也就能解释为什么它不能重载,因为当他发现方法没有时他根本无法判断这到底是不存在还是类没有初始化,因为他们得到的结果都是一样的!而我不知道为什么这么一个愚蠢的问题为什么得不到修正,至少我知道的语言里没有这样false不知道是啥的语言,php就是这样的。牢骚就不说了,写点难看的具有php特色的代码去。

从 method_exists 说起

[ 2008/05/10 12:50 | by edwardproAdmin ]
周五要用 method_exists 这个函数,当然如果再源头说用这个函数都是无奈,在别的语言我完全可以依靠try catch来解决问题,但是在php我却不敢这么做,原因是它的除错很有可能先die了,这会导致严重的问题,而try是无法捕捉这个错误的,原因是它的执行不是堆栈的或者说它的执行不是程序所看到的堆栈流程,于是php里多了很多服务于try操作的函数,比如 method_exists。其实用这个函数很简单不会出问题,但我今天想说说更深层次的东西。
首先看看这个函数的定义:
bool method_exists ( object object, string method_name )

Just a note that the behaviour of this function changed between version 5.0.x and 5.1.x when using static member functions

Using this code:
<?php
class a
{
   static function
test() {return "A"
;}
}
if(
method_exists('a','test'
))
   print
call_user_func(array('a','test'
));
else
   print
"Nothing"
;
?>
PHP 5.1.x returns "A"
PHP 5.0.x returns "Nothing"

Im not sure of a workaround for PHP 5.0.x yet.


看到没有,这个函数表现变了,因为5.1的时候发现如果方法是static的时候(也就是没有实例的域操作)无法判断了,我一开始也遇到了这个问题原因是我只看了定义,呵呵。而在5.1中它扩展了这个函数使得能够判断static 函数了,这从侧面折射出php是一种相当不成熟的语言,很显然在5.0时没有考虑这个需求,但实际上这个需求5.0肯定存在,但为什么存在呢?这是显而易见的。。。php社区的核心程序员思想是老旧的(这不是什么出言不逊,如果要明证这点,我还有很多例子,有人说你不要对php的oo提那么高的要求,问题是我不提,它的所有竞争对手都在这方面秒杀了php,php的前景黯淡,至少我是这么认为的)

对于php的oo我想我没有要求了,只要你正确就好了,语法支持我再要求一个重载就好了,其他的不提了。但我渐渐开始思考php究竟怎么发展,走标准oo意味着它必须抛弃所有的过去,也就是完全和老版本不兼容这个东西在python上是看到了3.0是不支持2.0的就是这样,这样才能大踏步的往前因为这样没有包袱。但php不同,php的优势在于众多的历史项目,如果抛弃了它,那么意味着更多人抛弃php,这不是太现实,因为它有很沉重的历史负担。那么究竟应该怎么发展呢?我想完全可以依靠标记,也就是annation,这是一个好东西,这种编程方式就像写附注一样,而且有很简单。
比如上述的我们可以这样考虑
class test{

static $cmd="xxx";
@catch::NoMethodException 就是说抓住下面的错误如果抛出了nomethodexception
@catch::NullPointedException
static initSystem(){
....
}

static function target(){
....
}

这只是一个猜想的例子,我也觉得这样不是最合适的,呵呵,当然我们可以寻找更好的模式来,这是借鉴了java的模型。

这种语言更接近于脚本的习惯,而在编译器端也是很好开发的(这点已经被java所证明了),而这种语法的好处是,即使php不支持它大不了可以忽略这些语句,也就是程序会可能变得不够强壮,但不会不能使用,这就是它的妙处,而这样也就有效解决了语言的继承关系又不失它的oo规范,既然一条路走不通我们就应该走另外的道路,php也是,但目前来说,我看到的php依然固我,这是很令人失望的。

在亚马逊的统计上也看得到php的份额正在不断失去,它还在吃老本,但是当对手始终可以秒杀你的时候,你靠吃老本也会很快耗完,赶快醒悟吧。
公司的一个新项目多用户blog系统终于在起起落落,拖拖沓沓的3个月之后上线了,目前运行的还是不错的,在这个版本中的框架action是最早的0.9版本 orm部分则是4个月前使用的未完成版本,但已经验证了action部分性能和实现的可行性,并且在不断改进中在老的action上加入了render等1.5版本的功能,框架正在试验中得到不断的完善,3月份基于拥有orm1.3版本的另外一个后台项目会上线,到时候还可以再期待一下。但目前版本中有个小问题就是,当我把smarty作为内存模组使用时出现了模板重复编译问题,所以下一个研究对象将会是smarty,我可能会对smarty机制做一个学习,并期望能重写一个完全面向对象并且基本兼容现有smarty语法的新版本,到时如果加入到应用框架,那么这个框架的三大部分就基本拥有了独立的自主设计模块,最后只要对数据库连接池部分做一个接口化就可以得到我最终的产品要求,可喜可贺,也期待着这天快点到来。

目前下一步研究的目标是在orm 1.3版本基础上利用aop思想实现对数据库存取的缓存技术,目前有了一个初步构想,但不知道效率如何,在其中会大量使用自省函数,php的自省函数我并没有做过很多原理研究不知道性能如何,如果大量应用会不会引起性能误差这一切还是未知数,但实验还是需要做的。

另外下个月准备开始搜索前端2.0版本核心api的开发工作,目标是要实现完全开放化的指令解析和语句分析,这将对我非常垃圾的底层算法和正则能力提出挑战,类构架已经基本搭载完成,现在需要只是动手开发和解决其中的问题,届时api将会被封装成module系统,并且加入webservice输出能力,使得它拥有多种支持功能,以此实现java的后端以及php的前端,将目前的平台数据桥梁问题彻底解决。

最后做一个广告吧:http://blog.onlylady.com/

关于ORM的补遗

[不指定 2008/02/23 12:47 | by edwardproAdmin ]
前天完成ORM中有个小问题,我忽略了,那就是多对一,按我的立即多对一就是一对多,但在多对多的情况下就不是这样了,因为当你做链接时会发现中间的数据表会无法真正融入整个对象集合,原因就是其中有多对一的关系,而我前天自己在实施时的配置也有点问题,居然导致了错误的方法变成了正确的结果,原因在于那天数据的id正好都是1 2 3 4 5 6所以错误的表连接居然恰好变成了正确的结果,发现这个问题之后我迅速的增加了一种外联模式,终于解决了这个巨大的bug。

现在看来ORM的好处不仅是使用方便,更多的是你会对数据表的设计和范式有一个非常深刻的认识,因为在ORM下是不允许错误的数据库范式设计的,我个人体验下来,在ORM下使用,必须达到第二范式标准,如果想完全使用必须达到第三范式,更高的范式现在来看毫无必要,但在以rails为代表的orm中会出现范式越高效率越高的情况,原因就在于他对表的操作很好的把握了delay这个概念,但传统的sql希望是最简单的方法一次取得数据,所以很多老程序员对于范式均会以越低越好著称,因为在他们的理解数据表越冗余,则sql越好些,则查询效率越高,但带来的负面就是数据的不统一和系统扩展维护的复杂度,因此在这个层面上ORM是有意义的,而且绝对应该得到推荐的。

至于效率,昨天在javaeye上看到一个讨论php orm的文章,大多数人都痛骂了php下的orm实现,其实我现在的方案效率也不高,但我觉得在后台上使用尚能接受,而且在代码上确实非常干净这一点正是我想要的东西,现在对于写程序来说,数据库操作变成了配置这是一种享受,这两天应该是心情很愉悦的两天虽然,其实我设计的表由于是标准三范式查询语句极为复杂,但现在却轻松许多,感谢orm这种概念,相信在机器性能大幅提高之后依靠硬件和使用未来的对象数据库之后,orm一定能得到更多的应用。

貌似恢复了

[不指定 2008/02/21 06:22 | by edwardproAdmin ]
今天5点半就起来了,天黑黑的,很有精神,哈哈

我的ORM实现思路介绍

[不指定 2008/02/21 05:49 | by edwardproAdmin ]
今天着重讲述SELECT上的实现。
在数据库操作中有两类SELECT,单表和多表,对于ORM对象来说多表总是非常复杂的,总结起来,表与表的关系有那么几种:
1对多
多对1
多对多
1对1
而将它们整合之后只有两种:
1对多
1对1
其中多对多变成了双向一对多(但在我的实现中使用了另外一种思路,后面会讲到,这种思路极大的简化了表的关系)而多对一本身来说就是1对多,只是主控方向不同而已,而且多对1实际上存在很少基本是在多对多中出现,因此基本可以忽略。
好了,下面来说说我对这两种模式的处理,实际上我采用了一种更简单的思维去考虑:
无论如何查询最终将返回一个hashmap(这应该是php的最佳形式,java中一个朋友曾经和我争论过这个,他认为Bean+list好过Hashmap+list,我个人的连接池均采用了hashmap+list,因为我想从根本上去摒弃java在类型上的不灵活,这是另外一个话题不到讨论),好了回到现在话题,那么经过我的乱七八糟的实验之后我只得出了两种结果,无论是哪种表关系,只有同时加载和延后加载两种风格。一种是单一数组比如
array(
"0"=>array(1,a,b),
"1"=>array(2,b,c)

另外一种模式是:
array(
"0"=>array(1,a,'extend'=>array(c,1,b))
)

实际上在实际的查询中前者我认为是LEFT JOIN语句,后者是一种我自己叫做后加载模式也就是select × from a select × from b where id in a。
而实际上我一开始去过于分析表和表的关系的时候其实是非常死胡同的,导致逻辑代码非常复杂,但却最后不知道怎么去写sql,而现在彻底摒弃了表和表的关系代以语句的实现来判断如何实现,这在很大程度上彻底简化了代码。当然我这种代码在本质上有很多致命弱点——查询语句会偏多带来的直接问题就是效率偏低,这个问题要在以后不断摸索和对数据库的熟悉之后再解决。
下面来看看部分实现代码:
module的构造,他需要塞入的参数1 连接池对象 表名 field列表,这个是可选的
function Module($dbObj,$dbName,$fieldList=array()){
$this->connectObj=$dbObj;
$this->dbname=$dbName;
$this->fieldList=$fieldList;
}

查询的类:其中核心的部分就是getsqlstr和后面的processonemore,processonemore就是我说的延迟加载查询的函数
function query($where="",$group="",$limit="",$order="",$foriegn="",$lazy=1,$fields='*'){
$sql=$this->getSqlStr($fields,$where,$group,$limit,$order,$foriegn);
$this->connectObj->sql=$sql;
$result = $this->connectObj->doSqlArray();
if($lazy){
$this->processOneMore(&$result);
}
return $result;
}
单一表查询:
private function processOneToOne(){
$ret="";
foreach($this->foriegnDb as $v){
if($v['type']==1){
$dbName=$v['db'];
$fKey=$v['key'];
$ret.=" LEFT OUTER JOIN {$this->connectObj->tablePrefix}{$dbName} ON {$this->connectObj->tablePrefix}{$dbName}.{$fKey}={$this->connectObj->tablePrefix}{$this->dbname}.{$this->key}";
}
}
return $ret;
}

多表查询:
private function processOneMore(&$result){
foreach ($this->foriegnDb as $v){
//ont to more
if($v['type']==2){
$className=$v['class'];
$dbName=$v['db'];
$key=$v['key'];
require_once(MODULE_ROOT.'/module.'.$className.'.php');
if(class_exists($className)){
$mObj=new $className();
foreach ($result as $k=>$v){
$cKey=$v[$this->key];
$r = $mObj->query("{$this->connectObj->tablePrefix}{$dbName}.{$key} = '{$cKey}'");
$result[$k]['extTable']=$r;
}
}
}
}
}
好,现在这样就基本实现了orm最基本的复合查询,不过现在的orm版本在sql上还比较单一,需要更多的sql优化,对类的处理进行大面积的优化才能有工业级性能,有时间的时候继续研究,这次其实参考了比较多的cakephp的思维方式,感觉还是不错的。
还有一个重要的问题:sql查询没有进行缓冲设计,这部分我打算是要用aop化的方面编程的方式来实现,具体的实施方法还没有想好囧,哪位有这种尝试的可以给我留言哈。


一直梦想着用自己的代码实现ORM,今天终于调试成功了,隶属于RAILS IN PHP的重要组件,虽然因此项目进度再次被拖延,又被批了,但相对于那些自己的ORM总是更有吸引力的,今天是值得纪念的一天。

就因为没有重载

[不指定 2008/02/18 20:10 | by edwardproAdmin ]
今天碰到一个很妖艳的问题,问题最后出在php没有重载又不报错,直接导致没有构造,使用的PHP版本是:5.2.5,我认为这是一个BUG。由于工作写的类不方便拿出来下面写一个完整的测试环境类给大家看:

abstract class father{
function father($a){
echo "class father";
}
}

class child extends father{
//子类构造函数(这是我错误的一个地方,但它导致了php另外一个错误)
function child(){
echo "test";
}
}

//run
$obj = new child('a');

执行后会发现父类的构造函数根本没有执行!但子类的构造由于参数不对也没有执行。
这个问题很明显:当我在子类中定义了构造函数,按照覆盖原理应该覆盖掉父类的一个构造函数,但是上述情况下由于已经定义了一个非默认参数的构造,这样子类定义的构造自动变成了重载而不是覆盖。而PHP又是不支持重载的,但这个时候应该报错,但神奇的事情发生了,PHP居然执行了,但是他显然没有执行我定义的父类的构造,而是执行了一个默认构造。这是其实产生了无法预知的错误,但PHP却莫名没有报错误,这应该是一个PHP的BUG。
我提交了一个bug report到php.net: http://bugs.php.net/44149


zend studio 6的新花招

[不指定 2008/02/12 21:27 | by edwardproAdmin ]
刚发现的一个表达方式:



inc的文件会被这样来表现真的非常非常方便,这对于一些老程序是很有益处的,因为老程序往往会不规则地require东西这样看起来很头痛,这样就好多了,一个很不错的改进。

不过凡事有好有坏的,zend studio 6的在build时非常缓慢,如果文件多的话,会蛮惨的。。。

zend studio 6 序列号

[不指定 2008/02/12 12:24 | by edwardproAdmin ]
在google上搜到的,不敢独享,也转贴一下吧:

用户名:PHPER
注册码:4784D9D0086669570000
CakePHP 手册翻译,前面略掉部分废话章节,从Basic Concepts 开始翻译:

Section 1

Introduction

This chapter is a short, casual introduction to MVC concepts as they are implemented in Cake. If you're new to MVC (Model View Controller) patterns, this chapter is definitely for you. We begin with a discussion of general MVC concepts, work our way into the specific application of MVC in CakePHP, and show some simple examples of CakePHP using the MVC pattern.

本节很短,而且是一个很随便的关于MVC和cake的话题。如果你之前对MVC这个概念不足够了解,本节会给你一个大致的定义。我开始讨论一般的MVC以及在cakePHP中MVC视如何定义的,其中会有些CakePHP的例子是使用 MVC模式的。

Section 2

The MVC Pattern

Model-View-Controller is a software design pattern that helps you logically separate your code, make it more reusable, maintainable, and generally better. Model View Controller was first described by the author group Gang of Four. Dean Helman wrote (an extract from Objective Toolkit Pro white paper):

MVC是一种设计模式帮助你在逻辑上分离代码,使得他具有更多重用性,可维护性。MVC最早是四人小组中的Helman提出的。

"The MVC paradigm is a way of breaking an application, or even just a piece of an application's interface, into three parts: the model, the view, and the controller. MVC was originally developed to map the traditional input, processing, output roles into the GUI realm.

MVC凡是是一种方法,他把应用程序分成三个部分 MODEL VIEW 和 CONTROLLER。MVC通常被用来开发映射成为 传统意义上的输入 处理 输出到界面 三个部分。

Input -> Processing -> Output

Controller -> Model -> View

"The user input, the modeling of the external world, and the visual feedback to the user are separated and handled by model, view port and controller objects. The controller interprets mouse and keyboard inputs from the user and maps these user actions into commands that are sent to the model and/or view port to effect the appropriate change. The model manages one or more data elements, responds to queries about its state, and responds to instructions to change state. The view port manages a rectangular area of the display and is responsible for presenting data to the user through a combination of graphics and text."


          用户从外部世界输入一个模型(MODEL),然后可视化界面会返回给用户,通过被分离和控制的 model view 端口 以及 控制器对象。控制器从鼠标和键盘得到用户的输入并变成动作指令送到model或者view端口并给予适当的改变。model管理着一个或者多个数据源色返回这些状态的数据,然后返回被改变状态的指令。 view端口管理一个显示区域并将数据通过图形和文本形式显示给用户。

In Cake terms, the Model represents a particular database table/record, and it's relationships to other tables and records. Models also contain data validation rules, which are applied when model data is inserted or updated. The View represents Cake's view files, which are regular HTML files embedded with PHP code. Cake's Controller handles requests from the server. It takes user input (URL and POST data), applies business logic, uses Models to read and write data to and from databases and other sources, and lastly, sends output data to the appropriate view file.

To make it as easy as possible to organize your application, Cake uses this pattern not only to manage how objects interact within your application, but also how files are stored, which is detailed next.

在CakePHP中,model通常提供一个数据库的表或者记录以及他关联的其他表和记录。model还包括当model数据被插入或者更新时的数据验证规则。CakePHP的VIEW是一些嵌入了PHP代码的HTML文件。cake的控制器掌握着来自服务器的请求。他包含着用户输入(url和post 数据),适用的商务逻辑,控制model从数据库或者其他数据源读取和写入数据,最后,把输出数据送到显示文件。为了使得你的应用程序尽可能简单地组织起来,cake不只是用这些模式管理对象和你的应用的交互,也帮助管理文件怎么存储这些具体细节。

Section 3

Overview of the Cake File Layout

When you unpack Cake on your server you will find three main folders -

      app       cake       vendors       

当你解压缩cake后就会发现三个目录

The cake folder is where the core libraries for Cake lay and you generally won't ever need to touch it.

The app folder is where your application specific folders and files will go. The separation between the cake folder and the app folder make it possible for you to have many app folders sharing a single set of Cake libraries. This also makes it easy to update CakePHP: you just download the latest version of Cake and overwrite your current core libraries. No need to worry about overwriting something you wrote for your app.


cake目录防治这cake的核心代码,一般来说你不要去动它。
app目录是你的因程序的目录。他和cake目录是分开的。app目录也是的你的许多应用都可以共享一套cake lib,这样你可以很容易去升级cakePHP。你只要下载最新版本的ake然后覆盖掉你当前的核心库,不需要担心覆盖掉任何你写的应用程序。

/app     /config          - Contains config files for your database, ACL, etc.       /controllers     - Controllers go here          /components  - Components go here      /index.php       - Allows you to deploy cake with /app as the DocumentRoot      /models          - Models go here       /plugins         - Plugins go here      /tmp             - Used for caches and logs      /vendors         - Contains third-party libaries for this application      /views           - Views go here         /elements    - Elements, little bits of views, go here         /errors      - Your custom error pages go here         /helpers     - Helpers go here         /layouts     - Application layout files go here         /pages       - Static views go here      /webroot         - The DocumentRoot for the application         /css         /files         /img         /js  /cake                - Cake's core libraries. Don't edit any files here.  index.php             /vendors             - Used for server-wide third-party libraries.  VERSION.txt          - Let's you know what version of Cake you're using.



You can use the vendors directory to keep third-party libraries in. You will learn more about vendors later, but the basic idea is that you can access classes you've placed in the vendors directory using Cake's vendor() function.

Let's look at the entire file layout:

名字叫cake PHP,粗看了代码还是有不少值得学习的地方的,这几天仔细看看,回头再来发表发表感想,主要是看到里边有ACL的部分,实现也是属于模块的,而在ORM方面他的实现层次也是3层和我的构思差不多,说不定有很多惊喜可以看,哈哈,总之还是很期待的。

http://www.cakephp.org/

好久没有写了,平时上班,没啥兴趣了,周末xx也写点吧,今天说说User接口和权限控制的讨论。

首先来谈谈权限范围内具体几个工作:
1 权限菜单
2 权限控制(控制是否能访问)
3 登录控制

在ACEGI中,它的数据描述抽象成了一张田字表,圈圈叉叉,然后通过XOR得到权限值,但这种方法在ACEGI中使用我觉得还是比较麻烦的,当然麻烦的好处是人家确实性能高超,没有做不出来的东西,但一般如果只是简单的控制我觉得貌似有牛刀之嫌了。我理解的权限控制是这样的一种实现:
<?php
/*
@description 定义用户处理类的接口方法
@author edwardpro
*/
interface User{
 function isLogin($uid="");

 function login($user,$pass);

 function logout($user);

 function getUserInfo($uid="");

 function isValid($userinfo);
}
?>
方法和实现都很容易理解
isLogin判断是否登录
login、logout 登录退出
getUserInfo得到用户信息,包括得到权限信息
isvalid是否合法用户

看似比较松散的结构,但充分考虑的网页应用的局限性,和ACEGI这类产品级产品完全不同,通过自己实现如上述的5个方法我相信绝对可以达到权限控制的目标了。

这是一个被注入在Action中的User接口,在ACTION中会在构造函数中增加:
 function setUser(){
  require_once(USER_CLASS_PATH.'class.'.USER_CLASS_NAME.'.php');
  if(class_exists(USER_CLASS_NAME)){
   $cName=USER_CLASS_NAME;
   $this->userClass=new $cName();
  }
  if($this->userClass->isLogin()){
   //注册为登录状态
   $this->islogin=1;
   $this->userinfo=@$this->userClass->getUserInfo();
  }else{
   $this->islogin=0;
   unset($this->cookieData[sessionID]);
  }
 }

Tags: ,
分页: 1/2 第一页 1 2 下页 最后页 [ 显示模式: 摘要 | 列表 ]