Google

星期三, 五月 14, 2008

使用CodeIgniter框架快速开发PHP应用:分析网站结构(3)

让我们看看内部细节。

再次强调我们并不处理静态网页和对应的URL,我们将会给你看CI如何分析URL请求和如何响应它。 首先,考虑一个正常的英特网请求。用户建立一个连接到你的网站: www.example.com,

然后经过端口发出一个如下的HTTP request:

GET /folder/file.html HTTP/1.0

GET是请求的类型, HTTP/1.0 指定 HTTP 协议的版本, 中间是相对路径和文件名。但是在你的网站上,找不到简单的静态 HTML 文件。取代它的,所有的收入请求被 index.php 文件拦截并进行处理。

如果使用者正在以正确的URL在你的网站上位置上请求页面-一般是通过点击你网页上的超级链接-request一般看起来象这样:

GET /index.php/tests/showall HTTP/1.0

如果使用者不知道精确的URL, CI 会设定一个默认页面(我们一会儿就告诉你怎么做.)

CI的处理步骤是:

+——————————–+
| internet request comes in: |
| "GET http://127.0.0.1" |
+——————————–+
|
v
+——————————–+
| Router:decides which controller|
| should handle this request |
+——————————–+
|
v
+——————————–+ +——————-+
| Controller: analyzes the | —–> | |
| request and responds:maybe | |Model:provides data|
| by getting data from the model | <—– | |
+——————————–+ +——————-+
|
v
+——————————–+
| View:formats the response |
| (in this case as an HTML page) |
+——————————–+
|
v
+——————————–+
| Page is served up to enquirer |
+——————————–+


一个从英特网到你的网站根目录的请求被 index.php 文件拦截,作用就象一个“站由器”。 换句话说, 它调用一个 ‘控制器’, 然后返回一个’视图’.

“路由器”怎么知道调用哪一个控制器? 就象我们已经见到的,有时候request本身包含的信息会告诉它调用哪个控制器。 举例来说,如果请求说:

GET http://127.0.0.1/index.php/welcome/index

并且如果你有一个控制器叫做welcome,这就是被调用的控制器。

welcome控制器

所以, 让我们看welcome控制器。 它被存放在如下路径:
system/application/controllers/welcome.php
它的内容是这样的:

class Welcome extends Controller {

function Welcome() {
parent::Controller();
}

function index() {
$this->load->view(‘welcome_message’);
}

}
?>

文件的第二行开始是一个类。 每个控制器从一个Controller类继承。 在类中包含二个函数或称为方法-welcome() 和incex().
注:CI 要求控制器名字从一个大写字母(class Welcome) 开始, 但文件名是小写字母:
/system/application/controllers/welcome.php

function Welcome() {
parent::Controller();
}

这三行组成构造函数。 注意到 CI 使用PHP 4 构造函数命名规则,兼容于 PHP 5.-CI在PHP 4 和PHP 5 两个版本中都能工作得很好。构造函数在类实例化时被调用,你可以做一些初始化的工作,比如调用函数库和模型层,或者对类的成员变量进行寝化。
这个例子中构造函数中仅一行,调用父类的构造函数。parent::Controller() 。这只是显式地使用父类功能的一种方法。如果你想要详细地了解CI框架中controller类,你可以研读文件 /system/libraries/controller.php 。
(可以放心的是你可以随时查看CI的源代码,它们已经保存在你机器上的某个目录内。)

http://www.anson-ho.com/index.php/2008/04/27/codeigniter-rapid-development-framework-for-the-use-of-php-applications-analysis-of-site-4/

标签:

使用CodeIgniter框架快速开发PHP应用:分析网站结构(2)

另一方面,你必须认识到,MVC只是用来帮助你的一种设计方式,而不是用来约束你的。MVC可以有不同的实现方式。CI 论坛包含许多如何 ‘正确合理’地实现 MVC 的方式。 ( 我应该在控制器部分实现数据库查询功能吗?我能直接从视图发送数据到模型层吗?或者我必须通过控制器来访问?)

