Of course, hosting for these patches continues as well as my ThemeableView class which some CakePHP users out there found useful. If anyone else is interested in taking the reins for this class, please feel free to do so. No need to contact me or anything, but a trackback to this post would be nice so that I will know who is currently maintaining this class. This will allow me to direct them to you for any updates that you may post.

On another note, the project that has been taking much of my time lately is a new website for posting free online classified ads for cars, trucks, and bikes. This website is currently US-centric. We have plans to extend worldwide if all goes well with the current setup. So, if you’re in the US and you wish to sell your vehicle, or if you’re looking to buy a preowned car, truck, or bike check out PreOwnedCar.com. If you know someone with the same needs, please tell them about this site.

We are also currently in the final design phases for PhilWeavers Version 4. I am currently divided between doing this new version using Django as a base or simply going back to the drawing board and creating a new PHP5-based framework. We’ll see how this pans out in the later stages of development.

a

It makes me wish CakePHP offered more when it comes to object-relational mapping. How I wish it was as simple as defining your models and running php cake/scripts/bake.php syncdb. CakePHP does it the other way around: you create the database first and then use cake/scripts/bake.php to create your models and views.

I found that Django’s way of doing ORM is significantly faster. You specify your models as Python classes using Django’s modeling API. You run python manage.py syncdb and Django takes care of generating the correct SQL for your database backend. It takes model relationships into account and also generates the correct foreign key constraints. Beautiful!

A similar system should also be possible to implement in CakePHP. I’ve been having a few ideas of how to go about it and hopefully, I can find the time to do them as an add-on to CakePHP 1.2.x (and hopefully, someone else is already working on the same thing).

Here is what I imagine it would look like:

class User extends MetaModel {
    var $username;
    var $password;
    var $lastname;
    var $firstname;
    var $is_active;
    var $is_staff;
    var $is_admin;
    var $created;
    var $updated;

    function __construct() {
        $this->username = FieldFactory::CharField(’Username’, 32, IS_PK, IS_REQUIRED, NOT_NULL);
        $this->password = FieldFactory::CharField(’Password’, 64, NO_INDEX, IS_REQUIRED, NOT_NULL);
        $this->lastname = FieldFactory::CharField(’Last Name’, 64, INDEX, IS_OPTIONAL, NOT_NULL);
        $this->firstname = FieldFactory::CharField(’First Name’, 64, INDEX, IS_OPTIONAL, NOT_NULL);
        $this->is_active = FieldFactory::BooleanField(’Active’, IS_REQUIRED, NOT_NULL, false);
        $this->is_staff = FieldFactory::BooleanField(’Staff’, IS_REQUIRED, NOT_NULL, false);
        $this->is_admin = FieldFactory::BooleanField(’Admin’, IS_REQUIRED, NOT_NULL, false);
        $this->created = FieldFactory::DateTimeField(’Created’, NO_INDEX, IS_REQUIRED, NOT_NULL);
        $this->updated = FieldFactory::DateTimeField(’Updated’, NO_INDEX, IS_REQUIRED, NOT_NULL);
    }
}

FieldFactory would have static methods for instantiating the correct field objects for each type. It would also have methods for generating constraints for implementing many-to-one and many-to-many relationships. I think a new model class is required to be able to do the additional magic without changing the current API.

I haven’t thought about how to implement the analogs of Admin and Meta inner-classes yet. I think those can be done as fields in the model, maybe $this->__meta and $this->__admin. As for QuerySets, Q objects and other classes in the Django DB API those are pretty much doable under PHP.

For SQL generation using the models, I imagine the backend will first load all the model classes found. Then models extending the MetaModel base class are instantiated and introspected to generate the correct DDL statements in database-specific SQL.

This is not a trivial undertaking and will take a lot of planning and thought. Model introspection and ORM should use as much of the existing CakePHP API as possible.

One last thing, if you are working on a similar system for CakePHP leave comments below. Remember: DRY.

a

CakePHP modifications will continue once I finish my current project and once CakePHP 1.2.x.x gets sorted out.

It’s interesting to see the direction that CakePHP 1.2.x.x is currently taking. It seems that most of the functionality I’m am currently working on with my modifications for 1.1.x.x is in the works for 1.2.x.x. Here’s the short list of features that I really need:

