Any way to use $this->methodname() everywhere?

[marc]

Hey there,

 

just purchased the premium video library and working my way through (mostly) the advanced/oop php courses

Thanks a lot, really helpful so far!

 

I'm coding a tracking system atm, as a side project. To learn OO I've decided to do the system completly OO style using the MVC pattern.

Now after finishing Ben's OO log in turorial, I realized I was really confused with all the different method names and to which object they were assigned.

 

So I was thinking wouldn't it be great if you could just do $this->methodname everywhere in your code, no matter where...?

 

 

I was doing some research on that topic, but wasn't really successful, what I found was mentioned often is a registry type of class...

 

Now I'm not sure, does a registry do exactly what I described above? Acts like a piggy bank for classes, so objects are loaded into the registry and then you can access all your methods with just one $this prefix?

 

 

So it all comes down to two questions for me:

 

1. Is this what a registry is about?

2. And if not, is it possible to reference all your objects with $this->methodname, instead of creating numerous different handles for each object... or is that kind of a stupid idea?

 

 

 

Thanks a lot!

[falkencreative]

So I was thinking wouldn't it be great if you could just do $this->methodname everywhere in your code, no matter where...?

Then use regular functions, and avoid using OOP?

 

1 - yes and no. Yes, a registry object would be used to store information or to reuse objects... but you would probably refer to it by the object's name, not "$this". "$this" is a special reserved variable -- it is a way that an object can reference itself. As a general rule, you only use "$this" when within a class file. In most of my OOP code, the template object handles including the views, so the view is considered part of the Template object and that is why I use "$this" to refer to that template object.

 

Even if you were to create a registry object, you'd still be using "$this" within the registry object to refer to itself. It's just something that you'll get more familiar with the more experienced you get at OOP.

 

For more information on $this, see the text below "Defining class methods" header on http://net.tutsplus.com/tutorials/php/object-oriented-php-for-beginners/ or the top of the page on http://www.killerphp.com/tutorials/object-oriented-php/php-objects-page-2.php.

 

2 - Yes, you could create one central object that controls everything... but that defeats the purpose of OOP in the first place. At least in the way I use OOP, I like it because it allows me to separate my code into individual objects that have specific purposes. If I need to make changes or spot bugs, this separation of work makes it much easier/faster to identify which part of the code needs to be changed.

 

In my CMS tutorial series, I used a registry object to help neaten up the code... but I didn't use one central object that held all my methods. I had one central object that stored other objects. So, for example, since I called the CMS "Flightpath", I had a variable named "FP", and within that $FP object, I had my Template object, Authorization object, etc. I could then call those objects like this:

 

$FP->Template->method_name();

 

I still use "$this" extensively within my objects though, because that is the only way to reference the current object.

[marc]

I see, so basically I just have to have a procedure how I structure my framework and remember the class/method/property names, and if I don't remember it I know where to look because I have a standard procedure... That basically how I have to look at it?

 

I was confused at how you remembered all the method and property names etc, but I guess that's just because I am not experienced enough yet and OO is split across so many different files that it's irritating at first, because as of yet I am not quite sure about where some things belong, to a model, controller, or core object... So when I think about how I would find stuff later when the application is really big, I start to shiver

[falkencreative]

I see, so basically I just have to have a procedure how I structure my framework and remember the class/method/property names, and if I don't remember it I know where to look because I have a standard procedure... That basically how I have to look at it?

Correct. A lot of it is practice and experience -- the more you do it, the easier it gets. If you have an standardized way that you name your methods, and if those methods are organized into individual objects that each have specific roles (the Template object, the Authorization object, ect.), it should be relatively easy to look those method names up if you need them.

 

because as of yet I am not quite sure about where some things belong, to a model, controller, or core object

As a general rule, nearly all of the methods that you call (at least, they way I have coded things in the OOP Login series) come from a model. Exactly which model they come from depends on what they do. Methods relating to views and view data are most likely in the Template model, methods relating to login and authorization go in the Authorization model, etc. Controllers may call the model's methods, or may call functions (usually, standard functions built into PHP), but they won't have methods themselves. And Views are mostly just HTML and CSS, with a little PHP thrown in when they need to retrieve data or call something from the Template object.

 

