My big OOP hurdle...

[KevinM1]

I get the basics.  I know what a Singleton is.  I know what Composition is, in comparison to Inheritance.  I understand the basics of PHP's flavor of polymorphism.  But I still can't envision how everything ties together, how these classes and objects are tied into a true web application.

 

I believe my biggest stumbling block is how to structure a PHP web app.  Most of my (limited) OOP experience comes from C++ land, where the program is still running in the background, awaiting user input, while the user is served a new view based on that input.  For example, in C++ I can create a simple program that acts like a shopping cart.  I can add products, view what's in the cart, and check out of the store.  Doing any of these things changes the view I receive -- the same executable is running in the background, waiting for me to do one of those three things.

 

In PHP, it doesn't seem to be that easy.  If I want to view my shopping cart, I create a link or form button which brings me to another page.  How is this done, while keeping the app 'in place,' so to speak?  Are all objects serialized and passed to the new pages via sessions?  Or is there one main script which merely displays different views based on what's been passed to it (links w/$_GET values and $_POSTed form values)?  If both approaches are used, then when would they be used?  What are the tradeoffs?  Most importantly, and if it isn't too much trouble, are there any examples one of you can give?

 

Thanks a bunch!   I think I'll finally get it if I can see some examples of this sort of thing.

[KevinM1]

I figure that I haven't received any replies for one of two reasons:

 

1. This thread should be in the application layout/design subforum.  If that's the case, then please feel free to move it there.

2. I didn't describe my problem well.  I'll try to remedy that here.

 

I think the best way to describe my confusion is to talk about PHP web app overhead -- how much setup work is required for each page.  Obviously, this depends on the project at hand, and what it entails, but I can't think of a real elegant way to deal with this.  Instead, two methods of dealing with this overhead come to mind:

 

1: In the point-of-entry (POE) script (index.php, or whatever the first page the user should access), do all of the setup -- initialize objects, setup their relationships, etc.  For each page/script the user could potentially access after that, forward the objects to those pages via sessions.  If the user hasn't visited the POE script, redirect them there.

 

This obviously has several flaws.  First, forcing the user to visit the POE script is a bit barbaric, especially if they come wandering into another portion of the site from a Google search or forum message link.  Second, there's a lot of code repetition -- every script has to see if anything was set in the session, unpack and handle that info, then put it back into a session before the user navigates away.  There are probably other weaknesses as well, but those are the two most obvious ones.

 

2: Have one main script run and decide what view to show.  Every link and form submit would return to the main script, whose logic is to display the right view based on what was passed to it.  I believe this is more or less what a Page Controller and/or Front Controller does, but don't quote me on that.  This seems like it could get messy upfront, and could perhaps be dangerous if the $_GET values aren't scrubbed properly.

 

Again, there's code repetition.  Sessions would once agan have to be used.  Upon each main script reload, the session variables would have to be checked, unpacked and handled, and packed back up again.  The benefit, though, is that this code appears only once.

 

Now, are either of these approaches realistic?  If given a choice, I'd go with the second option, as it seems more logical and appeals to my amateur C++ coding side.  Am I on the right track, or am I missing something fundamental?

[scottybwoy]

I think your half way to getting on the right track.  I'm probably not the best person to answer your question either.  I haven't really coded in C++ so can't point out the differences.

 

I can however pick out where I think you are going wrong.

 

You don't need to use sessions, until you want something to be available throughout the script, like userdata, a cart perhaps, the users level of admission etc.

 

You would only need to force users to a point of entry script, if you needed them to do anything there i.e log in.

 

My current framework does pretty much what you said in your 2nd point.  Since everything pretty much relates to an index.php, thats a good way to start.  A benefit of that is passing users directly to securer areas of you directory, without having them specifically executing the file.  Also if you look at the URI for this thread you can see that the way you got here, was one being passed to the relevant index.php which was given a $_GET handle and id file so that it can be easily accessed and sought via google etc.

 

Generally you must always control the $_GET data and it should be intrinsic to your framework.  All the other data that that is sent via $_POST and is user inputted, should go through some sort of validation and serialisation methods to stop your script from being broken or security breached.

 

I think that should send you on your way a little.  But maybe someone else can elaborate more or give sum basic examples.  Good Luck and happy coding

[deadimp]

Heh, you mentioned applying your C++ logic to PHP. A post from GDNet: http://www.gamedev.net/community/forums/topic.asp?topic_id=390500

The basic jist of it is, when you're programming in PHP, focus on PHP.

 

I think I know what you're going through, wondering how persistence might work with your applications. Well, the only thing I have to say is that yes, the scripts are run essentially from scratch on every request. Luckily the monotony of it all can be reduced by using cache, be it low-level prefetch data on your script generated by your PHP engine, or high-level cache structures included in whatever framework you may be using. Still, on each request the script is ran from the top - that's one of the reasons why PHP can be added as an HTTP module, so it doesn't have to restart the engine on each request.

 

[KevinM1]