与其寻找理论上的正确方式,不如遵循二项有用的原则。 这些在 CI 用户手册上有相关描述:

。松藕合: 类之间尽可能不要彼此依赖。

。组件智能化: 智能化是组件独立实现特定目标的能力。在 CI框架中,每个类和它内部的函数高度地自治。

这些是Rick开发CI要实现的目标, 他们也会成为你开发你自己的网站时的目标。实现这些目标之后,你代码中使用这些类时就不需要担心有什么副作用了。

CI做到了这一点,我的经验是那助手类和类库中的其它类使用用起来十分容易,工作起来效果也不错。

因此, 如果你的控制器直接操作数据库, 或你的在模型层调用视图, CI 代码将会以适当的方式工作-通常没有技术上的问题-但是从MVC理论来看这样似乎是 ‘不正确的’. 不要烦恼,如果非要这样做,做吧!

CI 的网站结构: 控制器和视图

你的整个 CI 网站是动态的。 就是, 可能找不到制作 ‘静态’ 网页的简单的 HTML 代码。 (如果需要你可以添加,但是他们将会在 CI 结构之外.) 那么, 你的网站文件到底在哪里?

当我们安装 CI 的时候,我们注意到应用目录包括名为models、views和controllers的子目录。 每个 CI 框架应用都包含这三大类型。

标签: , ,

使用CodeIgniter框架快速开发PHP应用:分析网站结构(1)

转贴自CI中国

分析网站结构

既然我们已经安装 CI ,我们开始了解它如何工作。
读者已经知道 CI 实现了MVC式样。 通过对目录和文件的内容进行分类, 而不是让代码大块大块地纠集在一起。
这一章,我们将会对 MVC 理论做个简短的介绍, 然后再介绍 CI 的MVC实现方式。特别地,要了解那些目录和文件如何互相交换信息?网站结构是怎样的?以及CI是如何自如地动作于其中的?

这一章将会介绍:

。MVC 如何架构一个动态网站
。CI如何接收和分析request以及如何调配指定的代码来reponse
。这些指定的代码如何编制
CodeIgniter 语法
。CI提供的各种类和函数,你自己编写的类和函数
。如控向controllers传递URL参数
。如何编写运行良好的视图并把动态内容传递给它们。
。如何返回信息给上网者
。文件和类如何传递信息和互相调用
。助手类文件有什么用?
。有助于网站设计的一些特别提示

MVC-到底有什么用?

MVC,在本文领域内,指的是一个动态网站的组织方法。 设计模式是1979年由挪威人,Trygve Reenskaug首次提出来的,这里是一些概要:
。模型是包含数据的对象,他们与数据库交互,对这些数据进行存取,使其在不同的阶段包含不同的值,不同的值代表了不同的状态,具有特定的含意。
。视图显示模型的状态,他们负责向使用者显示数据。(虽然他们通常是 HMTL 视图, 但是,他们可能是任何形式的接口。 比如PDA屏幕或WAP手机屏幕)
。控制器用来改变模型的状态,他们操作模型,提供动态的数据给视图。
CI框架包含模型、视图和控制器的子目录。 他们里面的每个文件都有.php文件后缀, 包含有特定命名约定的类。
CI 帮助你遵循MVC的约定, 使你更有效地组织代码。 CI允许你有最大的灵活性,你可以获得 MVC 结构的所有好处。
当你编程的時候,试着始终用 MVC 来思考问题。尽可能确保你的 ‘视图’ 聚焦于显示, ’控制器’纯粹地用来控制数据流。 把应用逻辑保留在数据模型和数据库中。

这样,如果你决定开发新的视图,你不必在任何一个控制器或模型中修改代码。 如果你需要更新 ‘商业规则’ ,你只需要在模型中修改代码。

标签: , ,

;)

C/C++还是最棒的

Object Pascal也不错,至少目前Free Pascal的发展比Delphi的命运好像好一点

Python易学易用,语法太灵活了,缩进还是没有;号爽

