FrontController Design Pattern and Code Reuse

[bigoxygen]

Hi.

I'm using a 3 tier FrontController Design for my web application right
now.
The problem is that I'm finding to have to duplicate a lot of code for
similar functions; for example, listing users, and listing assignments
use similar type commands. Is there a "better" way I can organize my
code?

[Tim Van Wassenhove]

On 2005-03-10, bi*******@gmail.com <bi*******@gmail.com> wrote:

I'm using a 3 tier FrontController Design for my web application right
now.
Doesn't seem to be relevant.
The problem is that I'm finding to have to duplicate a lot of code for
similar functions; for example, listing users, and listing assignments
use similar type commands. Is there a "better" way I can organize my
code?

You probably want to write a library/class to generate a generic list of
data. After that it's only a matter of using that library with the
concrete data.
--
Met vriendelijke groeten,
Tim Van Wassenhove <http://www.timvw.info>

[Bent Stigsen]

Tim Van Wassenhove wrote:

On 2005-03-10, bi*******@gmail.com <bi*******@gmail.com> wrote:

[snip]

The problem is that I'm finding to have to duplicate a lot of code for
similar functions; for example, listing users, and listing assignments
use similar type commands. Is there a "better" way I can organize my
code?

You probably want to write a library/class to generate a generic list of
data. After that it's only a matter of using that library with the
concrete data.

True, but forget your C/C++ background for a moment ;)

PHP have arrays and functions like "array_walk" to traverse an array.
/Bent

[Tim Van Wassenhove]

On 2005-03-11, Bent Stigsen <ng***@thevoid.dk> wrote:

Tim Van Wassenhove wrote:

On 2005-03-10, bi*******@gmail.com <bi*******@gmail.com> wrote:

[snip]

The problem is that I'm finding to have to duplicate a lot of code for
similar functions; for example, listing users, and listing assignments
use similar type commands. Is there a "better" way I can organize my
code?

You probably want to write a library/class to generate a generic list of
data. After that it's only a matter of using that library with the
concrete data.

True, but forget your C/C++ background for a moment ;)

PHP have arrays and functions like "array_walk" to traverse an array.

I was not referring to a stl list (=collection)

I was referring to a construct like (note that this is an oversimplified
example because usually you'll end up with a Script that has a
data/model, a view, and usually a controller component.)

class ListScript
{
function run()
{
$data = $this->getData();
$this->render($data);
}

function render($data)
{
// wrap html around the data
}

function getData()
{
// retrieve data
}
}

class UserList extends ListScript
{
function getData()
{
// retrieve userdata
}
}

$script = new ListScript;
$script->run();

--
Met vriendelijke groeten,
Tim Van Wassenhove <http://www.timvw.info>

[Kenneth Downs]

bi*******@gmail.com wrote:

Hi.
Hi.

I'm using a 3 tier FrontController Design for my web application right
now.
Good.
The problem is that I'm finding to have to duplicate a lot of code for
similar functions; for example, listing users, and listing assignments
use similar type commands. Is there a "better" way I can organize my
code?

First off, with PHP, a FrontController, if I understand how the term is
being used in this world, is the best way to go.

For the listing of users, assignments, and so forth, this is the basic
problem of similar needs. You will spend the rest of your career
identifying and dealing with repeating patterns of need, presentation,
processing, and so forth.

The Big Answer these days is Object Orientation. IMHO this is vastly
overrated and seems to create a tunnel vision that oftentimes can prevent
you from seeing simpler solutions. In OO you would make a class called
"lister" and then you would create subclasses for "user listing",
"assignment listing" and so forth.

The other big answer is data-driven libraries. You have a library or
utility called "lister". The lister accepts data and parameters and
returns HTML.

In both cases you need some core code that generates the HTML, and in both
cases you may need some 2nd layer code that obtains the data, such as a
directory walker, a table scanner and so forth, but the library is simpler
and requires less code overall.
--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)

[Tony Marston]

"Kenneth Downs" <kn**************@see.sigblock> wrote in message
news:48************@pluto.downsfam.net...