• Lazy-loaded models (already backported into 1.1.x.x) — This was one of the major gripes that I had with CakePHP as it loads class files for models that you do not even use. This feature increases performance and reduces memory footprint for very large applications with a large number of models.

• Validator classes — This new feature allows for more complex data validation while maintaining the DRY principle. I never liked the idea of using simple regex strings for data validators. What if I wanted to do more complex data validation? (e.g. query a user database if a username already exists) In my old framework, I used validator classes when handling form data. Each form field has its own validator chain and can include as many validator objects as it needs.

• i18n and l10n — Because it’s a big world out there and not everyone speaks English. There is now the beginnings of an internationalization and localization API in the framework.

• User Authentication — Although it’s not clear yet where this is going, I expect that there would be an extensible authentication framework with support for both simple authentication (username+password) and challenge-response authentication (username+password+challenge token).

Now, if only they could throw in a “standard” regression and unit testing framework and add a generous smattering of metaprogramming constructs into the mix…

I have also been following a very interesting discussion with regards to [using the built-in system ACL in limiting user access to data][acl]. The current ACL system built into CakePHP uses what’s called MPTT or Modified Pre-ordered Tree Traversal to navigate through a network of ACO’s and ARO’s. I have made my own MPTT implementation for the object system in my new CMS.The code for this is not for the faint of heart. Yet, the flexibility that you end up with is well worth the effort.

The current discussion on the list about ACL’s made me look deeper into my MPTT implementation. From what I can gather, it will not scale very well as the number of objects increase as it uses a recursive algorithm when reordering the tree traversal data. So now I’m off to look for a better implementation…

[django]: http://www.djangoproject.com/ “Django Project Home” [acl]: http://groups-beta.google.com/group/cake-php/browse_thread/thread/263d3ffd6fb7533d “Using ACL to limit access to data”

a

Why would this be a problem? Depending on the PHP setup, either CGI binary or Apache module, the server could end up exhausting file handles under heavy traffic. This issue is even worse on a virtual hosting setup. Virtual hosting allows one to run a website for cheap by sharing a server with several other websites. Because of this shared environments, there is the increased risk of file handle exhaustion leading to failed requests not only for the CakePHP-based website, but for the other hosted websites as well.

CakePHP, by default, loads everything it finds in the app/models directory into memory: even if it’s not used for the duration of the request. The only reason I see why this is done is to ensure that associations work automagically. However, simply loading everything into memory can be wasteful. It wastes memory and processing time because the PHP engine has to load and parse all those files, even if most of it is “dead code” anyway. While this is not a problem in most setups, I have seen hosting services where they do “CPU utilization capping”.

As part of my ongoing project to improve on CakePHP to allow for porting of my old framework, I have decided to implement a modification that allows for lazy-loaded models in CakePHP. The modification has two goals in mind:

1. Allow client code that depends on the mainstream CakePHP to work without problems;
2. Consequently, this allows the programmer to decide what gets to be loaded on each and every request and what gets to be lazy-loaded.

To allow for goal number 1, I had to leave the bootstrap code alone. For number 2, I had to modify the way CakePHP models are instantiated from both the controller and the models themselves. The controller instantiates the appropriate model at runtime. A model may instantiate one or more models from its associations model. But how do you do lazy-loading and still allow for the old model loading behavior?

My solution is to create a new directory under the app/models directory called lazy_load. All models to be lazy_loaded will be placed here. Everything else can stays in app/models.

A new function had to be created to perform the task of lazy loading. The lazyLoadModel() function in the basics.php file takes care of the task. It behaves a fashion similar to loadModel() by loading models from the lazy_loaded directory found in the modelPaths.

Show Me The Code

The changeset for this modification can be found [here][cs-1]. This should apply cleanly to CakePHP version 1.1.8.3544. It should also apply cleanly to version 1.1.10.3825. If you are still using 1.1.8.3544, then you should upgrade to 1.1.10.3825 before applying this patch. Otherwise, you will end up having to manually resolve conflicts. Of course, if you apply this modification, you will end up having to re-apply it with each new version of CakePHP.

Does it work?

I have done a bit of profiling on an example app based on the [Blog tutorial][cake-blog-tut] from the CakePHP Manual as well as tests using [Siege][joedog-siege]. For this test, I created 10 dummy model class files and placed them under the app/models directory as usual and then I ran the profiler from my demo version of Zend IDE. As expected, CakePHP loads everything it can find under the app/models directory and chews up processing time, memory and file handles. The Zend IDE profiler reports that it had to open at least 50 files for the blog app home page.

