Page 1 of 1

Design Centric Design Pattern

Posted: Sat Oct 06, 2007 8:54 am
by jimthunderbird
Hi All,

Just finished one more project and I'm going to set some time on writing my own php framework..., but I might start from a different angle.

My company starts as a printing-design and tradeshow company and in recent years jump on the web arena.There are many design-gurus, but I found that once I mentioned things like "Perl,Ruby, MySQL, Mod_Rewrite, PHP Framework...", they instantly get bored, but whenever they see those fancy AJAX and flash interactive sites, they are lighted up by fire. Their way of thinking is quite different. (what they call the left brain and right brain?)

On this project I'm involved, I used a different way..., instead of planning the application controllers, drawing data diagrams, doodling some ideas on the paper while they there listening to rock music for fear of falling asleep, I always talk with them with screenshots or dummy html pages showing how this project will look like. They are happy and they don't care how the data in those dummy pages are processed.

At the same time, I set aside sometimes every day studing many MVC frameworks, after a deep study of ROR, CakePHP, CodeIgnitor, I found they all share this pattern:

1. A request of the page comes in
2. The dispatcher send that request to a controller
3. The controller then render different views

It's like

Request->Dispatcher->Controller->Views

But what if I start from another angle:

1. Set up different possible views.
2. Fill the view with possible data.
3. Each view then maps to one controller.
4. The controller then corresponds to each request.

It's like

Views->Controllers->Dispatcher->Request

So it's like start from bottom to top.

The controller only process possible signals (link request, form post...).
Controller get and process data through models.

If a view is discarded, the corresponding controller will be discarded too. Here I think maybe "The view is the controller".

I found that I finished the project faster than I used to.

Is this pattern sort of "View Centric" and what do you think of this pattern?

Sincerely,
Jim

Posted: Sat Oct 06, 2007 1:07 pm
by John Cartwright
Views->Controllers->Dispatcher->Request
This really confuses me. The purpose of the dispatcher is to determine which controller to route to..

I really don't want to comment furthur without understanding exactly what this is you've created. Do you have any code samples?

Posted: Sat Oct 06, 2007 1:31 pm
by Zoxive
Jcart wrote:This really confuses me. The purpose of the dispatcher is to determine which controller to route to..

I really don't want to comment further without understanding exactly what this is you've created. Do you have any code samples?
I had the same problem, and didn't leave a comment.



How does the View load a Controller? and then Go to the Dispatcher? and then Request? What?

The request is whats used in the Dispatcher to determine what controller to load.


How does the View Know what to Display without a Request?

Posted: Sat Oct 06, 2007 1:32 pm
by Christopher
My guess is that you have lapsed back to Transaction Scripts. They are faster and easier to code -- the first time.

Posted: Sat Oct 06, 2007 7:38 pm
by jimthunderbird
Hi All,
Thanks for your attentions.

I think my idea is basically "there's only one view associated with each controllers".

Example:

Suppose on an application there are 3 different types of users, A and B and C, there's one single login page let them fill in the username and password, after logging in, they will see their customized contents depends on their user type.

There are 2 ways to do it.

1. create a controller named "Usercontent", then check the log-in user type:
if it's A --- render view_A
if it's B --- render view_B
if it's C --- render view_C
here, one controller associated with 3 views

2. create 3 pages named UserContent_A, UserContent_B and UserContent_C, but each page has already a view built into it, that means, they are "a controller with html code", maybe I will call them "presenter"?

For each presenter, it might contains some form process (example: user post a comment and then those comments are list in the same page),this is handed to the corresponding "pure controller", which a controller just for routing and processing signals.

Which way do you think is better?

I had to admit that I got confused a bit on the definition of MVC and wish like to learn more.

By the way, arborint, I found that my previous "self-made" MVC framework during converting a ROR application looks more closely to CodeIgnitor (90%), but CI is more mature and had many features I did not think about yet. I like CI more than Cake now since it's lighter weight and also, I like CI's $this->model->load("mymodel"). I think it better illustrate what a model is then even ROR, since I found ROR tends to base the model on a database table, it's not so flexible.


With my best,
Jim

Posted: Sat Oct 06, 2007 9:35 pm
by Christopher
Which do I think is better? It is really not a matter of better...

It really does not matter if there are "3 different types of users". If there is different program flow then there is different controller code. If there are, for one of many reasons, different responses to a request then there are different views. The controller and view can be combined (I have always been OK with that). If you further combine the model into the mix then you are implementing a Transaction Script (which I am OK with as long as you are truly fully aware of breaking the domain/presentation separation).

No matter how you combine it you have program flow, response generation and domain logic/data. The first thing is to identify them. Then you decide whether or how to separate them.