bi*******@gmail.com wrote:

Hi.
Hi.

I'm using a 3 tier FrontController Design for my web application right
now.

Good.

The problem is that I'm finding to have to duplicate a lot of code for
similar functions; for example, listing users, and listing assignments
use similar type commands. Is there a "better" way I can organize my
code?

First off, with PHP, a FrontController, if I understand how the term is
being used in this world, is the best way to go.

There are those who would disagree. take a look at the folowing links:
http://www.phppatterns.com/index.php...leview/81/1/1/
http://www.tonymarston.co.uk/php-mys...faq.html#faq02

Individual page controllers are better for PHP/Apache
For the listing of users, assignments, and so forth, this is the basic
problem of similar needs. You will spend the rest of your career
identifying and dealing with repeating patterns of need, presentation,
processing, and so forth.
Not if you design your 3 Tier architecture properly with reusable
components. If you can also include a bit of MVC at the same time you can
increase the volume of resuable components and therefore spend less time
repeating yourself. take a look at
http://www.tonymarston.co.uk/php-mys...ml#reusability
The Big Answer these days is Object Orientation. IMHO this is vastly
overrated and seems to create a tunnel vision that oftentimes can prevent
you from seeing simpler solutions. In OO you would make a class called
"lister" and then you would create subclasses for "user listing",
"assignment listing" and so forth.
In the MVC world classes for User and Assignment would exist as Models (or
the Business layer in 3 Tier) while Lister should exist as a Controller (or
Presentation layer in the 3 Tier world). In an efficient implementation it
should not be necessary to create a Controller subclass for each component
in the Model - for example, I can use my single Lister component to access
any Model component without requiring any alterations whatsoever
The other big answer is data-driven libraries. You have a library or
utility called "lister". The lister accepts data and parameters and
returns HTML.
In the MVC world the Controller deals with the HTTP requests, talks to the
Model, then passes control to the View to generate the necessary output
which may be (X)HTML, XML, PDF or whatever.
In both cases you need some core code that generates the HTML, and in both
cases you may need some 2nd layer code that obtains the data, such as a
directory walker, a table scanner and so forth, but the library is simpler
and requires less code overall.

Take a look at http://www.tonymarston.net/php-mysql...plication.html
if you want to see a working example of 3 Tier plus MVC in action.

--
Tony Marston

http://www.tonymarston.net

[Kenneth Downs]

Tony Marston wrote:

"Kenneth Downs" <kn**************@see.sigblock> wrote in message
news:48************@pluto.downsfam.net...

bi*******@gmail.com wrote:

Hi.
Hi.

I'm using a 3 tier FrontController Design for my web application right
now.

Good.

The problem is that I'm finding to have to duplicate a lot of code for
similar functions; for example, listing users, and listing assignments
use similar type commands. Is there a "better" way I can organize my
code?

First off, with PHP, a FrontController, if I understand how the term is
being used in this world, is the best way to go.

There are those who would disagree. take a look at the folowing links:
http://www.phppatterns.com/index.php...leview/81/1/1/
http://www.tonymarston.co.uk/php-mys...faq.html#faq02

Individual page controllers are better for PHP/Apache

Thanks, but I've seen them.

They both demonstrate precise thinking and solid reasoning, but they also
reveal the perspective of programmers who like to program. As somebody who
has done my share of programming, I seek not to organize code but to
eliminate it. A Framework is all about how to create code, which is not
our goal. Our framework exists only because our libraries don't (yet)
handle all of the cases we need, and so the framework exists to insert
exceptions, but it is not the normal course of events to create a system by
coding.

When you focus on providing a rich experience through simplicity, the
FrontController tends to fall out of the design process rather naturally.
It may not fit with a heavily OO design, but it fits very well with a
data-centric transcational design.

For the listing of users, assignments, and so forth, this is the basic
problem of similar needs. You will spend the rest of your career
identifying and dealing with repeating patterns of need, presentation,
processing, and so forth.
Not if you design your 3 Tier architecture properly with reusable
components. If you can also include a bit of MVC at the same time you can
increase the volume of resuable components and therefore spend less time
repeating yourself. take a look at