With Siege, with 100 concurrent requests and with 10000 reps per connection (resulting in 1,000,000 hits total), the server began to cave after the first 4,000 hits and continued to slowdown to at most 40 to 70 seconds on a lot of requests. I was not sure if there were any file handle exhaustion errors since Siege is not able to display the actual page that it requested.

For the second test, I moved all the dummy classes from app/models to app/models/lazy_load I also did the same for the classes that are actually used by the app (post.php and tag.php). First the Zend IDE profiler reports only 40 files are being opened for each request. With Siege, under the same settings as before, the server was able to make it through the ordeal slowing down to 10 to 20 seconds on some requests after about 700,000 hits.

For me, it’s a significant improvement. But you don’t have to take my word for it so go do your own tests and let me know about your results.

Caveats

This is a modification on the mainstream CakePHP code. Which means if anything changes on the mainstream, this modification may also be affected. If you apply the patch to future versions of CakePHP and it results in failed hunks, then you should check what went wrong and take the necessary steps to correct the problem.

Theoretically, the lazy loader should work for plugins too. But I have not tried it yet.

Conclusion

If you like this modification and use it in your production site, please leave a comment here and let me know what you think.

This and other modifications I am making are being made independently from the CakePHP project. As such, you should never report problems you encounter with my modifications to either the CakePHP mailing list or IRC channel. Please report them directly to me.

If you want to send bug fixes or suggestions for improvement, please send email to:

nimrod.abing+blog@gmail.com

Please use the subject line:

PATCH: CakePHP Model Lazy Loader

[cs-1]: http://abing.gotdns.com/cake/diffs/000010-lazy-loaded-models.diff “Changeset for lazy loaded models in CakePHP” [cake-blog-tut]: http://manual.cakephp.org/appendix/blog_tutorial “CakePHP Blog Tutorial” [joedog-siege]: http://www.joedog.org/JoeDog/Siege “JoeDog.org: Siege”

a

The ThemeableView class here is part of the CMS that I am currently working on.

Updated to Version 1.0.6

See this usage notes for CakePHP 1.2.x.x users.

Download the package here:

ThemeableView-1.0.6.zip

What's new in 1.0.6?

Yes, I am aware of another themeable view class for CakePHP which can be found here. However there are two problems that I have with that implementation which forced me to write my own class:

1. The class file is licensed under the OPPL. As far as I can tell, the OPPL seems to prohibit commercial use (see OPPL Section 3b and Section 4a).

   It is also unclear whether or not the OPPL is viral when OPPL licensed code is used to create a “Combined Work”. It is also unclear how the OPPL interacts with the GPL, LGPL and other licenses.

   I have written to Larry E. Masters about this but I have not gotten any response from him so far.

2. Theme elements are spread out in separate directories under app/views. This makes it less than ideal for large sites with a lot of controllers and actions.

For instance, if you have a theme named ‘MyTheme’ you will have to create the following directory structure in app/views:

app/views/elements/MyTheme
app/views/errors/MyTheme
app/views/layouts/MyTheme
app/views/controller_name/MyTheme

The first three directories present very little problems. However, with several controllers it will be taxing to have to create a MyTheme folder for each controller. Things get even messier when you use plugins:

app/plugins/MyPlugin/views/elements/MyTheme
app/plugins/MyPlugin/views/errors/MyTheme
app/plugins/MyPlugin/views/layouts/MyTheme
app/plugins/MyPlugin/views/controller_name/MyTheme

This can be a nightmare for theme maintainers since there can be a lot of themeable elements to keep track of and they are all over the place.

My implementation solves problem #1 by licensing ThemeableView under the MIT License. This is the same license used by CakePHP itself. Which means you can do pretty much anything with this code: use it in commercial apps, sublicense it (change the license terms), use it to bring world peace…

The only thing the MIT License disallows you to do is to remove the copyright notice from the code.

If you look at the code for the class itself, you will notice that it sort of resembles phpnut’s code. Before you go off and yell profanities at me, you should know that I contributed to phpnut’s ThemeView as well. Another thing is that my code is based on the View class itself, being that ThemeView and View are written by the same person, then there is bound to be similarities. This is aside from the fact that with the way CakePHP is structured, it is very hard to produce truly unique code.

