You know that something in your form is blackholing, but don’t know what caused it – right? so let’s start from the beginning. How does the FormHelper and SecurityComponent work? how does it do it’s magic?

Well, you use the FormHelper to make your forms, and each time you insert a field, the FormHelper records it, and adds it to a ‘master list’, a $fields array in the form helper. Each type of field does something a little different, but basically, as long as the security component is included (in your app_controller or your controller), then by default, all fields that the FormHelper adds are “secured”.

Now, there are 2 different ways that the FormHelper secures form fields. On most fields, it secures just the fieldname, but on hidden form fields, it secures the fieldname and it’s value – this is called “locking” the field. This is important, as you will see in the example later. Securing just the fieldname means that all the form fieldnames must remain the same. None can be added, or removed, or renamed. All fieldnames must remain the same and can’t be changed. When you “lock” a form field. It’s name and value must remain the same.

Understanding that, let’s talk about how it secures things? how does it work? OK, we know that all form fields to be secured (either by locking it, or just securing the fieldname) are part of a master list in the FormHelper’s $fields property. When you call $form->end() in your view, it iterates through this array, and all form fields that should be secured – including the ones that should be “locked” are added to an array, and then a hash is generated from that array. That hash is stored in a hidden form element in that form (as [_Token][fields]). Now the [_Token][fields] contains the hash, and all the fields that were “locked” in an encoded format (rot13), which is serialized. The form also gets a [_Token][key] generated which is stored in the users session.

Now that the form is “tattooed” with the secure hash, it’s pretty easy for the SecurityComponent to verify things. When a form gets posted, the security component basically compares the key stored in the users [_Token][key] session variable with the form’s [_Token][key] to make sure it’s the same. If it is, then it simply takes all the forms current fieldnames, un-serialzes/un-encodes the rot13 “locked” fieldnames which indicate which fields were locked (which fieldnames had which values), puts it all in a new array, and takes a new hash of the entire thing. If the hash is stored in the original forms [_Token][fields]match, and the newly created hash match, then it id assumed that the form hasn’t been tampered with and things are good. If it doesn’t match – then the form has been tampered with, and the request is blackholed.

OK – so far it’s pretty straight forward – but the big thing for me is that, by default, all hidden form fields are locked.

Now, imagine in your form, you have a typical “edit” form, which you are loading data dynamically into with your javascript framework of choice. Now, you update the hidden “id” field because it needs to be updated to reflect the new dataset that is loaded into the form – so that if it’s posted it updates the correct row.

Well, in this case, with the above understanding we know that the form will be blackholed because a hidden form field (which is locked by default) has been changed. when the form gets posted, the security component will generate a new hash with the form data that it received from the post, and the new hash will not be the same as the old hash. crap, what do we do?

Well it turns out that you can disable security for hidden fields. Now before I tell you how, I must tell you that this isn’t really a good idea, and I have proposed a better way which I will get too below. How do you disable a hidden field from being secured? Easy:

Now, this still won’t work in our example? Why? Well, this disables that field entirely from the secure “hash”. It isn’t locked anymore, and it’s not secured/present in the FormHelpers $fields array that gets hashed. Maybe some of you are saying “AHA!”, and maybe still some of you don’t see it yet…well, what happens when the form is posted? What does the SecurityComponent see? it sees all posted fields and values, all of a sudden there is an extra field in there (the hidden field), and a different hash will be generated. Since there is now a hash mismatch, the request is blackholed. “AHHHHHHH” how do we get around that?

This is where the SecurityComponent’s disableFields property comes in. If you disable the security in hidden fields using the above method, you must also disable them in the SecurityComponent using the disabledFields property in your beforeFilter(). That way, when the form gets posted, the security component knows which fields to ignore when generating and comparing the hashes, and they will match…but is this good?

I have been reading around, and it seems that most people just disable the SecurityComponent when ajax comes into the picture. Now, I consider using the SecurityComponent’s disableFields property pretty much the same as effectively disabling the SecurityComponent – especailly in the above case.

