phpk框架简介
PHPK是一个简单易用，易于扩展的轻量级PHP框架。phpk不仅仅是一个php框架，也是一个js框架，内置一套全新的js内库，完全摒弃了庞大的jquery，所有的前端都是一个全新的微世界。运行高效而不失功能强大，操作灵活而又能扩展自如。作为PHP框架里的&后起之秀&，PHPK秉承了那些优秀的PHP框架所共有的，并进行了很多微创新。
OOP编写风格，完全依据面向对象的思想编写
多项目管理，共享数据缓存层
自动压缩js和css文件
内嵌一个js微型内核，易于扩展
URL路由，支持3种路由模式
hook钩子操作，支持系统内核外扩展
助手函数，支持外围函数扩展
模版视图，模版引擎支持视图，支持本地缓存
wedgit，支持单独的区块加载
插件机制，可以很方面的引用第三方类库
多语言，支持多语言扩展
多种加密方式
多缓存机制
多种数据库引擎
支持分布式
多权限认证机制
支持自动侦测是wap还是web浏览
支持自动侦测客户端语言
一、如何调用？
&&把phpk文件夹下载到本地，然后在phpk文件夹上层建立index.php，里面代码如下：
include './phpk/base.php';
　然后访问index.php，然后你就会看到&欢迎使用phpk框架！&　
二、如何配置？
如果第一步访问成功，你就会在项目的根目录发现多了几个文件夹，分别是plugins、data、projects、projects/www。当然还有根目录下的config.inc.php，这个文件是项目总配置文件，代码如下：
//全局配置声明在这个文件中.
$CONFIG['system']['db']['driver']
= 'mysql';//数据库类型
$CONFIG['system']['db']['charset']
= 'utf8';//数据库编码
$CONFIG['system']['db']['prefix']
= 'ig_';//表名前缀
$CONFIG['system']['db']['master']['host']
= 'localhost';//主库地址
$CONFIG['system']['db']['master']['database']
= 'itest';//数据库名称
$CONFIG['system']['db']['master']['port']
= '3306';//默认端口
$CONFIG['system']['db']['master']['user']
= 'root';//数据库帐号
$CONFIG['system']['db']['master']['password']
= '123456';//数据库密码
$CONFIG['system']['app']['allow_dir']
= array("www","wap","admin","tools");//系统允许的应用
$CONFIG['system']['app']['auto_detect']
= 1; //是否自动侦测是wap还是web
$CONFIG['system']['app']['defalut_web_path']
= 'www';//默认的应用目录
$CONFIG['system']['app']['defalut_wap_path']
= 'wap';//默认的手机应用目录
$CONFIG['system']['security']
= '_phpk_@#!%DFDS_';
// 系统的加密字符串
$CONFIG['language']['switch_on']
= 1; //是否打开语言包
$CONFIG['language']['default_lang']
= 'zh-cn';//默认语言
$CONFIG['language']['auto_detect']
= 1; //是否自动侦测语言
$CONFIG['language']['get_var']
= 'lang'; //前端get获取语言包的字符
$CONFIG['language']['lang_list']
= 'zh-cn';//语言包列表，用逗号隔开
　　在projects/www文件夹下面也会多出一个项目配置文件config.inc.php，代码如下：
//项目配置声明在这个文件中.
$CONFIG['debug']
// 项目的调试模式，1为打开，0为关闭
$CONFIG['route']['url_type']
// url模式，1为字符串模式，2为pathinfo模式
$CONFIG['route']['default_controller']
= 'index';
// 默认控制器文件
$CONFIG['route']['default_action']
= 'index';
// 默认action接口
$CONFIG['output']['charset']
= 'utf-8';
// 页面字符集
$CONFIG['output']['errorlog']
// 是否记录错误日志
$CONFIG['output']['forceheader']
// 强制输出页面字符集，用于避免某些环境乱码,0为关闭，1为开启
$CONFIG['output']['gzip']
// 是否采用 Gzip 压缩输出
$CONFIG['output']['tmpl_cache']
// 是否开启模版缓存，0为内存输出做调试模式用，1为检测缓存输出做开发模式用，2为调用缓存输出，3做正式环境用
$CONFIG['output']['layout_on']
// 是否开启布局，0为关闭，1为开启
$CONFIG['output']['layout_name']
= 'layout';
// 布局的文件
$CONFIG['output']['layout_item']
= '{_content}'; // 布局的内部替换的标签名称
$CONFIG['output']['tmpl_suffix']
// 模版的后缀
$CONFIG['output']['default_tmpl']
= 'default';
// 默认模版目录
$CONFIG['output']['csszip']
// 是否压缩css文件，1为压缩，0为不压缩
$CONFIG['output']['jszip']
// 是否压缩js文件，1为压缩，0为不压缩
$CONFIG['loader']['libs']
= array();
// 是否加载外围的类
$CONFIG['loader']['helpers']
= array();
// 是否加载外围函数
$CONFIG['loader']['hooks']
= array();
// 是否加载钩子
$CONFIG['session']['prefix']
// session的前缀
$CONFIG['session']['id']
// session的id
$CONFIG['session']['expire']
// session的超时时间
$CONFIG['session']['auto_start']
// 是否自启动session，1为开启，0为关闭
$CONFIG['cookie']['prefix']
// cookie的前缀
$CONFIG['cookie']['path']
// cookie的有效路径
$CONFIG['cookie']['expire']
// cookie的超时时间
$CONFIG['cookie']['domain']
// cookie的作用域
$CONFIG['cache']['type']
// 缓存类型
$CONFIG['cache']['table']
= 'tb_cache';
// 缓存表的名称
$CONFIG['cache']['prefix']
= 'cache_';
// 缓存前缀
$CONFIG['cache']['time']
// 缓存过期时间
$CONFIG['cache']['check']
// 是否进行缓存的数据校验
$CONFIG['cache']['compress']
// 是否缓存压缩
$CONFIG['auth']['auth_on']
//是否启动权限认证
$CONFIG['auth']['auth_type']
//权限认证方式
　　项目配置文件继承了项目总配置文件，也可以对项目总配置文件重写。这样做的好处是，增加了项目的灵活性。
三、如何使用模版？
首先要写controller文件，在projects/www/controllers/indexController.class.php文件夹里，这样写：
class IndexController extends Controller
function index ()
$welcome = "欢迎使用phpk框架！";
$this-&assign('welcome', $welcome);
$this-&display('welcome');
模版文件支持layout，可以在projects/www/views/layouts/layout.php这样写，（这个文件的名字可以在项目里配置，也可以单独指定）
&!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"&
&meta http-equiv="Content-Type" content="text/ charset=UTF-8"&
&title&&?php echo $?&&/title&
{_content}
然后在projects/www/views/default/index.php模版文件里这样写：
&?php echo $?&
phpk模版支持js和css简写调用：
{css cssfile1,cssfile2}
{js jsfile1,jsfile2}
也支持一些静态调用方法，比如：{img}{js}{css}{pro}{url}{public}等，尽量做到简单、精简、规范。
phpk的内置模版引擎可以不用本地缓存，直接内存输出，也可以在项目完成后直接调用缓存文件。
四、如何数据查询？
phpk框架摒弃了一般框架的orm（关系数据库映射），让用户更加容易上手。下面是一个模型用例（projects/www/model/indexModel.class.php）：
class IndexModel extends Model{
* 检测用户名
* @param string $username
* @param string $password
* @return multitype:
function checkUser($username,$password){
$sql = "select uid,username,group_id from tb_user where username='$username' and password='$password'";
return $this-&select($sql,1);
* 更新用户登录信息
* @param int $uid
function updateUser($uid,$arr = array()){
$data = array('last_login_time'=&time(),'last_login_ip'=&getIp());
$result = array_merge($data, $arr);
$this-&update("tb_user", $result,"uid='$uid'");
五、如何使用钩子、助手函数和外围库？
phpk框架沿用了codeigniter的钩子思想，借鉴了thinkphp的行为体系，坚持易用简单的原则。配置钩子，首先需要在项目配置文件里加上：
$CONFIG['loader']['hooks']
'pre_controller' =& 'auth'
// 是否加载钩子
key值参考下面的说明：
* pre_system
系统执行的早期调用.仅仅在系统类和配置项加载完毕的时候. 没有执行路由或者其它的过程.
* pre_controller
在调用你的任何控制器之前调用.此时所用的基础类,路由选择和安全性检查都已完成.
* post_controller_constructor
在你的控制器实例化之后，任何方法调用之前调用，传入的参数为实例化的控制器。
* post_controller
在你的控制器完全运行之后调用，传入的参数为实例化的控制器。
* display_override
output.tmpl_cache=0时截取调试模式下的模版, 用来在系统执行末尾向web浏览器发送最终页面,传入参数为解析后的模版内容。调用后记得exit。
* cache_override
截取cache模式下的模版,这可以让你使用自己的方法来显示缓存文件，传入参数为解析后的缓存文件。调用后记得exit。
* post_system
在最终着色页面发送到浏览器之后,浏览器接收完最终数据的系统执行末尾调用
　　value值为需要加载的文件名，hook的文件放在projects/controllers/hooks/authHook.class.php
助手文件和外围库的加载更加简单，只需要这样写配置文件即可：
$CONFIG['loader']['libs']
= array('html','csv');
// 是否加载外围的类
$CONFIG['loader']['helpers']
= array('dir','str');
// 是否加载外围函数
当然你也可以扩展自己的助手文件和类库，把他们分别放在extensions/functions/和extensions/classes/里面，系统会先判断项目加载文件是否存在，然后再去判断系统内核文件。
&下载地址：
SVN地址：&
项目交流群：
阅读(...) 评论()怎么用js引用php里的函数？_百度知道
如果说将php内的数据传给js，操作如下。页面Akey.js 或者 嵌入式 js假设有变量 var kphp代码$a=array('OK')echo '&script&k='.json_encode($a).'&/script&';第二种$b='ok';echo '&script&k='.$b.'&/script&';
不太懂和这个一样的key.js 里怎么写才能访问 key.js 就能看到那段代码
我也不懂你想说什么，你那一串不知道是什么的代码，加了那么多的eval 具体的用途是什么。
其他类似问题
为您推荐：
其他1条回答
像这样的，
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁php数组参数,=&的意思, 代码中$k=&$ag是什么意思呢，为什么要这样？_百度知道
php数组参数,=&的意思, 代码中$k=&$ag是什么意思呢，为什么要这样？
foreach ($lasted_agents as $k=&$ag) { $lasted_agents[$k]['uno']=$blogObj-&getOne(&select uno from user_blog where uid='&.$ag['store_id'].&'&); $lasted_agents[$k]['brand_name']=$blogObj-&getOne(&select name from fssplatform.fss7_fx_brands where id='&.$ag['brand'].&'&);}
提问者采纳
foreach ($lasted_agents as $k=&$ag) {这句的意思是把数组 $lasted_agents 中的下标放入变量 $k，把对应的数组值放入$ag中。便于你使用。很方便的。
$lasted_agents[$k]['uno']
那这句意思呢？麻烦啦(*^__^*)
就是所你的数组 $lasted_agents 中下标是$k 的元素还是个数组，在这里命名为A；A['uno']是什么意思知道了吧。 就是取A中的uno这个元素，然后为他赋值。
提问者评价
谢谢了啊，我正开始研究一下php
其他类似问题
为您推荐：
您可能关注的推广
php的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁PHP Master | Logging with PSR-3 to Improve Reusability
February 06, 2013
Logging is one of the most ubiquitous tasks encountered in PHP. We use logs to track error messages, record important events, and debug problems with our code. In any PHP project, the code is likely to be full of calls to a logging library which handles these actions for us.
Unfortunately, having calls to a logging library scattered throughout our code makes the code dependent on the availability of that library, a clear violation of the Dependency Inversion Principle. Even if we use dependency injection to give our objects access to the logging library, the differences between logging libraries means that it can be difficult and time consuming to switch between them, requiring a major refactoring of our entire codebase.
To promote compatibility between logging libraries, the PHP-FIG group recently released , a common interface for logger objects. In this article, I’ll discuss how the logger interface defined by PSR-3 allows us to write reusable code that isn’t dependent on any particular logging implementation.
First, a Quick Primer
Before we look at how PSR-3 can make our code more reusable, it is necessary to understand what PSR-3 is. If you are already familiar with PSR-3, you can skip this section.
The heart of the specification is an interface for logger objects. This interface exposes eight methods for handling messages of different severity, and a generic log() method which can accept an arbitrary severity level.
The eight severity levels supported by PSR-3 are based on , and are described below:
Emergency – the system is unusable
Alert – immediate action is required
Critical – critical conditions
Error – errors that do not require immediate attention but should be monitored
Warning – unusual or undesirable occurrences that are not errors
Notice – normal but significant events
Info – interesting events
Debug – detailed information for debugging purposes
Each of the logging methods accepts a message, which must be a string or an object with a __toString() method. An additional argument accepts an array, which may be given to provide contextual information for the log message.
A full explanation of these methods and parameters can be found in the .
Getting PSR-3 Files
Getting the files you need to work with PSR-3 is easy – you can find them in the Psr/Log . You can also use
to get the files from . Below is a sample composer.json file to retrieve the Psr/Log files:
&require&: {
&psr/log&: &dev-master&
How Logging Can Limit Code Reuse
There are many different logging libraries for PHP, each with its own approach to collecting and recording data. While there are some common ideas among them, each library has its own unique set of logging methods. This means that switching between loggers can be challenging, often requiring code changes wherever logging is used. This works against the idea of code reuse and the
of object-oriented design. We’re left with a situation that requires us to either declare a dependency on a specific logging library, or avoid logging entirely.
To illustrate this problem more clearly, a concrete example is needed. Let’s say we’re creating a simple Mailer object to handle sending emails. We want the Mailer to log a message whenever an email is sent, and we decide to use the excellent
library to handle our logging needs.
namespace E
class Mailer
public function __construct($logger)
$this-&logger = $
public function sendEmail($emailAddress)
// code to send an email...
// log a message
$this-&logger-&addInfo(&Email sent to $emailAddress&);
We can use this class with the following code:
// create a Monolog object
$logger = new MonologLogger(&Mail&);
$logger-&pushHandler(new MonologHandlerStreamHandler(&mail.log&));
// create the mailer and send an email
$mailer = new EmailMailer($logger);
$mailer-&sendEmail(&&);
Running this code will result in a new entry in the mail.log file, recording that the email was sent.
At this point, we might be tempted to say that we’ve written a reusable Mailer object. We’re making the logger available to the Mailer with dependency injection so we can swap out different logger configurations without having to touch our Mailer code. It appears that we’ve successfully followed the SOLID principles and avoided creating any hard dependencies.
But suppose we want to reuse our Mailer class in a different project which uses
to handle logging interactions. Now we run into a problem, because Analog doesn’t have an addInfo() method. To log an info level message with Analog, we call Analog::log($message, Analog::INFO).
We could modify our Mailer class to use Analog’s methods, as seen below.
namespace E
class Mailer
public function sendEmail($emailAddress)
// code to send an email...
// log a message
Analog::log(&Email sent to $emailAddress&, Analog::INFO);
We can consume the updated Mailer class using the following code:
// set up Analog
Analog::handler(AnalogHandlerFile::init(&mail.log&));
// create the mailer and send an email
$mailer = new EmailMailer();
$mailer-&sendEmail(&&);
While this will work, it is far from ideal. We’ve run into Mailer’s dependency on a specific logging implementation, which requires the class to change whenever a new logger is introduced. This makes the class less reusable and forces us to choose between being dependent on the availability of a specific logger or abandoning logging from within our class entirely.
Using PSR-3 to Avoid the Logger Dependency
As Alejandro Gervasio explained in his excellent
on the subject, the Dependency Inversion Principle tells us that we should depend upon abstractions rather than concretions. In the case of logging, our problem so far has been a lack of a decent abstraction on which to depend.
This is where PSR-3 comes in. PSR-3 is designed to overcome the problem of incompatible logging implementations by providing a universal interface for loggers, aptly named LoggerInterface. By providing an interface which is not bound to any particular implementation, PSR-3 frees us from having to rely on a specific logger – we can instead type-hint against LoggerInterface to acquire a PSR-3 compliant logger. I have updated the Mailer class below to demonstrate this:
namespace E
class Mailer
public function __construct(PsrLogLoggerInterface $logger)
$this-&logger = $
public function sendEmail($emailAddress)
// code to send an email...
// log a message
$this-&logger-&info(&Email sent to $emailAddress&);
The constructor has been modified to accept an implementor of LoggerInterface, and the sendEmail() method now calls the info() method specified in PSR-3.
Monolog is already PSR-3 compliant, and Analog supplies a wrapper object that implements LoggerInterface, so we can now use both loggers without modifying our Mailer class.
Here’s how you would call the class with Monolog:
// create a Monolog object
$logger = new MonologLogger(&Mail&);
$logger-&pushHandler(new MonologHandlerStreamHandler(&mail.log&));
// create the mailer and send an email
$mailer = new EmailMailer($logger);
$mailer-&sendEmail(&&);
And with Analog:
// create a PSR-3 compatible Analog wrapper
$logger = new AnalogLogger();
$logger-&handler(AnalogHandlerFile::init(&mail.log&));
// create the mailer and send an email
$mailer = new EmailMailer($logger);
$mailer-&sendEmail(&&);
Now we’re able to use our Mailer object with either library without having to edit the Mailer class or change the way we consume it.
Using the Adapter Pattern for Loggers that Don’t Support PSR-3
So far we’ve successfully decoupled the Mailer object from any particular logging implementation by asking for an implementor of LoggerInterface. But what about loggers that have yet to add support for PSR-3? For example, the popular
library has not been updated for some time and is currently not compatible with PSR-3.
Luckily, it’s simple for us to map the methods exposed by KLogger to those defined by LoggerInterface by harnessing the power of the . The supporting files in the
make it easy to create adapter classes by providing us with an AbstractLogger class that we can extend. The abstract class simply forwards the eight level-specific logging methods defined in LoggerInterface to a generic log() method. By extending the AbstractLogger class and defining our own log() method, we can easily create PSR-3 compliant adapters for loggers that do not natively support PSR-3. I’ll demonstrate this below by creating a simple adapter for KLogger:
namespace L
class KloggerAdapter extends PsrLogAbstractLogger implements PsrLogLoggerInterface
public function __construct($logger)
$this-&logger = $
public function log($level, $message, array $context = array())
// PSR-3 states that $message should be a string
$message = (string)$
// map $level to the relevant KLogger method
switch ($level) {
case PsrLogLogLevel::EMERGENCY:
$this-&logger-&logEmerg($message, $context);
case PsrLogLogLevel::ALERT:
$this-&logger-&logAlert($message, $context);
case PsrLogLogLevel::CRITICAL:
$this-&logger-&logCrit($message, $context);
case PsrLogLogLevel::ERROR:
$this-&logger-&logError($message, $context);
case PsrLogLogLevel::WARNING:
$this-&logger-&logWarn($message, $context);
case PsrLogLogLevel::NOTICE:
$this-&logger-&logNotice($message, $context);
case PsrLogLogLevel::INFO:
$this-&logger-&logInfo($message, $context);
case PsrLogLogLevel::DEBUG:
// KLogger logDebug() method does not accept a second
// argument
$this-&logger-&logDebug($message);
// PSR-3 states that we must throw a
// PsrLogInvalidArgumentException if we don't
// recognize the level
throw new PsrLogInvalidArgumentException(
&Unknown severity level&
The log() method simply maps the LoggerInterface methods to the respective KLogger methods, and KLogger handles the actual logging activity. By wrapping the KLogger class in this way, we’re able to use it without breaking the LoggerInterface contract.
We can now use the KLogger adapter to work with the Mailer class:
// create a new KLogger object which will log to the &logs& directory
$klogger = KLogger::instance(&logs&);
// inject KLoggger to a PSR-3 compatible KloggerAdapter
$logger = new LoggerKloggerAdapter($klogger);
// send an email
$mailer = new EmailMailer($logger);
$mailer-&sendEmail(&&);
Using the adapter class, we’re able to use KLogger without modifying the Mailer class and still adhering to LoggerInterface.
KLogger doesn’t accept a second argument for debug level messages, so it’s not technically PSR-3 compliant even with an adapter. Extending KLogger to make it fully compatible with PSR-3 would be a trivial task, but one which falls outside the scope of this article. However, it is safe to say that using our adapter class gets us very close to full PSR-3 compliance and allows us to use LoggerInterface with the KLogger class.
Conclusion
In this article we’ve seen how using PSR-3 can help us to write logger-agnostic code which does not depend on a particular logging implementation. Many major PHP projects have already added support for PSR-3, including Monolog, , and , and other big names such as
are discussing how to best integrate it. As PSR-3 makes logging less of a barrier to code reuse, we should see more libraries and frameworks making proper use of logging to provide useful information to developers.
Will PSR-3 affect how you use logging in your applications? Let us know in the comments section below.
Patrick Mulvey is a freelance web developer with broad experience in both client-side and server-side development. PHP is his favorite language for creating websites, despite all its quirks.
Available on SitePoint Premium. Check it out now!
Next Article
Get a free year of
SitePoint Premium +
hosting from BlueHost
for $3.50/month}