UML 2.0还没有达到易用,易懂的程度,也许以后描述问题不用它了吧

PHP做网站很不错,CodeIgniter框架也不错,就是对XHTML的支持,特别是UTF-8的支持不是很理想。

标签: , , , , , , ,

星期四, 五月 01, 2008

CodeIgnitor,管理你的应用程序

默认情况下,你会将应用程序放入system/application/中,并且可能用 CodeIgniter 只管理这一个应用程序。当然,多个应用程序共享一个 CodeIgniter, 甚至对 application 文件夹进行重命名或更换路径也是可行的。

对应用程序文件夹重命名

如果你要对 application 进行重命名, 你可能还要打开 index.php 文件,对变量 $application_folder 也要进行更改:

$application_folder = "application";

更改你的应用程序的文件夹路径

你可以将 application文件夹从system 文件夹中挪放到服务器的其他的位置。但是你还要更改 index.php 文件里将$application_folder变量设置为服务器的全路径

$application_folder = "/Path/to/your/application";

在一个 CodeIgniter 下运行多个应用程序

如果你想要多个应用程序共享同一个 CodeIgniter, 你要将 application 下所有的文件夹放在不同的应用程序的文件夹内。

例如,你要建立两个应用程序 "foo" 和 "bar",你的应用程序文件夹的结构可能会像下面的这样:

system/application/foo/
system/application/foo/config/
system/application/foo/controllers/
system/application/foo/errors/
system/application/foo/libraries/
system/application/foo/models/
system/application/foo/views/
system/application/bar/
system/application/bar/config/
system/application/bar/controllers/
system/application/bar/errors/
system/application/bar/libraries/
system/application/bar/models/
system/application/bar/views/

要选择使用某个应用程序,你需要打开主 index.php 文件,并且设置 $application_folder 变量为目标路径。例如,通过如下设置,就可以选择使用 "foo" 应用程序:

$application_folder = "application/foo";

注意: 每一个应用程序都会需要它自己的index.php文件来调用他的目标程序。你可以随意对 index.php 文件进行命名。

http://codeigniter.org.cn/user_guide/general/managing_apps.html

标签: ,

星期一, 四月 28, 2008

什么是 Kohana? Kohana 与 CodeIgniter 的区别?

作者:沧蓝 / Fred Wu

Kohana 是一款基于 CodeIgniter 的 PHP5 框架,其与 CI 最大的区别便是 Kohana 完全采用 PHP5。

2007 年 6 月 1 日,CI 社区用户 Todd Wilson (Tido) 发布了 BlueFlame 1.0 的帖子。BlueFlame 1.0 正式发布,团队成员有九人,其中包括 Todd(原团队 lead developer)、现在 Kohana 的 lead developer、以及本人。该发布贴引起了 CI 社区用户的广泛关注。然而由于 BlueFlame 团队事前没有与 CodeIgniter 团队进行沟通,导致一些理解上的小插曲,包括 Rick (CI 的祖父)要求 BlueFlame 团队停止使用 CI 的社区资源来发布 BlueFlame 相关的信息,以及对 BlueFlame 源代码中的授权部分表示疑义。

最终通过 BlueFlame 与 CodeIgniter 团队的协调沟通,双方的小小误解很快便被解化。Rick 在此期间提到 BlueFlame 名称的潜在版权问题,于是 BlueFlame 几天后便正式更名为 Kohana,并注册了现在的官方网站:kohanaphp.com

在 BlueFlame 1.0 之后,Kohana 团队一直没有发布新的版本,之后整个项目一度处于僵化期。尽管如此,trac 上还是有更新进度。在 Todd Wilson “消失”了一阵子后,成员之一 Woody Gilk (Shadow Hand) 接下重任,担当团队 leader。

之后 Woody 联络本人,希望本人承担 Kohana 官方网站以及 logo 的设计制作。论坛上仍然可以找到当时我发的帖子(内有网站以及 logo 的草案)。可惜由于时间的因素,我最终没有将设计草案转化为 HTML。可喜的是,Geert De Deckere 之后设计了一个相当出色的方案,这也就是大家现在所见到的 Kohana 的官方网站。 :)