Why? well, what happens in the beforeFilter? well, it is executed before each and every action for that controller. That means if we tell the Security component to disable the “id” field, all forms for that controller will have all their ID fields vulnerable for tampering. Is that a good thing? I would say the answer to that is a big no.

What really is needed is a way to control the hidden fields. a way to say “secure the hidden field, but don’t lock it”. This way the value of that field can be changed, but the fieldname itself cant be. So that fieldname must be present and accounted for in the post. Also, if we had some of this control, we wouldn’t need to mess with the SecurityComponent’s disableFields property (or at least not as much) in these specific circumstances. This means that for specific instances, we could allow the hidden fields to have their values changed and still keep full security for all other forms for that controller. I would say that this is a much more secure method of dealing with things.

Now, this still isn’t the best, as this indeed doesn’t protect someone from changing the value of the hidden property – but you should also have other checks in place to safeguard against this (does the current user have the proper permissions to make this change?). But at least if we had this option in the FormHelper, then at least we could make that choice.

It turns out that to add this type of choice isn’t too hard, but, for now, it does require you to override the default FormHelper.

If you copy cake’s FormHelper into your view->helpers in your app directory, then all that is needed is to make the hidden method look like this:

if you do this, then on hidden form elements, you can pass an options array that has the following possibilities:

secure, and secureValue defaults to true, meaning that by default, hidden fields are locked. but if you change the secureValue to false, the hidden field will just be secured (meaning that the value is allowed to change, but the fieldname itself must be present and accounted for, but you should know that by now..right ).

I did open a ticket at the lighthouse, so maybe one day that change will be included in the FormHelper…but until then, this work around is needed (or you have to still mess with the SecurityComponent’s disableFields property – and remember to pass the ’secure’=>false option on hidden fields also, and “unlock” it for that entire controller).

Another option is to not use the form helpers hidden fields, and use the regular text input fields, then disable them/hide them with css/javascript. If you do it this way, then you do not need the FormHelper modification above, and as long as you don’t add/remove fields, your form will not get blackholed.

Hopefully now you have a better understanding of what types of changes will cause blackholes, and what options you have in dealing with them. If you rather have a patch for the above workaround, you can grab it from here

At first I didn’t know where to start, the Security component just was rejecting the post. so I started experimenting, and found that it only happened on select boxes. Clearing text or textarea fields were not an issue. After looking around a bit more, I found that version 2.21 of the jquery form plugin (and probably all other version) at around line 578 was changing the selected index of all select boxes to -1. Since -1 is not a valid option (option’s start at 0), the Security component was thinking that the form had been tampered with, and rejected the post.

A simple change in the clearFields() function (the clearForm() function calls the clearFields function for all form elements of type text, select and textarea) fixed this all up:

I guess the important part here may not be about fixing the jquery form plugin, but more this: however you are clearing your form, if you run into issues with the Security component, make sure that on select boxes you are not assigning them invalid option indexes (-1 in the above case).

That’s it. Now the select box entries go back to the first option (option 0 – which is often blank anyways) when a “clear form” button is pressed, the Security component will accept the post – and everyone is happy

While this does work, it is not a pretty solution, is not easily manageable, and leaves a bad taste in my mouth, so I figured that there must be a better way…and there is with Netbeans !

So, off I go again seeing if there are any new developments in the PHP IDE arena these last 6 months or so, and what do I find…Netbeans for PHP. Because I have tried almost every other PHP IDE on the planet, but have never tried Netbeans (since it never really had good PHP support until recently)…I decide that this will be the week.

As I am downloading and installing the thing, I start browsing around to see if there are any tips for CakePHP integration. About 30 seconds later,  I find something – and it looks promising.

So, I load up my usual test project, make some modifications to the source’s comments so that Netbeans understands the Cake world, and what can I say – I was really, really, really floored. This worked MUCH better then anything I had ever used before – much, much better then I ever had with Eclipse, in a much cleaner, and more manageable way.

