Magento – Rewrite 运行机制

 

看一个url例子
http://localhost/magento/index.php/cust … ount/login
这里假定http://localhost/magento/ 是magento安装目录。那么Magento将自动转而执行customer模块下名字AccountController的loginAction方法。这个是ZendFramework的默认重写规则。
另外一个产品详细页的例子
http://localhost/magento/index.php/cata … category/3
Magento将寻址catalog模块的ProductController的viewAction方法,传入参数id和category.
为了搜索引擎更加友好化,我们可能希望用用下面的url同样访问到该产品
http://localhost/magento/index.php/bask … -gold.html
Magento 重写了ZendFramework的机制完成这个功能,它的实现思路是:当发送请求的时候,Magento首先判断 basketball/tayshaun-prince-signed-auto-baketball-with-coa-gold.html是否在数据库core_url_rewrite表中是否有该route path和实际target path映射记录,没有的话,就使用Zend Framework的重写规则寻址相应的php执行代码。
为了窥视它的Rewrite机制, 还着实费了不少力气,但是也只是懂些皮毛。下面说说我分析这个机制的过程:
仍然以访问 http://localhost/magento/index.php/basketball/tayshaun-prince-signed-auto-baketball-with-coa-gold.html
为例
1. 从magento安装目录下的index.php开始,末尾的Mage::run();很显然是程序的入口。
2. 打开app/Magento.php查看run()函数尝试在不同的位置输出self::_$app属性(是一个类),看看有没有url关键字basketball,结果发现多处子对象有字符串属性包含它:

  1. Mage_Core_Controller_Request_Http
  2. ->_originalPathInfo = “/basketball/tayshaun-prince-signed-auto-baketball-with-coa-gold.html”
  3. ->_requestString = “/basketball/tayshaun-prince-signed-auto-baketball-with-coa-gold.html”
  4. ->_requestUri = “/magento/index.php/basketball/tayshaun-prince-signed-auto-baketball-with-coa-gold.html”
  5. ->_pathInfo = “catalog/product/view/id/1/category/3″

复制代码

那么为了完成映射,程序必须有一处读取其中一个属性(原始url串),然后进行解析和转换。这是着实有点迷惑了,四个属性,到底哪一个才是关键的呢?

3. 打开Mage_Core_Controller_Request_Http类

文件

,先从_originalPathInfo入手(因为名字带了一个 original),找到getOriginalPathInfo(), 该方法调用了setPathInfo(), 这么说这个方法应该是

设置

_pathInfo的函数了,结果这个发现该方法先调用getRequestUrl方法初始化属性

_requestUri,这个是url源头,然后运算出如下属性:

_originalPathInfo

_requestString

_pathInfo

4. 接着全目录搜索调用getOriginalPathInfo的类方法,找到类Mage_Core_Controller_Varien_Router_Standard。打开调用方法为match,浏览了下整个函数内容,发现了如下代码

  1. $request->setModuleName($module);
  2. $request->setControllerName($controller);
  3. $request->setActionName($action);

复制代码

由此可以猜测出,对于该例子,这里应该有如下的映射:

  1. $module = ‘catalog’;
  2. $controller = ‘ProductController’;
  3. $action = ‘viewAction’;

复制代码

所以下面的就是要找出$moudle变量是如何计算出来的

5. 找到上面初始化$module的位置

$module = $request->getModuleName();

一定是$request的属性被某处初始化,才使得 $request->getModuleName()返回module名字。

于是代码定位到前面的
$p = explode(‘/’, trim($request->getPathInfo(), ‘/’));

6. $request是Mage_Core_Controller_Request_Http类的实例,打开它的getPathInfo方法。

……哈哈

线索中断,其实这种分析方法是不

推荐

的,完全没有程序员逻辑

线索II.

1. 从Mage::run()方法开始,程序员可以敏感地意识到下面代码的关键性

  1. Mage::run() {
  2. self::app()->getFrontController()->dispatch();
  3. }

复制代码