2007 年 11 月,经过了团队成员以及社区用户的努力,Kohana 终于发布了 2.0 版本。

下面我来翻译一下 Wikipedia 对于 Kohana 的介绍。

历史

Kohana 是基于 CodeIgniter PHP 框架开发的。

开发 Kohana 最主要的原因是 CI 对于 bug 的修复和处理用户提交的建议所需的时间过长。许多 bug 在用户报告后很久才会纳入到新版本中,甚至一些 bug 一直没有被纳入。另外,由于 EllisLab 是 CodeIgniter 唯一开发者,部分用户对于框架的开放性产生异议,他们希望框架可以更自由开放,从而使社区对框架的发展产生一定的影响。

Kohana 与 CodeIgniter 的区别


  • 严谨的 PHP5 面向对象编程。优势:可见性保护、自动类装载、超载、接口类、抽象类以及单件类。
  • 延续 CodeIgniter 的设计模式。CodeIgniter 的用户能迅速的理解 Kohana 的架构和设计模式。
  • 社区向,而非商业向。Kohana 是一款基于社区的作品。Kohana 的开发者们来自世界各地,有着各自的天赋。这使得开发速度得以提高,并在短时间内提供bug修复以及反馈用户提出的建议。
  • GET、POST、COOKIE 以及 SESSION 数组得到改进。Kohana 不对全局数据做读取限制,但依旧提供与 CodeIgniter 相同的数据过滤以及 XSS 防护。
  • 层叠式资源、模块以及类继承。控制器、数据模型、库、助手以及视图均能够在系统中的任何地方进行载入。程序的配置选项可被继承或覆盖。
  • 无命名空间的冲突。类均添加了如“_Controller”之类的后缀,从而使得用户的控制器和数据模型可被同时同地装载。
  • 真正的自动类装载。这包括库、控制器、数据模型以及助手。与 CodeIgniter 不同,Kohana 的自动装载是真正意义上的动态装载,而并非预先装载。
  • 助手为静态类,而非函数。例如,在 CI 中使用的 form_open(),在 Kohana 中为 form::open()。
  • 库驱动以及 API 的一致性。库能够使用不同的驱动来处理不同的外部 API。例如,session 的储存有数据库、cookie 和 native 几种,但它们均使用相同的接口。这使得库可以不断的添加新的驱动,但不会影响到 API 的一致性。
  • 强大的事件处理器。Kohana 的事件可被动态的添加、替换或删除。这使得用户能在 Kohana 执行的过程中动态做更改,而不影响原有的系统代码。


特性


  • 高安全性
  • 轻量级代码
  • 学习周期短
  • MVC 设计模式
  • 100% UTF-8 兼容
  • 松弛耦合架构
  • 易扩展性


技术


  • 严谨的 PHP5 面向对象编程
  • 用 SQL 助手实现简单的数据库抽象层
  • 多 session 驱动(native、数据库、cookie)
  • 动态事件处理器


==============================

最后更新:2007 年 12 月 03 日

http://codeigniter.org.cn/forums/thread-91-1-1.html

标签: , , , , , ,

Notes on Choosing a PHP Framework: A Quick Comparison of CodeIgniter and Kohana

When I was reading through my subscribed feeds I came across this post: Notes on Choosing a PHP Framework: A Comparison of CakePHP and the Zend Framework by Chad Kieffer.

Chad has done a great job comparing the two frameworks that he’s interested in. That inspired me to write something up for the frameworks that I prefer and use. :)

I began hunting for PHP frameworks ever since Ruby on Rails hit the street. Coincidentally one of the first PHP frameworks I played with was CakePHP. At that time CakePHP’s documentation was nearly non-existent so I had to seek for an alternative. I did a lot of searches, and researches, and finally I was happy to see CodeIgniter. Its user guide was what impressed me the most, I am sure many of the fellow CI users would agree with me on this one. Because of the excellent documentation, I was able to start working on projects right after I spent a few hours on the user guide! Developing apps on CI was such a breeze! Today, I develop web applications in CodeIgniter, Kohana and Zend Framework. If you want to find out how to use Zend Framework components with CI or Kohana, please read my previous blog entry: Using Zend Framework with CodeIgniter.