Before I start talking too much about Netbeans, let me just cover the issues that I had with Eclipse’s code completion with CakePHP. To get Eclipse to understand that $this->Model in your controller was a model, you had to add something like the following to your controller:

Now, this doesn’t seem like a big deal at first, but once you realize that you have to do this for every component, helper, model that your controller uses, it gets a little nasty. Now, let’s just say that our $ModelName model has multiple relationships with other models. The CakePHP way is to access them as such:

So, Eclipse knows about ModelName, and we have code completion for that. But it knows nothing about ModelName->OtherModel…no code completion, we are stuck. So off we go again adding more comment blocks to try and manage Eclipse.

Now, again, you multiply this by all of your application models, and you end up with a mess pretty quickly. This even gets worse.

For components, cakePHP uses a component array to define which components your controller will use. Let’s say that I have some core components that I will use in every controller. Instead of loading them up manually in each and every controller, it makes more sense to load them up in my AppController, where all the other controllers are derived from.

So, in your AppController you start adding the Eclipse @var code blocks for all the components so that Eclipse can figure out the code completion, and it works great… in your AppController at least. Next you open one of your other controllers and start typing $this->ComponentName->….and nothing. No code completion again!! Eclipse, for whatever reason, can’t code complete an inherited @var comment block. Maybe I just did something wrong, but this never really worked well at all for me, at least not consistently.

Ok, so how do you get it working…well, you have to include the stupid @var comment blocks in each and every controller that you want code completion for…this is insane and is a complete mess.

You do this for all your Model’s, all the Model relationships, all the components, and then count how many lines of code in your entire project that was added just to make eclipse’s code completion work…it’s a lot. A lot of code, a lot of redundancy, and when you have to change things, it’s a lot of new code to add – simply stated, it’s a lot. Too much if you ask me.

Ok, so now I have talked about how all the Eclipse hacks are messy, how does Netbeans compare?

At first Netbeans seems to use a very similar method for helping it understand CakePHP’s world. You use @property javadoc comments in the codeblocks just before the class’s declaration, like so:

So, now you have a single @property javadoc comment to tell Netbeans that $this->ModelName refers to the ModelName model for that controller, and code completion works great. So far so good.

At least this is just a single comment line, and I don’t need to declare a useless variable like I have to do with Eclipse. With Eclipse, I would have a comment block consisting of at least 1 line, but possibly 3 lines (/**, * @var, */) depending on the project’s source code formating policy, and then the actual useless var $name line. That’s either 2 or 4 lines of code to do Netbeans’ 1 line of code. That’s at least a 50% improvement, not bad at all.

What about $this->ModelName->OtherModel-> code completion support? How do I get that to work?

Well, this is where Netbeans really starts to show it’s power. In the comment block that is just before your Model declaration, just add the same @property for each model that it has a relationship with. Example:

That’s it. Again, a single line of code for each relationship that this model has. The best thing about this is that Netbeans, unlike Eclipse, properly understands inheritance when it comes to the @property javadoc comments. As soon as you do this in your Models, all of a sudden, in your controller, $this->MyModel->OtherModel-> has code completion…awesome. This never worked well with Eclipse, and I just got rid of a TON of code duplication all over the place with @var comment blocks to try and get Eclipse to work. Now I am really happy, as this is much more then a 50% improvement…

Now, what about components? Well, components are exactly the same thing. In my AppController’s comment block that is right above it’s class declaration (for all the common components that every controller uses), you just add an ‘@property ComponentNameComponent $ComponentName’ line for every component that you want to use. Again, because Netbeans understands inheritance with these @property comments, they work in every controller – immediately. Wow.

Ok – now I am in heaven. I can get rid of all of these silly @var’s all over the place, which already cleans up the code a lot, and have a much cleaner, and controllable method of telling Netbeans about the CakePHP world.

At this point, I wanted to see how helpers in the views could get code completion, and this works pretty much exactly like Eclipse, so they are the same when it comes to helper code completion support. All you need is a file in a include directory, or somewhere in the “project” that has something like:

