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

[Tony Marston]

"Droolboy" <te*******@hotm ail.com> wrote in message
news:36******** *************** ***@posting.goo gle.com...

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.
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=ho me", "index.php?a=ne ws", 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_f orm.tpl') or service('page_t hankyou.tpl').

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

[rush]

"Droolboy" <te*******@hotm ail.com> wrote in message
news:36******** *************** ***@posting.goo gle.com...

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 getMidPageConte nt() )
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->getMessageSubj ect()); ?> 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.de mon.co.uk> wrote in message news:<cc******* ************@ne ws.demon.co.uk> ...

"Droolboy" <te*******@hotm ail.com> wrote in message
news:36******** *************** ***@posting.goo gle.com...

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*******@hotm ail.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=ho me", "index.php?a=ne ws", 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**********@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?
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**********@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.

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