For problem #2, all themes are placed in a themes directory under the app/ directory. Each theme is in its own directory. So using the MyTheme example above:

app/themes/MyTheme/views/elements
app/themes/MyTheme/views/errors
app/themes/MyTheme/views/layouts
app/themes/MyTheme/views/controller_name

Even with plugins:

app/themes/MyTheme/plugins/MyPlugin/views/elements
app/themes/MyTheme/plugins/MyPlugin/views/errors
app/themes/MyTheme/plugins/MyPlugin/views/layouts
app/themes/MyTheme/plugins/MyPlugin/views/controller_name

Everything that the theme requires to render all the views in your app is placed inside the MyTheme directory. In addition, you can also include other resources with the theme such as images, icons, Javascript, and CSS stylesheets. These need to be placed in a location that is accessible on your webserver. This means you should place theme resources under the themes/MyTheme directory in your webroot directory. For example, if your webroot is under your app (as in the default setup):

app/webroot/themes/MyTheme/css
app/webroot/themes/MyTheme/js
app/webroot/themes/MyTheme/images
app/webroot/themes/MyTheme/icons

Then from your templates, simply do:

<link href="<? $this->getThemeablePath('css', 'mystyle.css') ?>" type="text/css" rel="stylesheet" />
<script language="Javascript" type="text/javascript" src="<? $this->getThemeablePath('js', 'myscripts.js') ?>" />
<img src="<? $this-/>getThemeablePath('images', 'myimage.gif') ?>" />
<img src="<? $this-/>getThemeablePath('icons', 'myicon.gif') ?>" />

New in 1.0.4

As of version 1.0.4, a new ThemeHelper class is available. This class contains theme-aware versions of the css() and image() methods found in the HtmlHelper class. You can use this instead of having to write the tags by hand as above. See the ThemeHelper PHPDocs for details.

To use this class, place the file named themeable.php inside app/views.

Then, from your controller set view to "Themeable". Then set the current theme as a property themeName:

var $view = 'Themeable';
var $themeName = 'MyTheme';

Or you can create your own app_controller class and define the view and themeName properties so that all controllers in your application will be using them.

There are two constants that point to the location of your themes and theme resources.

• THEMES - point to the absolute path on your webserver's filesystem where your theme templates are stored.

  Default: APP . 'themes' . DS

• THEME_RESOURCES - point to the relative path on your website's URL where your theme resources are stored.

  Default: DS . 'themes' . DS

You can define these to point elsewhere depending on your setup.

I hope someone finds this useful. If you have any questions or comments please leave them on this post. My apologies for the slight inconvenience of required registration. There has been a string of spambot activity on my site recently.

If you have patches to this code, they are very much welcome. Send them to:

nimrod.abing+blog@gmail.com

Please use the subject line:

PATCH: ThemeableView class

Notes For CakePHP 1.2.x.x

This one comes from PJ Hile. Some API changes have taken place in CakePHP 1.2.x.x and naturally this equates to some changes in the themable view class as well. However, at the time of this update (13 Jun 2007) CakePHP 1.2.x.x is still in Alpha stage. That pretty much means that the API is still subject to change so this may or may not work for you depending on your current 1.2.x.x snapshot. Here's the full text of the email I got from PJ:

On 6/13/07, PJ Hile wrote:

Just some updates for those using CakePHP 1.2.x.x

1. $this->_viewVars has been changed to $this->viewVars (lines 242 and 260)
2. strip_plugin() has been moved to Router::stripPlugin() (line 183)

Hopefully that will save some people some time.

Regards, PJ

Internal ChangeLog

21 April 2007 - Version 1.0.6

Download: ThemeableView-1.0.6.zip

• Match themeable view locations between website pages and phpdoc. (Peppe Bergqvist)

• Fix filename mangling when falling back to 'system' theme in Themeable::themeElement(). (Peppe Bergqvist)

• Change behavior of Themeable::themeElement() to match new behavior in View::element(). Client code that relied on the old behavior should now use Themeable::_getThemeableElement() instead.

19 April 2007 - Version 1.0.5

Download: ThemeableView-1.0.5.zip

• Fixed recursive method invocation for View::element() whose behavior was changed in revision 4050. Special thanks to Peppe Bergqvist for discovering, reporting and investigating this bug.

07 October 2006 - Version 1.0.4

Download: ThemeableView-1.0.4.zip

