Design patterns

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Design patterns

Post by alex.barylski »

Page controller's

They are designed to handle the view and model/events for a particular page...

Reading some articles on page control, it seems many (including MSDN and other famous places) suggest that this pattern is only good for static linked websites...as updating the navigation, etc would become a burden...

They way I see it...why not use a template engine like Smarty...that way navigation is consistent across the board...

So I ask...in your opinion :)

A page controller, is responsible for handling events, working with the model and view for one physical web page (according to Fowler)

So the page controller would intereact with view controllers and model controller??? Page controller decides which gets invoked where as the atomic controller for view or model carry out the specific task at hand???

Code: Select all

class Page_Controller{
  function invoke()
  {
    switch($_GET){
      case 'update_user':
        Model_Controller::updateUser();
        break;
    }    
  }
}

class Model_Controller{
  function updateUser()
  {
    $fname = $_POST['first_name'];
    $fname = _secure($fname);

    $ado->Execute('INSERT  INTO table SET fname = "'.$fname.'"');
  }
}
In the example above: The page controller provides the wiring to invoke the atomic controllers, either view or model...

updateUser() for instance, would be an atomic controller as it's directly manipulating the model and therefore is bound to the model.

Would you agree, that this is a Page Controller???

One could almost argue...a page controller is *sort* of like a mini front controller :P

Cheers :)
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post by RobertGonzalez »

Is that a page controller or a front controller? Or is there a difference?
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Everah wrote:Is that a page controller or a front controller? Or is there a difference?
Page controller...

From what I can tell...there is a minor distinction between the two...

A front controller blindly determines "who" get's called whereas a page controller determines "what" get's called...

If that makes any sense...check the folwer page for more breif descriptions of both...his are likely most accurate, although vague especially in implementation details...

Basically they are akin, except for that distinction...

One is used in static URLs and the other is used for dynamic URL invokation...

At least from what I understand :)
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

Everah wrote:Is that a page controller or a front controller? Or is there a difference?
It's a page controller. There is a clear difference. I tend to think of it like this. A front controller manages your page controllers, the page controllers manage the model/view for that page.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

d11wtq wrote:
Everah wrote:Is that a page controller or a front controller? Or is there a difference?
It's a page controller. There is a clear difference. I tend to think of it like this. A front controller manages your page controllers, the page controllers manage the model/view for that page.
Thats how I see it as well... :P *high fives*

Thanks for confirming that for me...it's been bugging me all day... :)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

d11wtq wrote:
Everah wrote:Is that a page controller or a front controller? Or is there a difference?
It's a page controller. There is a clear difference. I tend to think of it like this. A front controller manages your page controllers, the page controllers manage the model/view for that page.
I agree that the above is some kind of Page Controller. But I don't think that the thing a Front Controller dispatches are exactly Page Controllers, because Page Controllers usually have some front end code -- which is the code that is move to the Front Controller. That's why they are usually called Actions or some such thing.
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

arborint wrote:
d11wtq wrote:
Everah wrote:Is that a page controller or a front controller? Or is there a difference?
It's a page controller. There is a clear difference. I tend to think of it like this. A front controller manages your page controllers, the page controllers manage the model/view for that page.
I agree that the above is some kind of Page Controller. But I don't think that the thing a Front Controller dispatches are exactly Page Controllers, because Page Controllers usually have some front end code -- which is the code that is move to the Front Controller. That's why they are usually called Actions or some such thing.
And here is where computer science becomes more of a computer art...

From what I understand and what "some" others feel (based on articles I've read which explicitly stated the conclusion I have come too; albeit not all, some definitions are so vague it could be interpreted as either, but none have explicitly stated it *cannot* be done) a front controller and page controller can be used in harmony..or not at all...

Which one you use or whether you use them in combination really depends on your application design...

In anycase I found a few more articles on Page Controllers and Front Controllers in the Java repository...so I'll have a read through them and see if my mind is changed :P

I gotta go buy a printer from Walmart...it's much easier reading articles in paper form :P

If anyone else has any opinions...comments, etc...I'd enjoy hearing your perspective...as I'm still open to change as of yet :) or Arborint if you feel like elaborating on your argument, feel free...I'm listening :)

Cheers :)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

d11wtq wrote:
Everah wrote:Is that a page controller or a front controller? Or is there a difference?
It's a page controller. There is a clear difference. I tend to think of it like this. A front controller manages your page controllers, the page controllers manage the model/view for that page.
Just a observation...or a statement or whatever...

I think it makes sense to further break down the problem into mini-controllers, so to speak...

You have a model controller (data sanitization, input checks, etc) and a view controller (prepare data for template engines, etc)

These mini-controllers are invoked by the page controller...

Make sense...? would you agree???
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Hockey wrote:And here is where computer science becomes more of a computer art...
No, here is where what is dispatched by a Front Controller is not defined (for good reason), but it can dispatch an object that is very similar or sometimes identical to how some programmers implement a Page Controlller. If you understand the reasons for implementating a Front Controlller or Page Controller then there is no confusion. Trying to compare patterns with intersecting functionality that are implemented for different reasons can cause confusion though.
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

No, here is where what is dispatched by a Front Controller is not defined (for good reason), but it can dispatch an object that is very similar or sometimes identical to how some programmers implement a Page Controlller
Exactly...you said it yourself...so it very well could be a page controller or some other object, etc...

