Simple model-view -separation

[Droolboy]

I'm trying to build a fairly small (max. 10 different pages) site
using php, and it's becoming obvious that I need some kind of model
view separation.

Having done a few searches, I've come across the concept of 'template
engines', but that seems like overkill for my needs. I'm thinking I'll
just stick with php as my template language; a little embedded code in
the view pages, for loops or whatever, should be ok..

I've come up with the following 'architecture', but would like some
feedback before i start working on it.
The heart of my site will be 'index.php'. Every request goes to that
page, with a parameter for picking the target 'page'.
"index.php?a=ho me", "index.php?a=ne ws", and so on.

Based on that parameter, the controller creates an instance of a class
for handling that type of request.

An 'if-else/switch' block including the file containing the logic
(model) file, creating an instance of the class inside?
Or should I create files named "model/home.php", "model/news.php" and
include these dynamically?

How do I name the classes or whatever's inside? Same name, but
different file included might work, but sounds like poooor design.
Creating an instance of class $somestring doable?
Once the logic is loaded, I plan on calling
$requestHandler->service(), which will somehow prepare the data we
plan on displaying. Will setting a global variable do the job?

$requestHandler->service() - or should i just use a global function,
there will only be one included, but I am better off placing it in a
class, right? - also returns a string, which is the url to the correct
'view'.

This page is then include(?)d, and, using the globally declared
$myTableData, it puts up a nice page with a table of data for the
user's browser..?

[Chung Leong]

"rush" <pi**@rush.aval on.hr> wrote in message
news:cc******** **@ls219.htnet. hr...

"Droolboy" <te*******@hotm ail.com> wrote in message
news:36******** *************** ***@posting.goo gle.com...
b) use inheritance and polymorhism (like you have different midpage gadgets, then you have several sibling classes that implement them but all of them do so through function getMidPageConte nt() )

I disagree with that. Inheritance should only be used to extend the
functionality of a class (hence the "extends" keyword). It's pointless to
try to emulate polymorphism in PHP, as it's not an end in itself but a mean
for strict typing languages like C++ to implement interfaces. In PHP 4 you
can archieve that simply by using the same method name, while PHP 5 allows
you to explicitly define an interface.

--
Obey the Clown - http://www.conradish.net/bobo/

[Tim Van Wassenhove]

In article <pe************ *************** *****@4ax.com>, Jochen Daum wrote:

Hi Tim,

On 5 Jul 2004 11:14:54 GMT, Tim Van Wassenhove <eu**@pi.be> wrote:

In article <cc**********@s olaria.cc.gatec h.edu>, Salil Das wrote:

The heart of my site will be 'index.php'. Every request goes to that
page, with a parameter for picking the target 'page'.
"index.php?a=ho me", "index.php?a=ne ws", and so on.

The key to this architecture is that it makes authentication and loggin
stuff very easy and comprehensive and also makes the site secure, in the
sense that you control the pages the user can see. THe user does not this 
way have complete access to ur webserver. You could block/password protect
rest of your pages

Most "architectu res" allow stuff to be logged. And allow you to control
which pages are public and which are not. So would you mind telling us
what separates this "architectu re" from others?

I agree with the others. his architecture allows you to control all
this from one point, which can be a php script, database or whatever.

But my question remains, what separates it from other "architectures" ?

If everyting has to pass through a controller, you end up with some
serious overhead when fe images are requested because most of the times
they don't need access to a database etc... And if you decide they
should not be handled by the controller, you are more or less saying
that not everything should be passed through such a controller.

So instead of using a controller script, i prefer to use the webserver
that maps request to scripts/pages. And the webserver has nice logging
functionalities too. Most of my scripts do have some "common" code. So
each script that needs this, can include/require(_once) it. No more, no
less. I know you will say: But then each scripts needs to have a line
that includes the "common" stuff. And then i answer: No, if you really
want it, you can also use the auto_prepend/ auto_append option :)

So i see the same functionalities ... But not the overhead, because i
have a only use what you need strategy.

--
Tim Van Wassenhove <http://home.mysth.be/~timvw>

