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=home", "index.php?a=news", 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..?

[Tony Marston]

"Droolboy" <te*******@hotmail.com> wrote in message
news:36**************************@posting.google.c om...

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=home", "index.php?a=news", and so on.
This is called a "front controller". Read
http://www.phppatterns.com/index.php...leview/81/1/1/ for an
argument against it.
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..?

If you want to learn how to implement an infrastructure that combines the 3
tier architecture and the MVC (Model-View-Controller) design pattern then
take a look at http://www.tonymarston.co.uk/php-mys...structure.html
and http://www.tonymarston.co.uk/php-mys...ontroller.html.

If you visit http://www.tonymarston.net/php-mysql...plication.html
you will see links to a sample application which you can run online and
where you can download the source code.

Do not worry that this may be too complicated for a "small" application, as
such applications have a tendency to grow over a period of time. Also
consider the fact that if you practice on a small application you will be
better placed to expand it into a large application.

HTH.

--
Tony Marston

http://www.tonymarston.net

[Tim Van Wassenhove]

In article <36**************************@posting.google.com >, Droolboy wrote:

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..

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=home", "index.php?a=news", and so on.
Why would you do that? The webserver is many times better in mapping a
request to a page/script.
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?
As said before, a webserver has already the code to this. And it has
been tested many times before.
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?
I'm affraid i don't understand what you are trying to say here.
What would be the relationship between a class method and
a global variable?
$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'.
If i understand well, you don't know if you should or should not use OOP.
Meaby now is the time to read through some of the many sites that explain
the advantages (and disadvantages) of OOP.
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..?

So you end up with a method service that is able to include some
template and that template should only make use of the data in the
$myTableData.

It might be handy to have a paremeter for the service method, so that it
knows which template to include. Say you have a page/script that allows
some values to be posted. Once these values have been posted, a thank
you message should be displayed. So your script validates the data, and
based on that, it decides if it should show the form or that it should
say thank you. At the end it would be able to call
service('page_form.tpl') or service('page_thankyou.tpl').

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

[rush]

"Droolboy" <te*******@hotmail.com> wrote in message
news:36**************************@posting.google.c om...

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.

Hm, what you describe does not sound as Model-View-Controler (or Presenter)
to me, but anyway. If you do start using object oriented tactics, my advice
would be that you:
a) avoid using globas as much as possible (regarding the idea to stuff some
result in global)
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 getMidPageContent() )
c)I do not see why having one page that server all pages is such good idea.
It makes sense to me if it is just diplaying different data, and then you
pass data id to it. But when you have different types of code that servers
it, I would go with different pages. This also solves the problem how to
instantiate a correct class for each page. In super-handler approach you
would end up having a large switch choosing a class based on parameter, or
table look-up.

<shameless plug> if you at the end choose to reconsider usage of some
template engine, please feel free to mail me, and I'll try to advise how you
could approach your problem with TT ;) </shameless plug>

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

[Droolboy]

Tim Van Wassenhove <eu**@pi.be> wrote in message news:<2k************@uni-berlin.de>...

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?

I'm affraid i don't understand what you are trying to say here.
What would be the relationship between a class method and
a global variable?

My original post wasn't too coherent, I know :)

To rephrase, i planned on the following architecture:

All requests get fed to a front controller, which load and dispatch to
the appropriate business logic based on the 'action' parameter.

The business logic part does whatever it's supposed to, then place one
or more data holders with the results wherever my presentation layer
can reach it.
It then tells the controller which page is supposed to be rendered (or
it could just include() that page if there's no need for
post-filtering).

Finally, the appropriate 'view' page is include()'d, filling in
certain areas of the page reading properties from the data holder
objects my business logic stored somewhere - <?php
print($somedata->getMessageSubject()); ?> and so on.
Thanks to the feedback on front controllers, I'm not so sure I'll use
one of those anymore.

I do think the dataholder-model beats constructing my view
programatically, though, especially if I have to scatter the
statements through my logic.
But I may well have missed the entire point, as i've just been
skimming through the stuff i found on common template engines..?

[Droolboy]

"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message news:<cc*******************@news.demon.co.uk>...

"Droolboy" <te*******@hotmail.com> wrote in message
news:36**************************@posting.google.c om...

Do not worry that this may be too complicated for a "small" application, as
such applications have a tendency to grow over a period of time. Also
consider the fact that if you practice on a small application you will be
better placed to expand it into a large application.

HTH.

Interesting links.

DB -> XML -(XSLT)> XHTML _would_ be slightly overkill for my little app, though :)

[Tim Van Wassenhove]

In article <36**************************@posting.google.com >, Droolboy wrote:

Thanks to the feedback on front controllers, I'm not so sure I'll use
one of those anymore.
You'll be using one (but don't code it... the webserver does that for
you).

If you have some code that should be used in ever script, you could use
OOP and create a base class that contains that code. And then have every
script/page extend that base class. Or in case you don't go for OOP, the
auto_prepend setting can be usefull.
But I may well have missed the entire point, as i've just been
skimming through the stuff i found on common template engines..?

From my point of view there are 2 sorts of templates. Templates to
handle data and retrieve data from the database(s). And templates to
convert the data into nice output, fe xhtml.

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

[Salil Das]

Droolboy <te*******@hotmail.com> 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=home", "index.php?a=news", and so on.
I use such an architecture myself, and till now I have had no problems,
whether it be small applications or decently big projects.

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
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?
If the site starts gettin bigger, Instead of using a switch case, try using
a hash table for faster access to the model files needed. Agains this adds
efficency and security offer what pages the user can access
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..?

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Salil Das | It's ok to kiss a fool,
bugs@cc | It's ok to let a fool kiss you,
| but never ever let a kiss fool you.

[Tim Van Wassenhove]

In article <cc**********@solaria.cc.gatech.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=home", "index.php?a=news", 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 "architectures" 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 "architecture" from others?
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?

If the site starts gettin bigger, Instead of using a switch case, try using
a hash table for faster access to the model files needed. Agains this adds
efficency and security offer what pages the user can access

Do you really think your own code is faster/more secure than the code
that your webserver is using?
--
Tim Van Wassenhove <http://home.mysth.be/~timvw>

[Jochen Daum]

Hi Tim,

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

In article <cc**********@solaria.cc.gatech.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=home", "index.php?a=news", 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 "architectures" 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 "architecture" 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.

HTH, Jochen
--
Jochen Daum - Cabletalk Group Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/

[Chung Leong]

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

"Droolboy" <te*******@hotmail.com> wrote in message
news:36**************************@posting.google.c om...
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 getMidPageContent() )

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**********@solaria.cc.gatech.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=home", "index.php?a=news", 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 "architectures" 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 "architecture" 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********************@comcast.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('classes/MainControllerClass.php');
$controller =& new MainController();
$controller->handleRequest();

----------classes/MainControllerClass.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 delegateToSubController()
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=home", "index.php?a=news", 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..?