No where have I read that a front controller *cannot* dispatch to a page controller...but I have read the opposite...so clearly...this is a matter of opinion...

Opinion is subjective...as is art and beauty of design...therefore, I still say this is when computer science becomes computer art...
If you understand the reasons for implementating a Front Controlller or Page Controller then there is no confusion
Again find me an "credible" article which stipulates they cannot be used in conjunction with each other...and I'll agree...until such time...I have to say it's matter of opinion... :P

p.s-I have literally read every article I could find on the subjects of page controller, front controllers and MVC...over 100 pages of printed text...i'm not going to write a book on design patterns, but I think I get the gist of the idea behind them...

Cheers :)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

If you have a second car and you hook it to the back of your car and tow it around filled with stuff that you deliver here and there -- is it a car or a trailer? It can be a car, but it is being used as a trailer. It's not a matter of opinion or "art" -- it is about how it is being used.

A Front Controller receives the request and dispatches an Action. A Page Controller receives the reqest and is the Action. If you have class that can act as a Page Controller, but it is dispatched by a Front Controller it is not longer being used as a Page Controller.

Patterns are solutions to problems, not implementations. Two seemingly identical pieces of code can be different patterns.
(#10850)
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post by RobertGonzalez »

Man, that is a lot to take in :D. One of these days I am going to get my hands on Design Patterns so I can follow (better) what you guys are always talking about.

I must say though, that this thread, as well as several others about Patterns of Design, have been very educational for me.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

A Front Controller receives the request and dispatches an Action. A Page Controller receives the reqest and is the Action.
...is the action :?:

Although that is the understanding I had...no where that I have read makes the distinction that clear...do you have any references???

I've been told that even the GoF state in their book, that design patterns are just that...and NOT a hardened specification to be adhere'd too. I have also been informed that design patterns are allowed to be intermixed/mingled with others...

This comes from another project I'm working on where I need to restrict a factory to returning only a single instance...therefore, I used both modeled the code after the singleton and factory...

After just saying that...what I've quoted above is where I am making the connection...

Re-read what you have said:
A Front Controller receives the request and dispatches an Action. A Page Controller receives the reqest and is the Action.
If the page controller is the *action* (was my impression and what you just said) and the front controller is what captures the requests and dispatches them...

Why can't a page controller be the recipient of a front controller dispatch???

What I quoted, basically says it all...and IMHO re-confirms what I originally understood...

The front controller does not need to dispatch to a page controller...but in everything I read...nowhere does it say it can't...and if you and I both agree the page controller is the action and a front controller sends the *action*

I dunno...I'm missing something...but this topic just got really convoluted :P

Cheers :)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Hockey wrote:I dunno...I'm missing something...but this topic just got really convoluted :P
Yes you are missing something. What you keep missing is that a pattern is a problem/solution not an implementation. Like my example of the car and trailer. A trailer is a pattern. It is towed by something and it is used to carry something -- that's a trailer. Many things can meet the definition of the trailer pattern. I gave the example of when a towed car can meet the definition of the trailer pattern. You can say "but it's a car!" all you want, but its usage is following the trailer pattern. I does not matter if it was implemented as a car -- if it is being used as a trailer it is following the trailer pattern.

Likewise with controllers. If it handles the request AND then dispatches a separate thing that creates the "page" -- it is a Front Controller. If it handles the request AND also creates the "page" it is a Page Controller. However, if it DOES NOT handle the request, but it does create the "page" then it DOES NOT follow the Page Controller pattern. Whether (like the car used as a trailer) is can also be use as a Page Controller does not matter. Controllers that DO NOT handle the request, but do create the "page" are usually called a Commands or Action Controllers.

The thing that Front Controllers and Page Controllers share is what Fowler calls an Input Controller -- Actions do not contain the Input Controller part. In fact, the Actions dispatched by a Front Controller do not even need to be controllers.

It is essential that you understand that patterns are described as a problem and a solution -- not an implementation. To quote the pertinent part of the Page Controller pattern from Fowler:

"As a result, Page Controller has one input controller for each logical page of the Web site. "

The Front Controller pattern identifies a potential problem with the Page Controller pattern:

"If the input controller behavior is scattered across multiple objects, much of this behavior can end up duplicated. "

And gives a possible solution:

"The Front Controller consolidates all request handling by channeling requests through a single handler object. "

It is only convoluted if you make it so...
(#10850)
alvinphp
Forum Contributor
Posts: 380
Joined: Wed Sep 21, 2005 11:47 am

Re: Design patterns

Post by alvinphp »

Hockey wrote:A page controller, is responsible for handling events, working with the model and view for one physical web page (according to Fowler)

So the page controller would intereact with view controllers and model controller??? Page controller decides which gets invoked where as the atomic controller for view or model carry out the specific task at hand???
The page controller does not call any more controllers. The page controller handles the users request that the Front Controller delegated to it. So if you wanted to do a user update your Front Controller would delegate controller responsibility to your User Page Controller which would then call the update_user method in the DB_User_Manager class and the check_that_user_can_do_this_update method from the User_Authorization class and any other methods you might need. Your same User Page Controller would then include your templates to build the page.
Post Reply