Welcome Guest, Not a member yet? Register   Sign In
Confused about variables
#11

(This post was last modified: 07-29-2016, 10:43 AM by MightBeABitLate. Edit Reason: spelling mistake )

MWhitney, PaulD, Dave,

Once again, I am extremely grateful for the high quality of the responses that I am receiving, and they encourage me to explore CI further. Your helpfulness is outstanding. All your posts are very very useful.

I think my confusion about variables vs constants was not adequately described.

I am happy with the difference between variables and constants in the context of PHP (and in most programming languages), and I understand MWhitney's point about defining properties for access from other classes, but it seems to me that within the context of CI....

Hmmm... just thinking out loud...

I think I've got this.....I HOPE I've got this...

You can declare variables within the constructor of the controller. You can then access and modify those variables within any of the controller methods RIGHT UP TO THE POINT AT WHICH YOU RENDER A VIEW.

So, for example, you might create a controller with a variable that holds a count of the entries in a database that met some criteria, and you could set that variable accordingly. You might then pass that result to other methods in your controller, and change that value for whatever reason, but once you render out that view with the data passed to the view, then the controller "disappears" for want of a better expression, and next time you instantiate that controller, all your variables are reset back to their default values as per the constructor.

That explains why my pseudo-code shown above always shows the $this->data['counter'] value as being 4 - because when the view calls the controller method, the controller class is a new version every time! And in order to make it increment, I would have to store the value in a database and read it in every time and then increment it - or store it in a session.

I think I've cracked it!

JB
Reply
#12

Yes, I think you've got it.

That said, it isn't the fact that the server replied to the browser (rendered out a view). It's just the CI actually does the output as part of the shutdown process. In other words, the controller script ends, if something is in the output buffer it is sent to the server. Whether it outputs something or not, CI then finishes its shutdown routine after which the server terminates the process thread, clears the allocated memory and forgets all about it what is just did. The next time the browser asks the server for the same URL it starts from scratch - creates a process thread, allocates memory for it, opens, interprets and executes the script.
Reply
#13

Dave

Once again - more clarity is added. That really helps to understand the process.

Thanks for your post.

JB
Reply
#14

Yes, that's more or less right, and I think any further differences are more semantics and wording than issues with understanding.

The sticky point with passing data to the View is that the Loader allows you to cache data for the View which it then merges with any data passed when loading the View before extracting the data into the scope in which the View is included. This is something to keep in mind when a variable contains something unexpected when you attempt to access it in your View (and is a reason you shouldn't try to call methods using $this-> in your View), but otherwise it's only useful when you want to know why $data['someVariable'] becomes $someVariable in the View.
Reply
#15

Hi friends,

By the way, how do you "control" or document your view variables? Example: at view code, I have a $foo var because it was injected by CI at controller, cool, but my IDE like Eclipse doesn't know this and thinks it's an undefined var...

Or, how to have some kind of "security" (sure) at view when using a var if it really was injected at the controller? How many vars and what vars?

My solution to this approach when working at a view code is to add some comment blocks at the beginning, something like this:

<?php
// This is a view, ok... Hum, we have some injected vars here, cool! But exactly what? This is the idea...

/* @var $myOrder Order */
/* @var $disabled bool */
/* etc... */

But as far as I know, this is a specific Eclipse feature.
Reply
#16

I'm generally pretty paranoid about variables in my Views, because, technically, your variables are defined by the context in which your View was loaded, and that context is determined by the Controller which loads it. In other words, your IDE is right in saying the variables are undefined, at least until you load the View in a Controller which loads the View and sets the values for those variables.

This is one of the issues which leads to fragmentation in how people handle MVC in general and Views specifically. Some people limit the number and types of variables they will use in a View. Other people create ViewModels and Presenters and other things which essentially create a layer between the Controller and the View to allow the Controller and View to be less dependent on one another. Even with something like that, your IDE isn't likely to be happy unless you do something like you've already done in comments, or initialize the variable with something like

PHP Code:
$something = isset($something) ? $something ''
Reply




Theme © iAndrew 2016 - Forum software by © MyBB