Hope that helps?

[marc]

Yes I think that was a big help to me in terms of understanding how to structure my applications.

 

So basically you have the core structure, which consists also of controllers and models, but not the ones that are used to display views for example. And then you have the controllers and models that are only responsible for the views and getting data to the views?

 

So I would make for example a structure like:

 

application

----- models

----- controllers

----- views

----- core

 

While the core folder contains the models and controllers/dispatching system etc that are responsible for the whole system to work (autoloading classes, dispatching urls and so on)

 

and in the model & controller folders are only models and controllers that are responsible for the views and data output to my application.

 

 

 

That correct so far?

[falkencreative]

Quick question of my won before I answer your question... Which of my video series have you watched? Just the OOP Login series? Or the CMS series as well?

[marc]

So far only the oop login series, had a quick look at the cms series, not really watched any videos yet.

[falkencreative]

OK, first a quick recap of MVC:

 

• M: These are the model files -- they do the heavy lifting required by your web application. In many cases, the model will interact with the database and retrieve data as necessary.
  
• V: These are the views -- any files that get shown to the user. The way I do MVC (with a Template object that controls displaying the views) the views are composed of HTML and CSS, with a little bit of PHP thrown in to retrieve and display information.
  
• C: These files are the controllers -- When a visitor enters a URL, a controller gets accessed first. It decides based on the URL, any variables in the URL or any other data (like data from a submitted form) what actions need to be done, what models need to be accessed and what views need to be shown to the user.
  

 

Here's how I structure simple applications, for example, the OOP Login system:

 

Includes folder:

---- database.php (database settings)

---- init.php (application settings)

 

Models folder:

---- all models (Template, Auth, etc)

 

Views folder:

---- all .php view files

 

Resources folder:

---- this folder may contain other folders that contain images, javascript, and css files

 

login.php (controller)

logout.php (controller)

members.php (controller)

 

I'm running out of time, but I'll post/explain the structure for the CMS series later today.

[falkencreative]

The CMS series is a bit more complicated since I was trying to make the CMS as modular as possible so it was easy to add additional functionality. For example, rather than having one central folder that holds all models, I've created individual folders for each chunk of functionality. For example, the CMS folder contains all files (models, controllers and views) that is related to viewing and editing content.

 

All CMS related files/folders within an "App" folder, since I wanted to make sure that the site's frontend (what the normal user sees) and the site's backend (what an admin user sees) are separate:

 

-- Core Folder (by "core", I mean all functionality that is absolutely necessary just to set up and create the application, like the Templating object and the Auth object):

------ Models folder (holds all models relating to core functionality)

------ Views folder (holds all .php views relating to core functionality)

------ Templates folder (holds a couple template view files that the CMS needs, such as the CMS toolbar, header and footer, etc.)

------ core.php (technically this is a model -- it is the main $FP object that creates all the other objects necessary for the core application to function)

 

-- CMS Folder:

------ Models folder (holds all models relating to editing content)

------ Views folder (holds all .php views relating to editing content)

------ edit.php (controller)

 

-- Dashboard Folder:

------ Models folder (holds all models relating to dashboard)

------ Views folder (holds all .php views relating to dashboard)

------ index.php (dashboard controller)

 

-- Settings folder:

------ Models folder (holds all models relating to settings)

------ Views folder (holds all .php views relating to settings)

------ password.php (controller)

 

-- Resources folder

------ contains all CMS resources: images, javascript, css

 

-- init.php (cms settings)

-- login.php (controller)

-- logout.php (controller)

 

Hope that helps? Keep in mind: everyone does the MVC pattern a little differently, and different people will organize their files differently. This is simply what makes the most sense to me, and what feels most organized and straight-forward to me.

[marc]

Cool, thanks a lot Ben. This is really helpful.

 

I was under the impression there is only one way, but it makes sense now that you explained it that there are literally many ways that lead to rome...

So it's all about becoming more experienced, and the more experience I have the more logical will my approach be, I should just start developing my application, and when I see ways to improve I simply do it later!

 

Thanks man!