Page 1 of 3

Single index.php or Multiple Script

Posted: Thu Apr 20, 2006 3:57 pm
by alex.barylski
When you develop an web application which technique do you prefer or use?

I personally use a single monolithic index.php with page state variables

I find everything much cleaner this way...

Previous to that approach I used a template engine, but used seperate scripts for every page, etc...

Which do you prefer?

Posted: Thu Apr 20, 2006 4:04 pm
by feyd
I've used several: single script, multiple scripts, pathinfo (script delegator)..

Of the three there, I honestly can't really put one above the others. I guess the line of development I'm moving down right now is with page controllers and custom view constructs that get loaded if and when needed so I guess single script/pathinfo as the main interaction point.

Posted: Thu Apr 20, 2006 4:12 pm
by RobertGonzalez
One of the projects I am working on right now I am trying to develop using a single page for user interaction. Before that, I was literally using a different page for every single page view possible. I doubt that I am going to be doing that again. I believe I am going to minimalize a lot of the viewable pages into as few pages as possible.

Posted: Thu Apr 20, 2006 11:06 pm
by Christopher
This is really a Front Controller vs Page Controllers discussion. At this point I am using a Front Controller per "application" within a site. So I consider, for example, the adminstrative area or a forum to be separate apps from the main site. I find it makes the apps more modular to build them that way.

Re: Single index.php or Multiple Script

Posted: Fri Apr 21, 2006 3:09 am
by alvinphp
I prefer using the index file as the front controller and build my site around MVC as I prefer the seperation as it makes it easier (for me) to work with and scale.

Posted: Fri Apr 21, 2006 3:18 am
by Chris Corbyn
arborint wrote:This is really a Front Controller vs Page Controllers discussion.
Agreed. I prefer to have separate controllers for each section since I prefer the way the URL's come together... granted it's more work for the developer to pull in the core components for each controller to operate.

In reality it's not black and white though. There's no reason you can't have a range of front-controller-like pages which bind elements of a module, or multiple modules together.

Posted: Fri Apr 21, 2006 3:36 am
by Maugrim_The_Reaper
Similar to last few sentiments I'm currently using Front Controllers - so I may have a few FCs designated to several front end files - index.php, admin.php, etc. which implement different FCs specific to a group of tasks and/or authorisation levels.

Posted: Fri Apr 21, 2006 11:37 am
by n00b Saibot
I always use Front Controller without knowing that it is Front Controller 8O

Posted: Fri Apr 21, 2006 11:49 am
by Chris Corbyn
n00b Saibot wrote:I always use Front Controller without knowing that it is Front Controller 8O
"Front Controller" is one out of a few concepts used in MVC. I used to write web apps as a novice that had the index page directing requests off to other scripts (via include() ) but everything was still essentially a spaghetti so I wouldn't consider it a Front Controller. MVC, helps to tidy things up a heck of a lot (and as a result, also speeds up development time due to less bugs or bugs being spotted quicker). Typically your controller will access your data model and your view components making it a sort of glue between your data and your template.

Posted: Fri Apr 21, 2006 12:29 pm
by n00b Saibot
OK. let's take it a little further. you can comment on whatever that is called (or maybe I have created a new controller type :? :lol: )

I have this main include file where I store the head, foot, imp. routines of site. there is a config file thru which i can control any aspect of site. then there are classes for each aspect I require e.g. DB Access, Input Validation, different features of site like emailing, access control, session handling etc.

now every page contains just the bare minimal code reqd. for its running.

so what it is exactly??? 8)

Posted: Fri Apr 21, 2006 12:41 pm
by Chris Corbyn
n00b Saibot wrote:OK. let's take it a little further. you can comment on whatever that is called (or maybe I have created a new controller type :? :lol: )

I have this main include file where I store the head, foot, imp. routines of site. there is a config file thru which i can control any aspect of site. then there are classes for each aspect I require e.g. DB Access, Input Validation, different features of site like emailing, access control, session handling etc.

now every page contains just the bare minimal code reqd. for its running.

so what it is exactly??? 8)
It might not neccessarily fit into an actual documented design pattern ;) Nobody says that using a given pattern is the definitive way to write your applications, these are just known to be strong methods. It does sound a bit like you're using a front controller but you didn't mention anything to do with the view side of things. i.e. do you use templates?

We're going off-topic here so perhaps it's worth starting a new thread to discuss this :)

Posted: Fri Apr 21, 2006 1:06 pm
by Christopher
n00b Saibot wrote:I have this main include file w ... now every page contains just the bare minimal code reqd. for its running.
That sounds like Page Controllers, which is the usual way that PHP apps are built. WIth Page Controllers there are multiple entry points for the application. WIth a Front Controller there is just one entry point (e.g. index.php) for the application and the selection of the "page" is done via parameters.

