User Tools

Site Tools


products:stewload:walkthru

Notes

Random thoughts, ideas and advice

Source compare tools

Windows: Beyond Compare

Mac: Delta Walker

These tools are invaluable. They perform three-way comparisons and allow instant editing and copy or moving lines.

You are going to end up with three scripts at the time of upgrade: your custom mods, the old version, and the new version. Of course you do not need to compare all three at once, you can work in stages.

The key point is that familiarity with your tools will dictate how you manage your mods.

For bug fixes, I find it best to simply replace the entire script and make the changes directly. Do not extend the class as if you were adding new features. Then the compare tools serve you better to spot whether or not a later release obviates the need for your mod.

On the other hand, if you are extending a class, you do not expect changes from fox, so it makes sense to use OOP.

Train your compare utility to ignore the version line generated by SVN at the top of every script. We find the following regular expression works for us.

^\s+\*\s+\@version.*

Extending a class

There are at least two ways to go.

#1

Rename the original class by prepending “PF_”, as in eg class PF_Fox_Stuff

In the same file, below the original class, create a new class, eg class Fox_Stuff extends PF_Fox_Stuff

#2

At the top of your extended class, require the old script, and create your own with a custom name:

require(PHPFOX_DIR_LIB_CORE . 'file' . PHPFOX_DS . 'file.class.php');

class Custom_File extends Phpfox file
{
...

The second method is good when the original class has been declared with object extension in mind.

As of 377, most fox classes were not. They have many private variables or methods that your extended class will need.

So even if method #1 is hokey, it allows you to expose what is needed from the original class, as needed.

Phpfox stores all instantiated objects and libraries in a hash table. It maps the dot-notation class id to a hash which gives it the object.

The point is that you can have a class called My_Custom_File and Phpfox::getLib('file') is still going to work.

Phpfox never uses real class names such as User_Service_Group_Setting_Setting→add()

Futures

Issues we noticed, attempting to make a “hack free” solution.

* Infinite recursion Plugin::get() needs to call getLib() which calls Plugin::get() etc

* Libraries are loaded before the Plugin system is initialized.

* Libraries loading is hard-coded in init.inc

* The module system for callbacks completely avoids the loader. It's all hard-coded.

* Class identifiers such as “user.group.setting” cannot be logically resolved without hitting the file system.

products/stewload/walkthru.txt · Last modified: 2014/06/30 10:51 by steward