As long as Netbeans (or eclipse for that matter), can see this file, you get code completion for helpers in all your views. This is an OK work around, and I have no issues with this method.

Netbeans also has some really nice features out of the box:

• awesome refactoring support – very cool stuff (look into Ctrl-R)
• searching with very cool “diff” like displays for all matches in the scrollbar area
• great CSS code completion
• awesome javascript support
• support for multiple language code completion in a single file (ex: css -> javascript -> php)

You add all this up, and I think that it will take a major problem Netbeans to get me back over to the Eclipse camp.

It is at least as good as Eclipse in most areas, and has a much cleaner and easier way of setting up code completion for PHP frameworks. It is also a no hastle-everything just works- installation, unlike Eclipse where you have to download a bunch of add-ons after you get it so that it can do the things you want…that’s if you remember which update site was needed to install the add-on…..that’s also a mess – but let’s not go there right now

The Netbeans add-on’s are more along the lines of Jedit, where you have a single section in Netbeans to view all “stable” add-ons, and you can install them within Netbeans. No browsing around for a while trying to find something and figuring out how to install it like you have to with Eclipse. You can also download alpha/beta add-ons from the netbeans.org site easily, which then you can install them in netbeans with a couple of clicks. I think this is a much better way of handling add-ons.

So – I think I am a Netbeans convert…if you haven’t used it before, I think it deserves a shot.

If you have had similar (or dissimilar) experiences with Netbeans, I would love to hear your comments

I had to do just this in one of my current projects. I used the kfm file manager, and wanted to integrate it into a CakePHP web site as seemlessly as possible. I was mainly concerned with access and authorization as I wanted to use the same components/controllers that my CakePHP based site used to control access. This way, all security management is done from a single place, and everything is nicely integrated.

I had already decided to use the KFM ajax file manager, as you can use it stand alone, or have it integrated with TinyMCE or FCKeditor. It has themes, and it has a great ability to add custom calls when starting it up to integrate it into other CMS’s. Because KFM was all setup to be nicely integrated, I just had to figure out how. While the rest of this post will be KFM specific, the CakePHP integration code should work on any application that has similar integration capabilities as KFM.

At first, I just wanted access to CakePHP’s sessions, so that I could query the current users session, and then decide if the current user had enough permissions to access KFM or not. While this was the road that I initially wanted to go down, I quickly realized that I would be duplicating much of the code that was already written in my CakePHP site – mainly all the security calls.

I would have to query for the current users permissions, and then map them out to make sure that the current user had the required permissions to access the KFM application. I already had a component that does this in my CakePHP site. All the controllers and views in the cake application just need to query a single method in this component to check if the current user has the required permissions or not. Wouldn’t it be great to just re-use this same component – to just be able to call it from KFM?

Well, it turns out, that with a little bit of work (not too much work – so don’t be scared), you can do this!

Let’s dive in.

KFM has a config.php in it’s api directory, where you can write custom code which will be executed when KFM starts. Basically, if this script returns true, then KFM launches. So all that is needed is to load CakePHP up in a way that doesn’t “take over” KFM, query the needed CakePHP components/controllers that control authorization in your CakePHP application, and return true if the user has access, or exit and redirect with an error message if the user doesn’t. So it makes sense that this is where our CakePHP integration will take place.

My KFM\api\config.php file looks like this:

Ok, there it is, let’s step through it so that we all understand everything.

This first line is the trickiest:

Where is this cakephp.php file, and what’s in it?

Well, this is a copy of CakePHP’s index.php that is in the webroot folder. By default this is in the app\webroot folder in the CakePHP distribution, but use the one that is in your webroot folder – the one that is configured to work for your site. Make a copy of it, and rename it something else. I chose cakephp.php, you can call it anything you like.

At the end of the file, you will see a section that has the following code in it:

you will want to change it to this:

I left the lines commented so you could easily see the changes that we made, but you could just delete everything from “else” onwards – just make sure that you leave the last ‘?>’ ending PHP line at the end of the file.

The first commented section (in the else{} block), is because we don’t want CakePHP’s dispatcher, we just want enough of CakePHP to load so that we can use most if it’s features without cake ‘taking over’ and trying to match the URL’s to controllers and actions.

The second commented section is the ‘if’ block. This is the block of code that prints out the page generation time – and we don’t want that present in KFM in any way. We don’t want CakePHP to echo anything out that will interfere with the HTML that is generated by KFM.

Once these changes are done, simply including this file in KFM’s config.php will load enough of Cake so that we can “tap” into it and use it’s features.

The next line is:

This is Cake’s configure array, and we are making sure that there is no Cake debugging on, so that Cake will not “echo” anything out to the browser – we just want KFM to output HTML, not Cake in this case.

The next three lines is where the magic starts happening:

These are straight-up CakePHP import calls. The first App::import (the SiteAuth Component), is the custom component that I was talking about. This is not a CakePHP bundled component, but you may have one that is similar in your CakePHP application.

This component handles all my authorization checks for the entire Cake app, and this is the component that I want to use.

I then load up the AppController, and Session Helper that come with CakePHP.

The next lines simply instatiate instances of the objects that we imported above:

At this point, I have access to CakePHP’s sessions, and all the methods/properties that come with the SessionHelper(), along with all of the methods/properties that are available in my AppController(). In addition, I have access to my custom component (SiteAuth). Basically, I have enough of cake loaded to do almost anything I want.

Notice here that I instantiate the SessionHelper() in my siteAuth component’s Session property. For other people, you can simply instantiate it to something like $session.

You may need to import other objects and instantiate them, the import thing here is that we have access to all of CakePHP. We can load up models, components, controllers, Helpers…pretty much anything, and start writing PHP in the normal CakePHP way.

Once I have all of the needed CakePHP ‘parts’ loaded, I make the calls I need:

This again is custom to my application, but basically, you will want to verify that the session is valid, and make authorization calls to whichever component/controller you use to authorize your users. if the test passes, return true, otherwise exit and redirect the user somewhere else (access denied).

I have a simple “bounce” controller that basically centralizes all my Flash messages in my CakePHP application. My controller->redirect call in the end redirects the user to this bounce controller that simply set’s the appropriate flash message for an “Access Denied” error, and uses the argument “FileManager” to tell the user that he/she was Denied Access to the File Manager section of the application.

My ‘bounce’ controller also takes care of all the needed logic to redirect the user to the last page he/she had access to, or the site’s root, so if you don’t already have anything like this setup, you may just want to set a Flash ( $session->setFlash(); ) message up in here manually and redirect the user ($controller->redirect(); ) to the site root (or whatever makes sense to you).

Anyways, I hope that this made some sense, and showed you how to load up Cake in a third party app that allows integration, and how to import the needed classes/objects to tap into CakePHP’s power and features, and re-use your CakePHP controllers and components in an interesting way so that you are not rewriting things from scratch.

Let me know if this helped any of you…

The only thing else that you may want is to setup some user feedback through some sort of animated GIF (a spinner), or some text telling the user that this section is reloading data from the database, and to be patient.

To do this, all you need is JQuery’s .ajaxStart and .ajaxStop methods:

just create a div with the image/text that you want to show while the user “waits”, something like:

And then in JQuery’s $(document).ready() function, add:

And that is pretty much it. The only thing else that I found today was a nifty little site to generate those animated gifs (spinning/twisting/progress bars) that we all search for. You can choose the colors you want, and can easily sample and download the animated gif that is created for you:

http://www.ajaxload.info/

