Customer Portal 3 – Brave New World

Dystopian connotations aside, the new framework is fully upon us a year in and it’s time for many to begin looking at the road forward. Those just starting on RNT will already be on CP3 and learning things right from the ground up (in theory). Those of us working on older sites have a bit of work ahead of us. Fortunately this work, when done right, can be a great way to learn how things are constructed now. If you’re like me, this will be hard at first (VERY hard in my case), but the work of upgrading a customized site from CP2 to CP3 will give you the chance to experience the changes and get a firm grip on them. If your site is highly customized you’ll be getting that grip for weeks to come. In order to document the various things to understand and pitfalls as well as best (or, lacking true expert opinion, at least decent) practices, I felt this would be a good time to begin blogging on the way things are done in CP3, using real world examples to document how things were, and how things are. We will start with the most basic of functions and then branch out to ever deeper customizations. To start, however, understand that it is not my intention at this time to go over basic MVC and how CodeIgniter itself works. While that may be post-fodder for a later date, these first handful of posts will handle CP3 itself, beginning with this first post, a broad overview of CP3 and how it works differently from CP2.

Back in the old days </grandpa voice> when we wanted to change a widget in any way other than by CSS, we had to copy that widget and make our changes to the view, controller or logic files as the case required. This came with a lot of flexibility, but also had the downside of divorcing that widget from the parent from that point forward. Your Multiline widget gets some neat new highlighting feature? Your CustomMultiline copy will never know about it. You’re going to have to go in and update your code…and who among us has that kind of time? With CP3, some real inheritance/extension has been introduced into widgets. When we create a widget we can choose to extend it from a base widget, and then determine what part of that widget we are impacting. Want to rearrange the display of the answers that the Multiline widget exposes? Then you’re going to modify just the view and ideally extend it. Need some neat new YUI features attached to your input box? Simply extend the logic file. Want to cause your input boxes to do a database write before form submission? Extend the controller with its own built in AJAX endpoint (more on that in a later post) and add a listener to the extended logic file for onBlur.

What all of this means is, we now have the potential to layer code on top of existing code in a way that preserves the baseline. If that baseline updates, our new widget gets the update as well. If we need to go one step further and override a method, either in the controller or logic, and we can’t simply include the parent (in the vast majority of cases we can) then only that small part of the whole codebase gets divorced, the rest of the code inherits just fine. There are exceptions to all of this, which we will go into in later posts, but by and large, inheritance is the watchword of the new framework. How things are done is going to feel very different, but hopefully through the following weeks, with plenty of examples, that learning curve can be simplified. Real world examples are critical for something like this, so the next post will be for performing what is likely the most basic extension for a widget, modifying the view. We will walk through, step by step, how to take the multiline widget and both add to as well as modify how it functions. There are a few gotchas in there, and I’ll go over those as they become relevant.

Stay tuned.