http://www.tonymarston.co.uk/php-mys...ml#reusability
No Virginia, there is no reusable code. The asset value of code is given by
its useful lifetime and how easily it can be invoked by new systems. By
this measure, there are legacy COBOL programs decades old that are being
"reused" more than any PHP program that exists or may ever exist.

Languages are like human beings, of each and every one of them you can say,
"This too shall pass." It's hard now to picture the death of PHP, but 10
years ago it was hard to imagine the passing of Foxpro and 20 years ago it
was hard to predict the passing of the Vax, and so on.

Code is a non-portable depreciating asset, but data is a portable
appreciating asset. Data tends to be useful far past the death of the code
that first handled it. My college records were processed on a Vax that is
long since retired, but those records still exist, ported to a new
platform. And when that platform is retired they will be ported again. In
the US, records of our civil war that were preserved on index cards for 100
years have been loaded into databases. Data survives, code does not.

So the best way to organize your 3-tier app is to have all three tiers
depend on *data*, not code. This means an extensive data dictionary is far
far more important than any OO implementation of it.

The Big Answer these days is Object Orientation. IMHO this is vastly
overrated and seems to create a tunnel vision that oftentimes can prevent
you from seeing simpler solutions. In OO you would make a class called
"lister" and then you would create subclasses for "user listing",
"assignment listing" and so forth.

In the MVC world classes for User and Assignment would exist as Models (or
the Business layer in 3 Tier) while Lister should exist as a Controller
(or Presentation layer in the 3 Tier world). In an efficient
implementation it should not be necessary to create a Controller subclass
for each component in the Model - for example, I can use my single Lister
component to access any Model component without requiring any alterations
whatsoever

See above.

The other big answer is data-driven libraries. You have a library or
utility called "lister". The lister accepts data and parameters and
returns HTML.

In the MVC world the Controller deals with the HTTP requests, talks to the
Model, then passes control to the View to generate the necessary output
which may be (X)HTML, XML, PDF or whatever.

In both cases you need some core code that generates the HTML, and in
both cases you may need some 2nd layer code that obtains the data, such
as a directory walker, a table scanner and so forth, but the library is
simpler and requires less code overall.

Take a look at
http://www.tonymarston.net/php-mysql...plication.html if you want
to see a working example of 3 Tier plus MVC in action.

Thanks I've seen them. Extremely labor intensive by our standards, may as
well be using .Net.

--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)

[Tony Marston]

"Kenneth Downs" <kn**************@see.sigblock> wrote in message
news:<gr************@pluto.downsfam.net>...

Tony Marston wrote:

"Kenneth Downs" <kn**************@see.sigblock> wrote in message news:48************@pluto.downsfam.net...