From version 1.2 when I first started coding on CI, to the newly released version 1.6.1 it sure is a long way. CodeIgniter has progressed well and gained many web developers’ trust, despite a few glitches. One of which was the spawn of the fork: Kohana.

CodeIgniter had some low periods where developers were all focused on pushing out new releases of ExpressionEngine, their commercial blogging/cms product. Some of the users on the CI forum got frustrated because their bug reports and feature requests were ignored. As a result of that, BlueFlame was born, and later renamed to Kohana.

Kohana is relatively unknown to the public. In fact, most of the Kohana users are ex-CI users or users that uses both CI and Kohana (like myself). According to the Kohana homepage and Wikipedia, the differences between Kohana and CodeIgniter are:

  1. Strict PHP5 OOP. Offers many benefits: visibility protection, automatic class loading, overloading, interfaces, abstracts, and singletons.
  2. Kohana has joined the GoPHP5 initiative. All releases from 2.2 on will conform with this project.
  3. Continues CodeIgniter design patterns. Anyone who has used CodeIgniter will quickly understand Kohana’s structure and design patterns.
  4. Community, not company, driven. Kohana is driven by community discussion, ideas, and code. Kohana developers are from all around the world, each with their own talents. This allows a rapid and flexible development cycle that can respond to bugs and requests within hours, instead of days or months.
  5. GET, POST, COOKIE, and SESSION arrays all work as expected. Kohana does not limit your access to global data, but offers the same filtering and XSS protection that CodeIgniter does.
  6. Cascading resources, modules, and inheritance. Controllers, models, libraries, helpers, and views can be loaded from any location within your system, application, or module paths. Configuration options are inherited and can by dynamically overwritten by each application.
  7. No namespace conflicts. Class suffixes, like _Controller, are used to prevent namespace conflicts. This allows a User’s controller and Users model to both be loaded at the same time.
  8. True auto-loading of classes. This includes libraries, controllers, models, and helpers. This is not pre-loading, but true dynamic loading of classes, as they are requested.
  9. Helpers are static classes, not functions. For example, instead of using form_open(), you would use form::open().
  10. Library drivers and API consistency. Libraries can use different “drivers” to handle different external APIs transparently. For example, multiple session storage options are available (database, cookie, and native), but the same interface is used for all of them. This allows new drivers to be developed for existing libraries, which keeps the API consistent and transparent.
  11. Powerful event handler. Kohana events can by dynamically added to, replaced, or even removed completely. This allows many changes to Kohana execution process, without modification to existing system code.

As you can see, whilst maintaining a certain level of similarity to CodeIgniter, Kohana does offer some advantages (at the same time, some disadvantages). Let’s take a look at a few quick comparisons. Grading scale: Limited <>