• Use / instead of DS in getThemeablePath() and THEME_RESOURCES. (thanks to Ryan Clark)

• Fix viewPath resolution logic in _getViewFileName to include 'system' theme.

• Provide documentation in the PHPDoc comments.

• Added new ThemeHelper class to provide theme-aware analogs to css() and image() methods in HtmlHelper.

06 October 2006 - Version 1.0.3

Download: ThemeableView-1.0.3.zip

• Fix _getLayoutFilename() logic when the view attempts to search for a usable view layout file. (thanks to Ryan Clark)

• Added absoluteURL() method and use it for getThemeablePath() so that it returns the correct path to a themeable resource regardless of where CakePHP is currently installed.

25 September 2006 - Version 1.0.2

Download: ThemeableView-1.0.2.zip

• Move theme resources to webroot to allow for setups where the app dir is in a location that is not accessible through the webserver.

• Conditionally define THEMES constant to allow user to define an alternate location.

• Add a new conditionally defined constant THEME_RESOURCES to point to the relative URL of resources provided by the current theme.

15 September 2006 - Version 1.0.1

Download: ThemeableView-1.0.1.zip

• Fix theme fallback mechanisms. If a theme resource is not found in the current theme, it will try to search in themes/system.

• Fix bugs in plugin and element theme resource searching.

11 September 2006 - Version 1.0.0

• Initial release.

a

Click on the thumbnail above to view the full image.

a

While some may argue that this manner of implementing MVC is overkill in typical applications, in very large applications (like PhilWeavers.net) it leads to very quick turn-around when it comes to adding new actions or modifying existing ones.

The full ChangeLog entry pretty much sums it all up:

This modification allows the client code to implement actions in separate classes. It is comprised of two parts:

1. A custom dispatcher capable of loading an Action class if action is not found to be in the controller’s methods.

2. An Action base class.

Rationale:

Implementing actions as methods of the controller class can become unwieldy especially with very large applications. Most of the time, only one of those action methods is invoked. The PHP engine still has to parse through the whole controller class file.

By moving out the actions into separate class files that are loaded on demand the overhead of parsing through a large file consisting mainly of dead code is avoided.

Because an action class is self-contained, it is now safe to implement a more structured approach in implementing methods through the use of small helper methods in the action class.

Full Description:

First and foremost, the goal of this modification is to be backwards compatible with existing code. This will help in migration towards using action classes.

Secondly, missing action classes must not disrupt the normal dispatching of the request. Missing action classes will not trigger a special error. Instead, the usual “Missing Method in Controller…” errors will be generated.

Finally, plugins should be able to use action classes as well.

How to implement an action class-based CakePHP app:

1. Edit app/config/core.php and set CUSTOM_DISPATCHER to ‘acDispatcher’.

2. For each controller create a folder in app/controllers/ with the same name as the controller following the usual CakePHP naming conventions.

3. Override app_action.php if desired. Place your custom app_action.php in app/app_action.php.

4. Create an action class file inside app/controllers/controller_name. We also follow the CakePHP naming conventions here.

5. Implement the method perform() in your action class. This is the same as creating an action as a method in your controller. If your action accepts parameters, specify them as such in the parameter list for perform().

For example:

http://example.com/ctrl/index/

Create the directory app/controllers/ctrl

Create the file app/controllers/ctrl/index_action.php

Define IndexAction in index_action.php defining the perform() method.

Notes:

• You get a reference to the controller in $this->controller.

• All the properties of the controller can also be referenced in the context of the action itself. For instance, the $uses property is also available as a reference using $this->uses.

For plugins, simply follow the usual conventions as above in addition to the CakePHP plugin conventions.

I wish to clarify to any CakePHP users who might stumble upon this (and my other modifications) that this modification is meant to serve as a transition point for me to allow me to port my apps to CakePHP from my previous framework.

Also note that this is the first commit of this modification and there may be bugs. If you encounter any, please DO NOT report them to the CakePHP developers nor the CakePHP Google Group. Leave a comment here if you wish to file a bug report.

Lastly: Experimental code. Caveat Programmor

a

Updated: 6 Dec 2006

NOTE: Instructions for applying individual diffs found here are incorrect. [Read this][correctinsns] if you want to apply patches individually. This article is kept mostly unedited for archive purposes.