Thanks, both of you.  I'm happy to see I'm somewhat on the right track.  It looks like a hybrid approach would work best: a POE script for each large subsection of a site (user area, admin, forums, etc) which basically go the Page Controller route.  Awesome!

 

Heh, you mentioned applying your C++ logic to PHP. A post from GDNet: http://www.gamedev.net/community/forums/topic.asp?topic_id=390500

The basic jist of it is, when you're programming in PHP, focus on PHP.

 

I think I know what you're going through, wondering how persistence might work with your applications. Well, the only thing I have to say is that yes, the scripts are run essentially from scratch on every request. Luckily the monotony of it all can be reduced by using cache, be it low-level prefetch data on your script generated by your PHP engine, or high-level cache structures included in whatever framework you may be using. Still, on each request the script is ran from the top - that's one of the reasons why PHP can be added as an HTTP module, so it doesn't have to restart the engine on each request.

 

I was wondering if you could elaborate a bit.  I'm not currently using any framework (stupid?  probably, but I want to get the basics down first before adding another layer of complexity).  I was wondering if you could further describe the "low-level prefetch data" caching you mentioned.  I'm not exactly sure what you mean by that.  Also, is there any way to see if PHP is acting as an HTTP module?  Would this be visible in a phpinfo() call?

 

Thanks again!

[deadimp]

The "low-level prefetch data" was more or less of a guess on my part - I should have said that before. The basic idea would be like that of Java or an interpreted language, where some of the byte code generated from the script is stored and used again if the raw format of the script (text) hadn't been changed. If you want to learn more on this, you probably ought to go to the Core PHP Hacking forum.

 

If you're able to view your PHP files on your server by just marking them with the *.php extension (or whatever else you designate in your httpd.conf file).

I'd say more, but I gotta go.

[aschk]

Unfortunately i hit this hurdle to (in a manner of speaking). You can read books and internet blogs/articles all you like and grasp the basics nice and easily for OOP, however when you sit down to do an enterprise application, all of a sudden it becomes a lot more complicated. I sympathize entirely. I guess it's just a matter of getting down to it and finding your own way to understand it. As for PHP vs C++, obviously the differences are Stateless vs Stateful. So forget a lot of things you expect from C++ and start working slightly differently. Ever call is a NEW call which requires initialisation of various objects/parameters and then build everything up to get to where you need to be.

[448191]

Thanks, both of you.  I'm happy to see I'm somewhat on the right track.  It looks like a hybrid approach would work best: a POE script for each large subsection of a site (user area, admin, forums, etc) which basically go the Page Controller route.  Awesome!

 

Why oh why would you want to use anything remotely like Page Controller?

[KevinM1]

Thanks, both of you.  I'm happy to see I'm somewhat on the right track.  It looks like a hybrid approach would work best: a POE script for each large subsection of a site (user area, admin, forums, etc) which basically go the Page Controller route.  Awesome!

 

Why oh why would you want to use anything remotely like Page Controller?

 

It seems, to my limited experience, to be the most obvious way to go about things in a general sense.  I know you're one of the OOP gurus on here (when I have time, I always try to find your posts in the layout/design subforum), so what would you suggest?

[Jenk]

Thanks, both of you.  I'm happy to see I'm somewhat on the right track.  It looks like a hybrid approach would work best: a POE script for each large subsection of a site (user area, admin, forums, etc) which basically go the Page Controller route.  Awesome!

 

Why oh why would you want to use anything remotely like Page Controller?

Page controllers are very useful. They are nothing more than sub-controllers.

http://martinfowler.com/eaaCatalog/pageController.html

[448191]

They are nothing more than sub-controllers.

 

I disagree. That is not what Fowler meant with "Page Controller". While he does mention Front- and Page Controller combinations (PoEAA[335]), even then he describes the combo as "some pages handled by a Front Controller, some by a page Controller".

 

One of the key properties of Page Controller is that, in contradiction to Front Controller, it provides decentralized accesspoints for webrequests. ALL of Fowlers' examples reflect this. The first uses different servlets, the second different JSPs, the third different ASPs.

 

Granted one can reinterpret patterns and shift overlapping responsibilities by combining them, the main problem I have with calling Page Controller a "sub-controller" is that it is confusing. It does not reflect Fowler's intent when describing Page Controller.

 

Fowler even goes as far as saying that strictly, Page Controllers tie in to actions. Which makes perfect sense, and is a testament to Page Controller as a simple solution, unconcerned with matters like resolving a request to a given action (which is in fact done by the Web server).

[Jenk]

It is a sub-controller, because it takes a fork of information, then whittles it down further still.

 

I'd imagine you have met this scenario a few times before, you have an admin area of say a forum - so you'll have a controller for the admin area. This admin area has several areas of function for it, user maintenance, etc.

 

A Page Controller would be assigned one of those functions each, as such you have the first action (Select user to maintain), then at least one more action for that function (i.e. make your changes) - all the while, the main controller knows you are using the admin area, the next controller knows you are still in user maintenance, then your page controller knows you have moved to the next stage of user maintenance (or finished.)

 