Feature Comparison of CodeIgniter and Kohana
Feature CodeIgniter 1.6.1 Kohana 2.1.1 Notes
License Apache/BSD-style new BSD Licenses are similar, although Kohana uses the new BSD license which is slightly more flexible than CI’s modified BSD license.
PHP compatibility 4.3.2+ and 5 5.1.3+ CodeIgniter supports PHP4 whilst Kohana is a stict PHP5 framework. If you are using PHP5 then Kohana offers more OOP and performance advantages. Start from version 2.2 (yet to be released), Kohana will only support PHP 5.2+.
Supported Databases MySQL (4.1+)
MySQLi
MS SQL
PostgreSQL
SQLite
Oracle
ODBC
MySQL
PostgreSQL
SQLite
CodeIgniter’s longer history ensures us a more widely available database support options than Kohana, although in the future Kohana is likely to support more databases too.
Community Forum
Wiki
Bug Tracker
Forum
Trac
IRC
CodeIgniter obviously has a much larger community and offers a wiki for community members to share tutorials and code snippets. Kohana on the other hand, has a smaller community, however the developers are actively online on the forum and IRC.
Documentation / User Guide Excellent Limited CodeIgniter is known for its excellent user guide. Kohana is in the process of improving its documentation.
Tutorial / Sample Availability Good Fair Tutorials are available on both of their forums. CodeIgniter has the advantage of having a wiki for easier navigation. Kohana on the other hand, has a dedicated tutorial page for some of the tutorials.
MVC Strict Strict Both frameworks use the same MVC approach.
Modular / HMVC Via 3rd party libraries Built in Kohana is built with HMVC in mind whilst CodeIgniter has some 3rd party libraries such as Matchbox and Modular HMVC to accomplish the same effect.
Conventions Flexible Flexible Unlike CakePHP, both of the frameworks offer flexible convensions. There are some defaults but most of them can be overwritten.
Configuration PHP files PHP files In my opinion Kohana is more configurable than CodeIgniter yet it is simpler (less clustered) to do so! Most of the Kohana configuration files are stored in the system folder, you only copy and paste the ones you actually need to modify, and modify them accordingly. CodeIgniter’s config files are all stored in the application folder.
Database Abstraction Modified ActiveRecord Modified ActiveRecord
ORM (optional)
Both frameworks use the modified ActiveRecord pattern. Kohana has an optional ORM module. CodeIgniter has some ORM and Rails-style ActiveRecord implementation avaliable via 3rd party libraries.
ACL Via 3rd party libraries Auth library (optional) Neither of the frameworks forces you to use a specific ACL mechanism. CodeIgniter does not have one built in, and Kohana has one available as an optional module.
Validation Good Good Both frameworks offer a good built in validtion layer. Kohana 2.2 is planned to have some significant improvements for the validation library.
Caching Limited Fair In my opinion both of the caching features are limited. Kohana offers a slightly more useful cache library that supports file, SQLite, APC, eAccelerator, memcache, and Xcache based caching, with tag support.
Session Good Excellent CodeIgniter 1.6 has improved its session library, but it’s still inferior to Kohana’s implementation. Kohana’s session library supports both encryption and storing session data in database.
Logging / Debugging Good Excellent Both frameworks offer very good logging and debugging mechanisms. Kohana is a little bit ahead thanks to PHP5’s native Exception class and its powerful event handlers.
Templating Native PHP Native PHP Templating is *very* easy for both frameworks. If you can skin Wordpress, then you’d have no problems at all skinning CI or Kohana. If you want though, you can still incorporate one of the 3rd party templating solutions such as Smarty.
Helpers Good Good Helpers are usually libraries that used for simple, repetitive tasks. Both frameworks offer a wide range of helpers for handling forms, URLs and dates, etc.
JavaScript / AJAX N/A N/A Both frameworks respect your choice of JavaScript / AJAX frameworks. Unlike CakePHP and Ruby on Rails, they don’t have built-in helpers for any of the JavaScript libraries. This offers more flexibility as well as the use of unobtrusive JavaScript.
Web Services Fair Fair I could be wrong but I don’t think either framework supports (or at least encourages) RESTful design…
Localization Limited Good CodeIgniter has limited i18n support whilst Kohana offers a bit more (timezone / full UTF8 layer, etc).
Unit Testing Limited None * CodeIgniter’s built in unit testing class is very limited. * Kohana as of version 2.1.1 does not have a unit testing class, however it is planned for version 2.2.

The Verdict

I had a hard time deciding which of these two I use. In the end, I chose to use both. Why? Because they each have its advantages and disadvantages.

CodeIgniter is great for small to medium sized projects, especially good for legacy servers which have PHP4 installed. The fantastic user guide made coding in CI very efficient.

Kohana is probably better for larger sized projects as well as projects that need more flexible extensions. PHP5 offers better (proper) OOP support as the foundation, plus Kohana’s several better feature implementation make it a strong competitor to its predecessor.