First off, these modifications started out as a set of patches to make porting between my old framework and CakePHP much easier. They may not be useful for you. Another thing to note is that these patches are made against the latest Subversion version of CakePHP. With that in mind, you might be better off using the official releases of CakePHP [found here][cakephp].

Secondly, some of these patches might break compatibility with the official CakePHP. However, I have taken great care to maintain compatibility with the official releases as much as possible. If a patch introduces features or modifications that could break compatibility, it will be indicated in the patch description.

Applying the Patches

You have two options of applying the patches. The recommended (and easiest) way is to download them using [darcs][darcsweb]. The second way is to download CakePHP from the offical Subversion repository and then apply the patches using diff.

Since the second way requires a bit more work, I will describe how to do it first. (EDIT: I highly recommend using the prepatched version found [here][prepatched] instead of applying each patch individually or use the darcs repository.)

Applying Patches with diff

1. Download the patch set [here][diffs]. You can either individually download the patches you need. Or download the tarball all.tar.gz.

2. Download the official CakePHP from the Subversion repository. Instructions can be found [here][cakeman3] (see section 2). Make sure you get the latest revision indicated in the diffs [README.html][diffsreadme]. (EDIT: The README.html now has a table showing which patch should apply cleanly to which SVN revision.)

3. Using the Gnu Patch program, apply the patches.

Assuming you have downloaded the CakePHP and you have it under the directory cake and the patches in the directory immediately above it, here is an example command line session (Unix):

$ cd cake
$ patch -p1 < ../<name of patch>.diff

The patches are numbered sequentially, in the order that they were committed to the darcs repository. So you should apply them in sequence since one patch might depend on another. If one patch does not apply cleanly, you should remove it (EDIT: Or resolve the conflicts manually). Otherwise, you may end up with a broken CakePHP.

Using the darcs Repository

Now for the recommended way of downloading the patches.

1. Get [darcs][darcsweb]. There are binaries for many operating systems, choose one that is appropriate for you.

2. From the command line (Unix), issue the command:

   $ darcs get http://abing.gotdns.com/darcs/repos/cake

   That should pull in all the patches and give you an up-to-date tree. If you only want to pull in a specific patch:

3. From the command line (Unix), issue the command:

   $ darcs get --tag='CakePHP-v-1.1.' http://abing.gotdns.com/darcs/repos/cake

4. Then look at the [ChangeLog][changelog] and search for the patch name that you want to pull.

5. Make sure you are in the local repository directory. From the command line (Unix), issue the command:

   $ darcs pull --patch='PATCH NAME'

Darcs will pull in the patch that matches the PATCH NAME you specified along with any other patches that it depends upon.

A Few Thoughts About Darcs

You may be wondering, CakePHP already uses version control software (Subversion), why use darcs?