bi*******@gmail.com wrote: Hi. Hi. I'm using a 3 tier FrontController Design for my web application right now. Good. The problem is that I'm finding to have to duplicate a lot of code for similar functions; for example, listing users, and listing assignments use similar type commands. Is there a "better" way I can organize my code? First off, with PHP, a FrontController, if I understand how the term is being used in this world, is the best way to go. There are those who would disagree. take a look at the folowing links: http://www.phppatterns.com/index.php...leview/81/1/1/ http://www.tonymarston.co.uk/php-mys...faq.html#faq02 Individual page controllers are better for PHP/Apache Thanks, but I've seen them. They both demonstrate precise thinking and solid reasoning, but they also reveal the perspective of programmers who like to program. As somebody who has done my share of programming, I seek not to organize code but to eliminate it.
An impossible dream, I fear, that has existed for decades but has yet to see
the light of day. The simple truth is that it is impossible to write
applications without writing code somewhere along the line.
A Framework is all about how to create code, which is not our goal.
I disagee. A framework is not about creating code but about creating working
components with, hopefully, as little effort as possible. This can only be
achieved by maximising the use of standard pre-written code and minimising
the use of custom code.
Our framework exists only because our libraries
By 'our libraries' do you mean the libraries that you have created for your
personal use, or the libraries that are generally available as part of the
language?
don't (yet) handle all of the cases we need, and so the framework exists to insert exceptions, but it is not the normal course of events to create a system by coding.
Tell that to the fairies, and the millions of programmers who do nothing
each day but create systems by coding.
When you focus on providing a rich experience through simplicity, the FrontController tends to fall out of the design process rather naturally. It may not fit with a heavily OO design, but it fits very well with a data-centric transcational design.
Not in my experience, it doesn't. I have programmed in various 2nd, 3rd and
4th generation languages in the past 25+ years, and I have never used a
front controller. As a Front Controller does not offer any advantages over
individual Page Controllers I see absolutely no point in switch.
For the listing of users, assignments, and so forth, this is the basic problem of similar needs. You will spend the rest of your career identifying and dealing with repeating patterns of need, presentation, processing, and so forth. Not if you design your 3 Tier architecture properly with reusable components. If you can also include a bit of MVC at the same time you can increase the volume of resuable components and therefore spend less time repeating yourself. take a look at http://www.tonymarston.co.uk/php-mys...ller.html#reus ability No Virginia, there is no reusable code.
Then you need your eyes tested. Each XSL stylesheet is used more than once.
Each page controller is used more than once. Each table class is used more
than once. Surely 'used more than once' qualifies as 'reusable'?
The asset value of code is given by its useful lifetime and how easily it can be invoked by new systems. By this measure, there are legacy COBOL programs decades old that are being "reused" more than any PHP program that exists or may ever exist.
Code being 'executed' is not the same as code being 're-used'.
Languages are like human beings, of each and every one of them you can say, "This too shall pass." It's hard now to picture the death of PHP, but 10 years ago it was hard to imagine the passing of Foxpro and 20 years ago it was hard to predict the passing of the Vax, and so on. Code is a non-portable depreciating asset,
Absolute rubbish! Modern programming languages provide portable code which
can run on a variety of hardware platforms, not just the one on which it was
originally developed. Also, code does not depreciate or wear out with age.
When a program is executed it makes no difference whether the code was
written 10 minutes ago or 10 years ago - it still runs the same.
but data is a portable appreciating asset.
Not necessarily. It depends on what the data is and how it is stored. Some
data only has value when it is current, so when it becomes out of date it
has no value at all, other than historical interest. Also, there is data
provided by numerous space probes which was stored on magnetic tape while
waiting to be processed. As the data arrived much faster that it could be
processed the library of magnetic tapes grew larger and larger.
Unfortunately the ability to process this library of data is fast
diminishing as the devices required to read these old-fashioned magnetic
tapes are no longer available (except in museums).
Data tends to be useful far past the death of the code that first handled it. My college records were processed on a Vax that is long since retired, but those records still exist, ported to a new platform. And when that platform is retired they will be ported again. In the US, records of our civil war that were preserved on index cards for 100 years have been loaded into databases. Data survives, code does not. So the best way to organize your 3-tier app is to have all three tiers depend on *data*, not code.
Then you have a peculiar notion of what the 3-tier architecture is all
about. It is not about the data that passes through each of the 3 tiers, it
is all about how the data is processed in each of the 3 tiers, and that
processing requires code. The really clever trick is to write code that can
handle new applications with new data with the minimum of effort. No matter
what you seem to think it is impossible to develop applications without new
code being developed somewhere along the line.
This means an extensive data dictionary is far far more important than any OO implementation of it.
I have used data dictionaries in several languages, so I know how valuable
they can be. That is why I am currently developing one for my own PHP
infrastructure.
The Big Answer these days is Object Orientation. IMHO this is vastly overrated and seems to create a tunnel vision that oftentimes can prevent you from seeing simpler solutions. In OO you would make a class called "lister" and then you would create subclasses for "user listing", "assignment listing" and so forth. In the MVC world classes for User and Assignment would exist as Models (or the Business layer in 3 Tier) while Lister should exist as a Controller (or Presentation layer in the 3 Tier world). In an efficient implementation it should not be necessary to create a Controller subclass for each component in the Model - for example, I can use my single Lister component to access any Model component without requiring any alterations whatsoever See above. The other big answer is data-driven libraries. You have a library or utility called "lister". The lister accepts data and parameters and returns HTML. In the MVC world the Controller deals with the HTTP requests, talks to the Model, then passes control to the View to generate the necessary output which may be (X)HTML, XML, PDF or whatever. In both cases you need some core code that generates the HTML, and in both cases you may need some 2nd layer code that obtains the data, such as a directory walker, a table scanner and so forth, but the library is simpler and requires less code overall.