• rounding different types of elements – not just div’s, but p’s, h#’s, and lists (ordered and unordered) can be specified and rounded.
• transparency support
• fixed-height option (if you need a fixed height defined in css)
• same-height option. this is by far my favorite. you can use this for layouts, or many other things. I once had to make 12 divs the same size – no matter what data was in them. The layout was a 2 column layout, and so the 12 divs were in two columns of 6 each. If one div needed enough room for 15 lines, all the rest of the divs needed to grow to match the size – so everything would still look even  – that is one div should never be smaller or bigger then the rest of them – all had to be the same size – no matter what. This can be a litle tricky, but a no-brainer with the same-height option, and you get rounded corners for free too – bonus!

For these reasons, and another being that it’s soo easy to use, I am a fan of Nifty. Although I knew that I could use it, and that it plays fairly nice with jquery on it’s own, I wanted to see if I could stay within jquery realm…

I quickly found some basic corner plugins for jquery to round my corners, but most of them were not pretty at all, no anti-aliasing, and so the corners looked pretty jagged. Not very attractive at all. I know that Nifty Corners isn’t the best as far as anti-aliasing goes, but these were much worse then the results that one can get with Nifty.

I searched around some more, and pretty much found what I was looking for with the “JQuery Corner” plugin. The JQuery Corner plugin is more or less a port of the curvy corners script to jquery, so you can use the jquery syntax to locate sections on the page and round them easily. It’s a simpe as:

I mean, it can’t get much easier then this can it! Just use jquery to select the elements you want, and round them. You can also pass the normal curvey corners parameters to control how large the corners should be, which corners should be rounded, etc..

This was fine and all, but I continued my quest to see what other options there were. There was the interesting Nifty Corners port to jquery which also caught my attention.

At first I thought that this was it…all the benefits of Nifty right in jquery – could it be true? Although on it’s own it did work, I just wasn’t able to get it working on IE through cakephp for some reason. Other browsers worked fine, but on IE7 – nothing. No errors, and worst of all, no round corners. I tried different things, but in the end simply gave up. It’s too bad also, as I really liked this idea.

Well – all was not lost, as I knew that I could just use Nifty as is, inside jquery’s $(document).ready() statement. just load up your jquery javascript file, and load Nifty’s javascript right after. After that, all that is needed is:

Basically, just use Nifty as described in it’s home page. We are just using jquery’s document.ready statement to control when Nifty does it’s job.

Since I now had two options that were interesting, and one was outside of the jquery world – I thought to myself “hey, since I am already outside the jquery world – I might as well try the Cadillac of rounded corners..”. I have known about, and used Ruzee’s corners, but didn’t like the fact that it’s heavy. The new one seems a little faster, and although it produces absolutely beautiful corners, it still is heavy and a little slow when trying to round lots of corners on a page. As a simple test, just load up the demo page, and try to scroll around and watch your CPU. Just resize the window, and scroll around and listen to your CPU fan start to kick in.

It also plays nice with jquery – all that is needed it to simply load up the shadedborder.js file after you load up jquery, and then do something like:

Again, we are using jquery’s document.ready statement to control when shadedborder will start doing it’s magic.

All 3 options are viable in my opinion. Ruzee border is by far the prettiest – with it’s drop shadow ability and all, but it’s also the heaviest by far. If you do use it, use it sparingly. The JQuery Corner plugin is pretty good also, and lighter then Ruzee’s corners. It also produces nice anti-aliased clean corners, and works in all browsers that I threw at it. And good ol’ Nifty corners with it’s ‘passable’ corners but very usefull features is the lightest and fastest of the bunch. If you have many corners to round in a single page, Nifty is the way to go. You will sacrifice a bit of the look for speed and usability.

As far as script sizes go, it is very surprising that Ruzee and Nifty are tied for 1st place – with each weighing in at 9KB. Pretty impressive. JQuery Corner is double in size (the minified version) weighing in at 19KB. Although you can use the packed version if you want at 13KB. Still larger then Ruzee or Nifty though.

The one thing that I have left to test is seeing how heavy/fast Ruzee’s corners are if I get rid of drop shadow (.., shadow:0, …). At 9KB, it’s a very impressive library, and produces beautiful results….but maybe that will be a discussion for another day.