I have been using [David's Advanced Version Control System][darcsweb] (darcs) for all of my projects for over two years now. CakePHP uses Subversion, I think only because it works well with Trac. Using darcs instead of subversion is entirely my own choice.

Darcs is what is known as a “Distributed SCM” which is vastly different from the way CVS (and Subversion) does things. There are a few things to note, especially for long-time CVS or Subversion users.

First off, you will notice that there are no revision or version numbers in darcs. It may come as a surprise to you, especially is you have been using CVS or Subversion for a long time. Version numbers are useless under darcs because of its “distributed” nature. Instead we use “Patch Names”. A patch name is just a short string used to identify a specific commit.

Secondly, your copy of the remote repository is a complete repository. Which means you can record or commit your own changes without having to connect to the remote repository. Your recorded patches remain in your repository, unless you send them to me so that I can apply them. This is where the “distributed” nature of darcs comes into play. It allows you to make changes in your local repository and commit them locally, thereby providing you with a complete record of the changes you made.

Lastly, darcs has a feature that reduces the burden of tracking down who made which changes. By setting your name and email address in the _darcs/prefs/author configuration file in your local copy, all commits made in your repository will be tagged with your name and email address. When the ChangeLog is generated, all patches that you send to me that I applied to my repository will automatically contain your name and email address.

Those who are familiar with darcs will probably wonder why I did not use tailor.py to migrate patches back and forth between the Subversion repository and my darcs repository. This is because I do not expect these patches to make it into the mainstream CakePHP code, so why bother? Most of the patches I made are necessary for my purposes, but may not be useful in the general use-cases for CakePHP.

I also wanted to be able to start from a single recent SVN snapshot (I don’t need the pre-1.0 stuff). This reduces the amount of space I need for the repository. I have a 300MB disk quota on the server hosting the remote repository, so every bit of space savings counts. This is also why you will only see the _darcs directory (without the pristine directory) on the server.

Patch Descriptions

Aside from maintaining compatibility with the mainstream CakePHP, I have made it easier to determine what a patch does based on its name. However, one can only say so much in a patch name so a longer description of the patch is necessary. I have made use of the following convention when entering patch descriptions:

[optional introductory text]

Rationale:

[explanation of why this patch is necessary]

Full Description:

[full documentation about what this patch does and what it affects as well API changes that it introduces]

[optional notes on compatibility]

The Future

This is just the beginning of a series of articles and patches for CakePHP as I continue to port my old projects to this new framework. Though I do not really expect these patches to make it into the mainstream CakePHP tree, it would be great if some of the patches make it.

You may also find that some of these patches won’t do anything useful for you. As one saying goes, “If you don’t know what it does, then you probably don’t need it.” This is most certainly true for many of the patches that you will find here. Read the description first if the patch name does not give you enough of an overview as to what a patch does.

[cakephp]: http://cakephp.org/ “CakePHP Official Website” [darcsweb]: http://darcs.net/ “Darcs Website” [cakeman3]: http://manual.cakephp.org/chapter/3 “CakePHP Manual Chapter 3″ [diffs]: http://abing.gotdns.com/cake/diffs/ “CakePHP diffs” [diffsreadme]: http://abing.gotdns.com/cake/diffs/README.html “diffs README.html” [changelog]: http://abing.gotdns.com/cake/diffs/changes.xml “ChangeLog for CakePHP modifications” [correctinsns]: http://abing.gotdns.com/cake/diffs/README.html “Correct way to apply individual patches” [prepatched]: http://abing.gotdns.com/cake/diffs/cake-diffs-latest.tar.gz “Pre-patched CakePHP”

a

I have been keeping close watch on the [CakePHP][cakehome] project for quite some time now. Ever since all the hype and hoopla for [Ruby on Rails][rorhome] exploded on the Internet, I wanted to see a similar framework for PHP and that’s when I discovered CakePHP (which was still in version 0.10.x). RoR is good but there are a few barriers to entry for me with this framework:

1. Not a lot of hosting providers that support RoR out of the box, most of them offer RoR as an installable option or “uppgrade” for extra $$$.
2. Documentation for the framework is a bit dodgy in some areas, though it’s improving constantly.
3. The tutorials seem to speak of older RoR versions and focus primarily on the “scaffolding” feature of the framework. Though I think this has been revised already.
4. I have to force myself to learn Ruby, not necessarily a bad thing but I prefer to stick with what I already know for production projects.
5. I have tried installing and configuring a running server (not using webrick) and even with FastCGI, it’s still not as fast as PHP. Performance is really important to me and it seems it requires way too much work to get RoR running as fast as my current PHP-based framework (also using the MVC-pattern).

With CakePHP, I get most of what RoR currently offers without having to go through extra lengths that I had to go through with RoR to “just get things working”.

I like the fact that the CakePHP docs are honest in admitting that the scaffolding feature, while impressive during demos, are not really meant to be used in production work. RoR seems to push the scaffolding feature as one of their main selling points, which has led some newbie users into thinking that it was suited for production apps. From the CakePHP manual:

Cake’s scaffolding is pretty cool

So cool that you’ll want to use it in production apps. Now, we think its cool, too, but please realize that scaffolding is… well… just scaffolding. Its a bunch of stuff you throw up real quick during the beginning of a project in order to get started. It isn’t meant to be completely flexible. So, if you find yourself really wanting to customize your logic and your views, its time to pull your scaffolding down in order to write some code.

I tried out the [Blog Tutorial][cakeblog] and in less than 15 minutes I was able to finish it with everything working exactly as advertised.

It’s interesting to see what CakePHP-based applications others will come up with in the next few months. Personally, I am planning to rework my existing CMS framework to use CakePHP. I think it will be worth the effort, as it was certainly worth the wait for the 1.0 release.

[cakehome]: http://www.cakephp.org/ “CakePHP Home” [rorhome]: http://www.rubyonrails.org/ “Ruby on Rails Home” [cakeblog]: http://manual.cakephp.org/chapter/17 “CakePHP Blog Tutorial”

a