Take a look at http://www.tonymarston.net/php-mysql...plication.html if you want to see a working example of 3 Tier plus MVC in action.

Thanks I've seen them. Extremely labor intensive by our standards, may as well be using .Net.
You don't know what the term 'labor intensive' really means. I once worked
on somebody else's infrastructure which took 10 days to write a simple
Search screen and List screen. With my own infrastructure I can create a
complete family of screens - Search, List, Create, Read, Update and Delete -
in under 1 hour.

You seem to be implying that you can generate new applications almost
instantaneously without writing a single line of code. If that is the case I
suggest you market your methodology and watch the money roll in as you are
clearly onto a winner! A guru such as yourself should be basking on a beach
in the Bahamas and not trolling the newsgroups with the rest of us
common-or-garden code monkeys.
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth@(Sec)ure(Dat)a(.com)

[Kenneth Downs]

Tony Marston wrote:

When you focus on providing a rich experience through simplicity, the

FrontController tends to fall out of the design process rather

naturally. It may not fit with a heavily OO design, but it fits very

well with a data-centric transcational design.

Not in my experience, it doesn't. I have programmed in various 2nd, 3rd
and 4th generation languages in the past 25+ years, and I have never used
a front controller. As a Front Controller does not offer any advantages
over individual Page Controllers I see absolutely no point in switch.

As you are a fish and I am a bird, I will not try to persuade you of the
advantages of flight, nor are you likely to persuade me of the relevance of
the fresh vs. salt-water debate.

But I hope we can discuss smaller parts of these issues in other threads.

--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)

[Henk Verhoeven]

bi*******@gmail.com wrote:

Hi.

I'm using a 3 tier FrontController Design for my web application right
now.
The problem is that I'm finding to have to duplicate a lot of code for
similar functions; for example, listing users, and listing assignments
use similar type commands. Is there a "better" way I can organize my
code?

In general, if you are already doing functional decomposition and you
still have repeating code (patterns), you can choose between inheritance
and delegation to get rid of them. The latter is usually more flexible
but more work to implement and maintain. One could describe object
oriented design as simply a matter of choosing the best alternative. The
trouble is that basically every statement and use of variables in your
code is one other place where you can make these choices, and every
choice you make does potentially change the options space for all the
other choices. So because of how your own mind works you do need more
ways to structure the options space then just choosing between
inheritance and delegation. Here semantics come into the picture, so you
try to make meaningfull classes and try to refactor, see what it does to
your code (patterns), then reconsider the choices you made.

IMHO the only reason to have a front controller can be becuase handling
all different kinds of http requests has some things in common. And the
only reason not to delegate from there to other objects can be becuase
all of what ever happens during all http requests can be elegantly fit
into one single class hierarchy. Even for a simple website this is
usually not the case, so you'll obviously need delegation.

But when a front controller delegates, it looses control. So it can only
do those things that are common to all http requests either first
(before it delegates), or last. Unless of course the delegates have a
reference back to the front controller. Then they can make a callback like
$this->parentController->doSomeCommonTask();

Of course you can repeat this trick for the delegates, that themselves
can delegate and get callbacks, resulting in a hierarchy of controllers,
or however you want to call them. This will probably lead to classes
that specialize in differnt kinds of parts of your pages, like listings,
widgets, menu items etc. I think it is usefull to build those. But you
can also download them, you can still add some more wherever you need to ;-)

Greetings,

Henk verhoeven.

Links:
http://www.phppeanuts.org/site/index...Popup/web.html
http://www.phppeanuts.org/site/index...rts/parts.html