许多人应该ecshop并不陌生，它粉丝不少。它对我php的入门学习帮助不少，在此非常感谢它的开源（http://www.ecshop.com)！

总的来说，它的架构清晰，易扩展，可以适合二次开放大型应用的雏形。但它细节的东西还比较粗糙，逻辑任务分解不到位（有些代码块太长，冗余多），稳定性欠佳。我这也是很笼统的说它缺点，它的程序对于入门不久phper也是很容易阅读。本人文笔不够，建议去看它，就知道其中缺点，更能学到许多有用的东西。到时欢迎讨论。也是希望可以帮助改进ecshop，支持开源！

下来就说点ecshop的问题，挑个它模板机制吧，它是模板机制核心在includes/cls_template.php，是改写smarty模板引擎的。改得不错，很方便，Just for it。它里面的诸多细节还需要改进。

它有个动态库文件，就是可以后台添加，删除在前台某个区域显示的内容。如添加广告显示，某类的产品等呀。所以，它不是实时显示内容（不进行缓存）。

这个处理它在cls_template.php中template类的smarty_prefilter_preCompile（）方法，在这方法中，对动态库文件的处理，仅仅是加入smarty标签，如｛assign var=”” value=”” ｝，然后，比如首页index.php, 写起控制程序的时候，又写了并调用了assign_dynamic()函数，里面不干什么，也是注册动态库的smarty变量。这里虽然通过一个“桥”，来实现对相同的smarty的变量赋值不同的值（如{assign var=”cat_goods”  value=”cat_goods_’. $id .'”}（smarty_prefilter_preCompile()方法实现）, $smarty->assign(‘cat_goods_’.$id, $cat_goods) [assign_dynamic()函数实现])，觉得这不错–对动态添加或删除某个显示内容，但是，smarty_prefilter_preCompile（）的复杂且多的正则开销，每个方法或函数连接数据库的开销，smarty变量命名的不稳定性（如果方法和函数中某个变量写的不一致，就不能对应赋值啦），这些开销省下来，是多么的可观啊！呼呼~，可以省去assign_dynamic()函数，在preg_replace_callback()中的调用函数，在进行匹配处理的时候，就进行相应的赋值。

还有，smarty_prefilter_preCompile（）对动态库文件那么辛苦的工作，就是为了在对应的include的动态库文件前，加入对应{assign var=” value=”}。既然在后台处理模版布局的时候，ecshop对添加的动态文件会在对应的模板，即是对应的.dwt文件里添加<!– #BeginLibraryItem “*.lbi” –>，何不添加一个标识（唯一），在smarty_prefilter_preCompile用str_replace()替换，不轻松许多吗？！

不过，这样也一个弊端，就是对模板可视化编辑的时候，添加的动态库文件不能按原来的规则（即<!– #BgeinLibraryItem ”*.lib” –>, Dreamweaver的模板文件)显示出来。

如果不用标识替换，即保持原来处理方法。在smarty_prefilter_preCompile()方法中，觉得不需要用正则来{include file=”动态库文件”}来前面加上{assign var=”” value=””}，而且还要整个$GLOBALS[‘libs’]来协助。稳定性可想而知了。何不用explode敲入数组处理（处理匹配的第一个就可以，这样说很多人不清楚，它的动态库文件存储在数组中，在某个区域内，相同类型的包含的动态文件是相同的，所以在前面｛assign｝来赋不同的值。在遍历该动态库文件，遇到匹配字符，立即处理便可。）。用处理处理效率高很多，也减少许多不稳定行因素。

再稍稍说下category.php页，有些once write的感觉，很容易看到在相同的应用下调用get_extension_goods()函数许多次，而get_extension_goods()每次都需要和数据库“握握手”。太过奢侈啦！里面可以改进许多，有兴趣者欢迎Email探讨~

以上也是个人看法，自己能力还不够强，还很有待指点。BTW，shopex比ecshop完善许多，可惜不开源。希望ecshop越来越高级，支持开源！

附上改过后的code: ecshop_20101226.zip