[rush]

"Chung Leong" <ch***********@ hotmail.com> wrote in message
news:xa******** ************@co mcast.com...

I disagree with that. Inheritance should only be used to extend the
functionality of a class (hence the "extends" keyword). It's pointless to
try to emulate polymorphism in PHP, as it's not an end in itself but a mean for strict typing languages like C++ to implement interfaces. In PHP 4 you
can archieve that simply by using the same method name, while PHP 5 allows
you to explicitly define an interface.

As far as I know, polymorphism has come to existance in Smalltalk (as many
other OO thingies), which is dynamically typed object oriented language, and
had nothing to do with overcomming restrictions of statically typed OO
languages. In that sense PHP as dynamically typed is much closer to some OO
tenets than some other statically typed languages as java or C++ (but php
befeore 5 had some other serious problems). Popular statically typed OO
languages have skewed (in negative way imho) what OO is, and what are it's
strenghts. As Alan Kay (this year Turning Award recipient) has said
(approx): "I have invented OO, and I can tell you I did not have C++ in
mind".

rush
--
http://www.templatetamer.com/

[Henk Verhoeven]

Hi,

Very simple:

--------------------someScript.php---------------

require_once('c lasses/MainControllerC lass.php');
$controller =& new MainController( );
$controller->handleRequest( );

----------classes/MainControllerC lass.php ----------------
class MainController {

function handleRequest() {
include('views/main.php');
}

function printSomething( ) {
//do the printing
}
}
---------------views/main.php-----------------------
<HTML>
<HEAD>
</HEAD>
<BODY>
<!-- here could be some layout -->

<?php $this->printSomething () ?>

<!-- here could be more layout -->
</BODY>
------------------------------------------------------
of course the names should be specific. The view could call more methods
on the controller. There could be methods like delegateToSubCo ntroller()
taht create a new controller and delegates the request handling. The
subcontroller could again include a view script for more layout.

Our framework works like this. For more info and a diagram see:
http://www.phppeanuts.org/site/index...principle.html

If you want to avoid the complexity of the framework,
download its source (download page) but then only look into the source
of pntUnit/index.php and whatever is called from there, and what is
called from there, etc .
PntUnit is for unittesting. It does not use the framework but follows
the MVC pattern the same way as the framework does. The idiom is a
little bit different from the above example: a subcontroller is called a
'part', creating it and delegating to it is called
print<partname> Part(), a view script is called a 'skin'.

( pntUnit can be tried on line too:
http://www.phppeanuts.org/examples/pntUnit/index.php )

Greetings,

Henk Verhoeven,
www.phpPeanuts.org.

Droolboy wrote:

I'm trying to build a fairly small (max. 10 different pages) site
using php, and it's becoming obvious that I need some kind of model
view separation.

Having done a few searches, I've come across the concept of 'template
engines', but that seems like overkill for my needs. I'm thinking I'll
just stick with php as my template language; a little embedded code in
the view pages, for loops or whatever, should be ok..

I've come up with the following 'architecture', but would like some
feedback before i start working on it.
The heart of my site will be 'index.php'. Every request goes to that
page, with a parameter for picking the target 'page'.
"index.php?a=ho me", "index.php?a=ne ws", and so on.

Based on that parameter, the controller creates an instance of a class
for handling that type of request.

An 'if-else/switch' block including the file containing the logic
(model) file, creating an instance of the class inside?
Or should I create files named "model/home.php", "model/news.php" and
include these dynamically?

How do I name the classes or whatever's inside? Same name, but
different file included might work, but sounds like poooor design.
Creating an instance of class $somestring doable?
Once the logic is loaded, I plan on calling
$requestHandler->service(), which will somehow prepare the data we
plan on displaying. Will setting a global variable do the job?

$requestHandler->service() - or should i just use a global function,
there will only be one included, but I am better off placing it in a
class, right? - also returns a string, which is the url to the correct
'view'.

This page is then include(?)d, and, using the globally declared
$myTableData, it puts up a nice page with a table of data for the
user's browser..?