What is perhaps the most interesting, is that you can use all 3 of them together with ease. So you can use Nifty for the “I need lots of corners all over the place and so need speed” things, and then use Ruzee or JQuery Corner when you need larger, prettier corners, but only on an single (or a few) element(s).

For my uses, I think it will be a combination of Nifty and Ruzee, as both are smaller then JQuery Corner’s, and Ruzee produces “photoshop quality” corner effects that are really great.

First off, all of these frameworks are really great, this is not meant as a “this framework is better then that framework” thing. Just my thoughts and finally the decision that was made as to which technology/framework I will use for current and future projects.

First off – the frameworks I have bounced around and used over the last little bit:

• CakePHP
  • PHP web development framework
• Django
  • Python web development framework

There have been others, but these two are the two that I have used the most. My idea to go to Python was initially because of language features and performance. Python is a really great language that I enjoy developing in. The use of mod_python and apache with a great framework like Django is very appealing. Django is one of the hottest things right now in the python world, and so I jumped on that train with both of my feet.

After tweaking Apache and mod_python, I had an example app serving a consistent 500 requests per second – not too bad at all. I was pretty impressed, and I knew that that was just the start. I still hadn’t started messing with memcache configurations and load balancing architectures, which I knew that a couple of these projects would need, so a base of 500 rps was very satisfying.

The only issue I had on the performance side was the CPU. mod_python did use more CPU on average to serve the same example app written in CakePHP. That being said, mod_python and Django did serve the app faster then CakePHP, at least twice as fast. So using more CPU could be a satisfactory trade-off on that end.

So I left the PHP/CakePHP camp for a bit, and fooled around in the Django camp. Built a couple of sites, and everything seemed like it was going really well. So well infact, that I wondered why I didn’t do this sooner. Time went on, and the site started getting more and more complex, and soon I was starting to do a lot of “grunt work” so to speak. 

More time went on, and I was finding issue after issue that I was having to write from scratch. More and more time was spent searching around to see if anyone else had done this or that, and try to “snap-in” code from all over the place. The end result was that I was spending more time searching, and trying, and searching again, and trying again for things online to make sure that I wasn’t recreating the wheel, then actual coding of business/application logic.

One such example was data-sets/data-grids. It is a basic, common feature to display a table that is filled with data retrieved from a database. It is also very basic these days to have it sortable, and paginated. Datasets/grids make this job very easy on the developer. I fell in love with the way dotNet 2.0 does this – it’s approach is wonderful. CakePHP also has very nice ways to deal with this, and is extremely easy to use. After searching online 15 or so minutes, I found that there were a couple of “Django” approaches from the community, and an hour+ later, did have some working datasets, but again, I felt like I was simply doing too much leg work. 

That is an hour lost. Never again will I be able to get that hour back. You pile on that hour, with the previous hours of doing similar things, and  you end up being a little frustrated and wondering as to why you are behind. At first it’s a learning curve, and you are expected to be slower. But after a while, the expectation is that at least  you should be as fast as before. Hopefully faster.

PHP can be a very sloppy language. There is less consistency in the language, and there is a fairly large legacy of “the old ways” that PHP is still dealing with. PHP 5 was a good step in the right direction, and added some very much needed things to the language, but it has been slow to adopt for some reason.

But. But. But…..there is always a “but”.

PHP can be very nice to program in also. It is supported all over the place, has a huge community, and runs almost anywhere. Before jumping on the Django/Python train, all my web development was done in PHP for years and years. It is one of the web platforms that I now best, and am comfortable in. For me, the decision to go back to PHP, and CakePHP in specific, was a choice that I thought about, and weighed. CakePHP has really great features, is documented fairly well, and wastes less of my time.

I will say that again: CakePHP wastes less of my time.

It really was a no-brainer to go back…

So – I say hello again to cakePHP, and bye-bye for now to python…maybe one day I will go back, as I do really like the language and it’s offerings, who knows. But for now, I am back to making cake’s with PHP.