A Front Controller translates from a raw request into usable data, interprets which action is to be fired, and fires it. The discussion of Front Controllers in PHP is debatable, some argue Apache/IIS is the front controller, others argue that is outside the context of PHP.

[448191]

A Page Controller would be assigned one of those functions each, as such you have the first action (Select user to maintain), then at least one more action for that function (i.e. make your changes) - all the while, the main controller knows you are using the admin area, the next controller knows you are still in user maintenance, then your page controller knows you have moved to the next stage of user maintenance (or finished.)

 

Call it "sub controller", "domain controller", but don't call it Page Controller. Like I said, that's not what Fowler meant, supported by his examples and repeated mention of the choice BETWEEN Front Controller and Page Controller. The very first responsibility of Page Controller mentioned by Fowler is that of "decoding the URL and extract any form data to figure out all the data for the action". In the scenario above, I would assume this is done by in a central place like the Front Controller.

 

Where just talking names here, but I hope you can agree that for the sake of clarity, you shouldn't reinterpret patterns without changing the handle.

 

A Front Controller translates from a raw request into usable data, interprets which action is to be fired, and fires it. The discussion of Front Controllers in PHP is debatable, some argue Apache/IIS is the front controller, others argue that is outside the context of PHP.

 

I am aware of this discussion, and frankly I think it's a bit silly. A Java servlet needs a Web server (wheter it be Apache/IIS or the build-in Tomcat server) to process the HTTP requests just as badly as a PHP bootstrap file. I've yet to come across an argument that invalidates the use of Front Controller in PHP, and I don't think I will.

 

[KevinM1]

Okay, so...what does a "main controller" look like?  That's the conceptual hurdle I'm having trouble with -- the main thing that generates and/or contains the rest of the site's architecture.  Is there typically just one main controller for an entire site?

[Jenk]

Yes.

[448191]

Typically and ideally, yes.

[KevinM1]

So, how would this main controller actually work?  For, instance, in Jenk's hypothetical of having a forum administrator access and perhaps modify another user's account (perhaps to temporarily ban them from the forum for some infraction), how would something like that actually function?

 

I'm assuming that you'd have the main controller, but how would the sub-controllers be invoked?  Would they be in separate files and include()-ed based on what Request was sent to the controller (I'm thinking of the Command pattern from the Zandstra book, specifically the CommandContext class, which had an array, in part, constructed from $_REQUEST)?

 

I dunno...I'm just having a hard time seeing how it would all fall into place.  I keep feeling that I'm overthinking this whole thing as I haven't been exposed to anything like this in PHP.  Most of the admittedly horrible largescale PHP code I've been exposed to has been in the form of a ton of files, each one actually visited by the user.  So, if a site administrator wanted to ban a user, they'd be sent to something like a /admin/manageusers.php file.  This file, like the rest, would have its own HTML embedded within.  I keep thinking there has to be more, some trick to the OOP way of doing things.

[Jenk]

It's important to only have one level deep transparency. That is to say, the main controller will only know/see the sub-controller below it. If that sub-controller needs to start another controller, the main controller does not need to know this.

 

Let's take a url..

 

foo.php?controller=main&subcontroller=foo&somethingesle=bar.

 

The front controller will only need to see the ver "controller" we can see it has the value of "main" so it will start which ever process is necessary for "main".

public function run () {
  if (isset($_GET['controller']) {
    switch $_GET['controller'] {
      case 'main': 
        $sub = new SubController;
        break;

      case 'notmain':
        $sub = new AnotherSubController;
        break;
    }
    $sub->run($_GET);
  }
}

So, next the subcontroller checks the value of "subcontroller" and takes appropriate action.

public function run ($vars) {
  switch $vars['subcontroller'] {
    case 'foo':
      $this->fooAction();
      break;

    case 'bar':
      $this->barAction();
      break;
  }
}

 

and so forth.. sub controllers are often used for process like I described before, where multiple requests/stages will be used to complete a single objective or functionality. For example, the value of "subcontroller" could be "step1" or "step2" etc.

[trq]

Nightslyr, do yourself a favour, download and install codeignitor and have a read through the user guide. Alot of the concepts will click into place within a few hours, I know they did for me. Its a pretty simple framework so its easy to see how the underlying concepts work togther. I'm not saying you need to use it, but its pretty easy to learn / get ideas from.

[KevinM1]

I can't seem to get a complete download of Code Ignitor.  WinRAR keeps telling me the .zip has been damaged.  Is there another method of obtaining the framework?

[trq]

Actually, I think I remember having the same issue. Hold on a sec.

[trq]

Yeah, sorry, don't think I can help.

[redbullmarky]

you may actually get similar results (from an educational point of view) downloading CakePHP, as it's similar in a huge way to CodeIgniter (just a little more complex )

 

you may find the following article useful to get stuck straight in to how things are working:

 

http://www.thinkingphp.org/2006/09/25/learning-from-the-cakephp-source-code-part-i/

 

and Cake's manual isn't too shabby these days. However, CodeIgniter's manual is very good and easy to follow, yet alot of the stuff in there can very easily be translated to Cake.

 

Good luck!