I used to have a more even attitude about Page Controllers and Front Controllers until I converted a couple of sites from Page Controllers to a Front Controller. I was amazed at the amount of cruft and redundant code that I had crept in there that was masked by the use of Page Controllers. Conversely they allow for a little more slack like that -- which can be ok a well.

Posted: Fri Apr 21, 2006 1:35 pm
by alex.barylski
d11wtq wrote:
n00b Saibot wrote:I always use Front Controller without knowing that it is Front Controller 8O
"Front Controller" is one out of a few concepts used in MVC. I used to write web apps as a novice that had the index page directing requests off to other scripts (via include() ) but everything was still essentially a spaghetti so I wouldn't consider it a Front Controller. MVC, helps to tidy things up a heck of a lot (and as a result, also speeds up development time due to less bugs or bugs being spotted quicker). Typically your controller will access your data model and your view components making it a sort of glue between your data and your template.
I am familiar with MVC and have used many implementations or derivatives, such as the document/view model in Windows MFC applications, etc...

However I have yet to use anything formal in PHP - mostly cause I don't yet see the advtange over a single index.php using page request variables and includes. If you care to explain your take on it, i'm listening... ;)

I have read all easily found and obvious articles, perhaps skimming through as opposed to trying to fully absorb the material, which might help, however I still don't *get it*

I know what the parts are Model-View-Controller, but I see using index.php as a page request handler using a template engine to generate displays (HTML/PHP separation right there) and thus supplying the templates with required data, as emulating MVC.

I see it as:

index.php emulates the model
Templates emulate the view
Scripts emulate the controller

I know this isn't ideal MVC in the strictest sense, but I still get satisfactory seperation between:

1) Program logic and Templates
2) Actions or user requests are executed in modular scripts called via templates and FORM actions, etc...

I see that index.php is somewhat emulating 2 parts of the MVC pattern (from what I can tell)

As it determines which templates to load and it also takes care of business logic, etc and then supplying templates with this informaiton, I suppose it implements:

1) Model
2) View - which indirectly handles action requests and acts as the controller?

Just my take on the subject thus far... :P

Cheers :)

Posted: Fri Apr 21, 2006 2:43 pm
by Christopher
Hockey wrote: index.php emulates the model
Templates emulate the view
Scripts emulate the controller
index.php is definitely not the Model -- the Model which should be kept in separate files in all but the simplest apps.
Tempaltes are part of the view and can be most of it, but something has to register template vars.
Scripts (meaning everything else) usually are the Controller, but Transaction Scripts that combine the Model and Controller are very common in PHP.
Hockey wrote:I know this isn't ideal MVC in the strictest sense, but I still get satisfactory seperation between:

1) Program logic and Templates
2) Actions or user requests are executed in modular scripts called via templates and FORM actions, etc...
I am not sure what "Program logic" is here. Part of the point of MVC is to separate Domain logic, Display logic and Program Flow logic with clean dependencies. I am sure what "called via templates and form" means?
Hockey wrote:I see that index.php is somewhat emulating 2 parts of the MVC pattern (from what I can tell)
index.php may contain parts of the View and Controller -- but it's not emulating anything.
Hockey wrote:As it determines which templates to load and it also takes care of business logic, etc and then supplying templates with this informaiton, I suppose it implements:

1) Model
2) View - which indirectly handles action requests and acts as the controller?
Whether it directly or indirectly acts as a Controller it is still doing that task.

I know I harp on this, but the confusing thing about MVC is that it is about separation and dependencies and not about code organization. As long as the dependencies are clear, parts of the View and Controller can be scattered across several classes and files -- and often are. MVC is at its core about two separations.

The first is between the Model and the Presentation (View+Controller) layers. I consider that separation the most important thing that programmers can achieve in any design -- it is 80-90% of the benefit of MVC in my opinion. Separating your data and business logic so it is independent of the rest of your code is essential in my opinion.

The second separation is between the View and the Controller. That is the difficult one because it take a lot of experience to decide where to draw the line for each application. And it may not matter that much in most cases. MVC can be done all in one file, or split into many files.

Finally the Front Controller has nothing to do with MVC. A Front Controller is often part of the Controller, but does not have to be. They are certainly complementary and it is often the case that programmers that "get" one probably "get" the other as well.

Posted: Fri Apr 21, 2006 3:16 pm
by alex.barylski
It's clear to me I need to read up on design patterns...

I have heard and read all of what you've just told me...

And I get it, but it's still not answering the questions which I have or explains what I don't understand...

And here's the kicker...I'm not even sure what it is that confuses me, so I can't even ask the right questions :P