2.打开Mage_Core_Controller_Varien_Front的 dispatch方法

  1. class Mage_Core_Controller_Varien_Front{
  2. function dispatch() {
  3. ….
  4. Mage::getModel(‘core/url_rewrite’)->rewrite();
  5. ….
  6. while (!$request->isDispatched() && $i++<100) {
  7. foreach ($this->_routers as $router) {
  8. if ($router->match($this->getRequest())) {
  9. break;
  10. }
  11. }
  12. }
  13. }

复制代码

3. Mage::getModel(‘core/url_rewrite’)可以定位到Mage_Core_Model_Url_Rewrite类文件

  1. class Mage_Core_Model_Url_Rewrite {
  2. public function rewrite() {
  3. $this->loadByRequestPath($requestCases);
  4. ……
  5. if (!$this->getId()) {
  6. // debug code
  7. var_dump($requestCases);
  8. exit();
  9. return false;
  10. }
  11. ….
  12. $request->setPathInfo($this->getTargetPath());
  13. return true;
  14. }
  15. }

复制代码

如 果 $this->loadByRequestPath($requestCases);从数据库中core_url_rewrite表查找是否有对应 的target_path,如果找不到return false(用默认的rewrite机制),这里应该是可以找到targe path的,即

catalog/product/view/id/1/category/3

4. 继续回到dispatch()方法,代码

if ($router->match($this->getRequest()))

$router 是Mage_Core_Controller_Varien_Router_Standard的实例,方法match如下:

  1. public function match(Zend_Controller_Request_Http $request) {
  2. ….
  3. // set values only after all the checks are done
  4. $request->setModuleName($module);
  5. $request->setControllerName($controller);
  6. $request->setActionName($action);
  7. }

复制代码

上面代码显而易见,到此代码分析结束。

结论:此次分析是推论+推测(瞎蒙,瞎蒙就是全文搜索匹配字符串确定调用和被调用关系),没有使用任何单步调式工具。

那么分析Rewrite机制对于扩展Magento的意义何在呢? 比如,如果你想为产品增加品牌

分类

,那么你可能需要定义如下的符合SEO的

URL

http://localhost/magento/index.php/ibm/

使之映射到

http://localhost/magento/index.php/catalog/brand/id/2

此时,你就要定义重写机制使两个URL的映射关系保存到数据库表中。

 

 

 

 

1

Mage_Core_Controller_Request_Http

 

2

接着全目录搜索调用getOriginalPathInfo的类方法,找到类Mage_Core_Controller_Varien_Router_Standard。打开调用方法为match,

3

Mage::run()

 

  1. Mage::run() {
  2. self::app()->getFrontController()->dispatch();
  3. }

 

4

 

  1. class Mage_Core_Model_Url_Rewrite {
  2. public function rewrite() {
  3. $this->loadByRequestPath($requestCases);

 

 

 

 

 

$router 是Mage_Core_Controller_Varien_Router_Standard的实例

 

源码链接: https://pan.quark.cn/s/a4b39357ea24 斐讯K2是一款广受用户青睐的无线路由器,其运行表现稳定且具备较高的可操作性,在DIY爱好者群体中拥有极高的声誉。本资料将系统性地阐述斐讯K2的固件刷机方法及其关联的技术要点。固件升级是路由器爱好者改善设备性能、扩展功能的一种普遍手段,经由替换出厂固件,能够达成更加个性化的网络配置、增强安全防护等目标。斐讯K2固件资源库涵盖了多种知名的非官方固件,诸如Tomato Pheonix 不死鸟、高恪、PandoraBox 潘多拉等,这些固件均具备独特的优势,能够适配不同用户的需求。 1. Tomato Pheonix 不死鸟:Tomato是一款立足于Linux的开源固件,以其精巧、高效而备受推崇。不死鸟版本是专门为华硕及斐讯路由器优化的分支,提供了卓越的QoS(服务质量)配置、详尽的图表监控以及便捷的固件升级途径。对于那些需要精准调控带宽和监测网络状态的用户而言,这是一个理想的选项。 2. 高恪:高恪固件是OpenWrt的定制化版本,着重于操作的便捷性和运行的可靠性,特别适合对路由器操作不甚熟悉的用户群体。它提供了一些实用的功能,例如内置的广告屏蔽、快速测速工具等,同时保留了OpenWrt的适应性。 3. PandoraBox 潘多拉:潘多拉盒是另一款基于OpenWrt的固件,它以丰富的插件库和强大的自定义潜力而闻名。用户能够依据个人需求安装各类插件,实现更多功能,如远程接入、DDNS(动态域名解析服务)等。 4. 官方固件的纯净版本与定制版本:官方固件通常更侧重于稳定性,纯净版意味着未预置额外的应用或服务,适合注重稳定性的用户。定制版则可能包含了制造商的特色功能或优...
源码下载地址: https://pan.quark.cn/s/926926948560 AS3.0与XML结合的通用图片滚动功能,是一种基于ActionScript 3.0和XML技术的动态图像展示方案,非常适合初学者进行学习和实践应用。此项目的关键在于借助XML文件作为数据媒介,用来保存图像的相关参数,例如图像的链接地址、展示的次序等,接着在AS3.0环境中对XML进行解析,并动态地载入和展示这些图像,达成图像的滚动或是循环播放的目的。 我们需要明确ActionScript 3.0(AS3.0)是Adobe Flash Professional以及Flex Builder等开发工具中采用的编程语言,用于构建交互式内容以及丰富的互联网应用。相较于先前的版本,AS3.0在性能上有了大幅度的提升,并且引入了更为规范的面向对象编程模式,涵盖了类、接口以及包等概念。 XML(可扩展标记语言)是一种简明且高效的数据传输格式,既便于人类阅读和编写,也易于机器进行解析和生成。在该项目中,XML文件用于存储图像数据,例如图像的URL、延时的时长、动画的样式等,通过这种方式可以将数据与程序代码分离,从而增强代码的可维护性与可扩展程度。 实施这一图片滚动功能,主要涉及到以下AS3.0的核心知识点: 1. **XML解析**:运用`XML`类来载入并解析XML文件,从而获取图像的清单。AS3.0提供了简便的API来操作XML节点,例如`children()`、`attributes()`等,用以获取子节点和属性值。 2. **事件监听**:借助`EventDispatcher`类来监控载入和解析过程中的事件,比如`Event.OPEN`、`Event.PROGRESS`、`Event...
内容概要:本文介绍了软件许可管理的技术实现方式及相关工具资源,重点阐述了加密外壳(EMS)和API加密两种保护机制。加密外壳通过将程序(如.exe、.dll、.apk)封装在加密壳中,实现运行时内存解密,防止静态反编译和代码篡改,同时支持对数据文件、系统参数及部分代码的加密,并依赖硬件锁(HL)或软件锁(SL)进行授权控制。API加密则通过在代码中嵌入安全验证调用,确保授权合法后才执行核心逻辑。文章还说明了锁的类型(HL/SL)、模式(有驱/AdminMode与无驱/UserMode)、升级路径以及虚拟时钟功能,并描述了产品授权流程从功能定义到产品创建、授权生成的全过程,支持通过C2V文件或锁ID复制已有授权状态。文中附带多个开源平台链接和技术博客参考资源。; 适合人群:从事软件版权保护、授权系统开发或安全技术研究的研发人员,尤其是具备一定逆向工程、软件安全基础的1-3年经验开发者。; 使用场景及目标:①构建安全的软件授权体系,防止盗版和非法使用;②实现灵活的功能授权管理(如时效、并发、硬件绑定);③选择合适的加密方案(硬件锁/软锁、有驱/无驱)并集成到现有产品中;④学习加密外壳与API验证的实际应用方法; 阅读建议:此资源侧重于软件许可的技术架构与实施细节,建议结合提供的GitHub、Gitee项目链接及CSDN技术文章深入理解实现原理,并通过实际调试加密壳和模拟授权流程加强实践能力。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值