http://www.mtheoryx.com/ Tutorials by Geeks, for Geeks en drpoindexter@gmail.com Copyright 2007 2007-11-25T03:41:00-05:00 http://www.mtheoryx.com/index.php/site/multiple_views_and_templating_with_codeigniter_method_2/ http://www.mtheoryx.com/index.php/site/multiple_views_and_templating_with_codeigniter_method_2/#When:03:41:00Z When we last left off... In the previous episode, we left off with the basic instructions for setting up a templating system in your CodeIgniter application. The benefits are two-fold: It saves you lines of code when using many views It helps with future maintenance by abstracting away a great deal of your code So, onto the new stuff...With that said, lets move onto an interesting situation. Let's suppose you've set up a view which has a header, navigation, content, sidebar, ad unit, and a footer. So, your view, with all the includes, would look something like this: <$this->load->view('partials/header');> <$this->load->view('partials/nav');> <div id="content"> <h2>Some content here.</h2> <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Etiam hendrerit orci commodo tortor. Nam eu lacus in turpis placerat pulvinar. Mauris vehicula nisi posuere magna. Aliquam a purus quis pede volutpat commodo. Fusce rutrum tortor non massa. Quisque non tortor. Duis adipiscing pretium velit. Maecenas a ante. Vivamus id urna. Nulla facilisi.</p> </div> <$this->load->view('partials/sidebar');> <$this->load->view('partials/ad');> <$this->load->view('partials/footer');> And the controller index function would simply be this: function index () { <$this->load->view('home');> } Notice that I obviously am keeping all the sub-views, or partials, in a folder together. This is just for organizational purposes, and you don't really have to do it...but you should Disclaimer!! Important!! Now, before all you MVC crazies out there start hammering me with complaints like "You shouldn't have logic in the view" and "You're breaking MVC and promoting bad programming" let me set one thing straight. The logic that will be in the view is display logic. The "V" in MVC is for the view, or presentation of data. We will be actually making the decision in the controller. So the actually programmatic logic is, in fact, in the controller. However, the result of said logic happens in the view, as it should. So, disclaimer over, lets move on, shall we? Moving on... Okay, adding a little logic to our view; here's the situation: You have this sidebar view and this ad view. We're going to set up a little logic to let the view decide when the ad gets loaded into the view. The reason could be that you have a public site that serves an ad, but logged-in, registered users get an ad-free experience. Regardless, the point is, you can see how this works with this example. You can easily extend the logic to say that non-logged in users get an ad and a sidebar, but logged in users get a control panel and a sidebar. Of course, you'd want to make sure for your layout, spacing, and all that you use classes. That way, when you replace something in the sidebar, its fluid and consistent. See how useful this can be? Something very basic... Okay, for now, lets start with something basic. We're going to set up an array called data, and we will assign an item in that array. The key will be "loggedIn" and we will manually set the value to "true." In the controller, you'll have this: function index () { $data['loggedIn'] = 'true'; $this->load->view('home', $data); } And in the view, you'll put this around your call for the ad: <?if ($loggedIn != "true") { ?> <?=$this->load->view('partials/ad')?> <? }?> Now, what you'll notice is since we set the value to "true," the ad does not load! However, go back in the controller and change the value to "false" or, better yet, leave it empty. Now you will see the ad presented. Okay, where's this "extensible" bit? Right here... Remember I told you we could extend this? Okay, let me show you how to do that. First, lets add another view file called "admin.php," and add a call for it in the view: <?=$this->load->view('admin')?> Now, we're going to expand on the logic that we put in the view. What we want is instead of a non-logged in user seeing an ad, we want the logged-in users to see their little control panel. It should look like this: <?if ($loggedIn != "true") {?> <?=$this->load->view('partials/ad')?> <?} else {?> <?=$this->load->view('partials/admin')?> <?}?> Now, if you have the value set to "true" you will see the sidebar and your admin panel. And if you are not logged in, you will see the sidebar and an ad. In closing... So, this concludes our discussion on view logic. As you can see, this method is very flexible. If you use your imagination, I'm confident you can extend this technique much, much further. In the next article in the series, I'll describe another method that allows for controlling all this decision logic inside the controller. Instructions 2007-11-25T03:41:00-05:00 http://www.mtheoryx.com/index.php/site/expressionengine_users_rss_patch_required/ http://www.mtheoryx.com/index.php/site/expressionengine_users_rss_patch_required/#When:21:06:00Z Special Announcement: So, as I was trying to set up FeedBurner for this site, I discovered there was an error with the RSS feed. Ugh. I'm using the most recent version of EE, so, I thought maybe I made an error in a template file. No, no. It wasn't me! If you are using EE 1.6.1 downloaded the EE 1.6.1 version right away (sometime before November 14th, 2007), you need do re-download the package from the site. Replace the following file in your install with the one from this new download: system > core > core.output.php file So, after replacing that file, the feed is valid....except for one thing... You'll still get this error: line 33, column 4: Missing atom:link with rel="self" Just ignore this. Your feed is valid...this is not an error, it's a recommendation by the authors of the validator. Apparently they are wanting you to use the Atom namespace to get at some features that you can't get with RSS 2.0. Politics. Further explanation of this, and discussion can be found in this forum thread on the EE boards. News 2007-11-23T21:06:00-05:00 http://www.mtheoryx.com/index.php/site/multiple_views_and_templating_with_code_igniter_method_1/ http://www.mtheoryx.com/index.php/site/multiple_views_and_templating_with_code_igniter_method_1/#When:16:48:00Z Why am I writing this? Over the past couple weeks, I've been asked several times what I feel the best method is for managing a template-like system in CodeIgniter. Instead of continually explaining the various different methods each and every time, I eventually started using a copy of a long IRC discussion on the subject to introduce users to the concept. Well, I still don't think it gets the point across, so we'll dive into it with this multi-part series. The basics: First, let's explain some basics: CodeIgniter (CI) is an MVC PHP framework. It is derived from ExpressionEngine and is quite flexible. Not as strict an implementation of MVC as something like CakePHP would be, CI still follows a set of defaults, and understanding the concepts behind these defaults is key. Let's take a peek at the CI User Guide for a moment. When you render a view from your controller, what you are doing, essentially, is passing program control from the controller to the view. In the MVC model, this means moving into the presentation and interaction part of the model. So, in your controller, you would have: $this->load->view('yourView'); And you will have a view named "yourView.php" Now, how about those time-saving templates? This is the method to call the view. Now, lets say that you want all your views to have some shared elements. For example, on this site, the header, sidebar, and footer are the same on ever page. It would be silly to actually put that code in every view. What if you got the site all done, and had 20 different view files. And suppose you realized that one of the links you added to your sidebar was wrong. Yeah, now you see the point of separating your shared code. So, in your view, instead of all that header stuff, create a file called "header.php" and place all of your header code in there. After calling the "yourView.php" file, instead of all that header code, you would place this at the top of the view: $this->load->view('header'); This essentially performs an include, but does not pass program control to that view. In the view you would essentially have this for a pretty standard site: $this->load->view('header'); $this->load->view('navigation'); ...put the content unique to this view here... $this->load->view('sidebar'); $this->load->view('footer'); So, this is the basic way to manage a pseudo-templating system with CI. In the next example in the series, I'll show you how to start adding some decision making for the occasion that you may have views that wont have a sidebar or a footer. Instructions 2007-11-23T16:48:00-05:00