There is no right or wrong for which framework you use, everyone has its own taste. For me, CodeIgniter’s excellent documentation and Kohana’s strict PHP5 + easy to use are the primary reasons to choose them over say, CakePHP and Symfony. That said, CakePHP, Symfony and other frameworks are all excellent choices depending on your taste and experience. On one hand I envy the Ruby community because they obviously have the de facto framework to work with, on another hand, we have more options hey? :)

Feel free to share your opinion and experiences!

Update log:

[2008-02-23]
- Removed MS SQL support for Kohana (confirmed by Shadowhand)
- Updated cache driver description for Kohana (confirmed by Shadowhand)
- Edited unicode / UTF8 description for Kohana (confirmed by Shadowhand)

These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • DZone
  • Furl
  • Live
  • Reddit
  • Slashdot
  • Spurl
  • StumbleUpon
  • Technorati
  • YahooMyWeb

标签: , , ,

CodeIgnitor: Query String URL Enhancement

Hi everybody,

I had a problem described in my last post:
http://codeigniter.com/forums/viewthread/68197/

This problem forced me to use query strings and the url I had to parse was as follows:
http://www.mysite.com/index.php?c=mycontroller&m=processAuth&auth_token=3c562b119bd387ec194ade6bab9832c4

I enabled query strings in my config file:
$config[’enable_query_strings’] = TRUE;
$config[’controller_trigger’] = ‘c’;
$config[’function_trigger’] = ‘m’;

I still had issues getting to the auth_token value.

In the end I changed some code in the Router.php file and wanted to submit the code here in case anyone else finds it useful. It makes query strings act pretty much the same as the regular CodeIgniter URLs. For example, if you had a controller like:

class myClass extends Controller {
function myFunction ($myValue) {
}
}

Normally, you could call myFunction with a value using a CodeIgniter URL:

www.mySite.com/index.php/myClass/myFunction/123456

With the changes I made to router.php, you can now call it with:

www.mySite.com/index.php?c=myClass&m=myFunction&value=123456

The way the changed code is written now, you only need the “controller_trigger” key in the query string. The other keys do not matter. The values will go into the segment array in the order they show up in the query string.

There are a few improvements that could be made but what’s there now is a good start.

I can’t seem to attach the changed Router.php file (renaming or zipping didn’t seem to matter). But I only changed the _set_route_mapping() function commenting out the following code at the top:

/*
// Are query strings enabled in the config file?
// If so, we're done since segment based URIs are not used with query strings.
if ($this->config->item('enable_query_strings') === TRUE AND isset($_GET[$this->config->item('controller_trigger')]))
{
$this->set_class(trim($this->_filter_uri($_GET[$this->config->item('controller_trigger')])));

if (isset($_GET[$this->config->item('function_trigger')]))
{
$this->set_method(trim($this->_filter_uri($_GET[$this->config->item('function_trigger')])));
}

return;
}
*/

and adding the following code near the end of the function:

// check if query strings enabled
if ($this->config->item('enable_query_strings') === TRUE AND isset($_GET[$this->config->item('controller_trigger')]))
{
// at this point the uri_string is the query string
$keyValues = split('&', $this->uri_string);
foreach(
$keyValues as $keyValue) {
list($key, $value) = split('=', $keyValue, 2);

// just use the value and add in the order they come in
// at some point may want to utilize keys and ignore order

$value = trim($this->_filter_uri($value));

if (
$value != '')
$this->segments[] = $value;
}

}
else {

the code above goes just above:

// Explode the URI Segments. The individual segments will
// be stored in the $this->segments array.
foreach(explode("/", preg_replace("|/*(.+?)/*$|", "\\1", $this->uri_string)) as $val)
{
// Filter segments for security
$val = trim($this->_filter_uri($val));

if (
$val != '')
$this->segments[] = $val;
}

}
// do not forget this bracket

make sure to add the closing bracket

Hope someone finds it useful.

http://codeigniter.com/forums/viewthread/68698/

标签: ,

辽ICP备05003652号
流风洄雪听天籁,轻云蔽日看落花

Powered by Blogger