One of the most important and least understood aspects of design patterns is that they are a language for talking about programming. Design patterns were originally "invented" by an architect as a way for architects, developers, planners and construction crews to all use a common lanugage while designing and building things.Hockey wrote:It's clear to me I need to read up on design patterns...
Single index.php or Multiple Script
Moderator: General Moderators
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
(#10850)
IMHO, you are a little tiny bit off.Hockey wrote: index.php emulates the model
Templates emulate the view
Scripts emulate the controller
Model = Your methods (ie functions) and classes
View = This is your output. So your DTHML
Controller = This is the code that determines what methods (from your model) should be called. In a Front controller patter it would be your index page, however controllers can be throughout your application.
I am a little weary of promoting patterns because I feel people jump right into them without first understanding what I consider the basics of programming like MVC, OOP, and (though not a coding style) UML.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
php_auto_prepend would, by definition, not be a Front Controller because it would be common code included in every entry point to the app. If there are many entry points then they are Page Controllers.timvw wrote:Imho php_auto_prepend is much nicer way to implement a FrontController instead of routing everything via index.php
(#10850)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
The Model is not all your methods or functions, it is only those in the Domain layer. In PHP that's usually the database access stuff and the code that is often called business logic.alvinphp wrote:Model = Your methods (ie functions) and classes
View = This is your output. So your DTHML
Controller = This is the code that determines what methods (from your model) should be called. In a Front controller patter it would be your index page, however controllers can be throughout your application.
The View is not just the DHTML, but any display code as well.
The Controller is every else.
(#10850)
@arborint: I wanted to ask how you define a FrontController.. But i seem to have found it already...
It first i found that http://example.com/foo.php and http://example.com/bar.php are as different entry points as http://example.com/index.php?page=foo and http://example.com/index.php?page=bar are but with a little effort i was able to figure out the differences...
For you, a FrontController application would have entrypoints that have the same hier_part (net_path | abs_path) parts in their URI and the differences are only allowed in the ?query part. Thus, whenever one chooses for a FrontController he forces himself into this URI scheme... Where you can get the same functionality with auto_prepend (or a simple include in the parts of the application that want to use it) without the URI constraint.
The way i see it, with auto_preppend there is a single entry point, namely the code that is prepended. And yes, that code can use parameters too to choose to include/redirect to a different page and eventually exit.arborint wrote: 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.
It first i found that http://example.com/foo.php and http://example.com/bar.php are as different entry points as http://example.com/index.php?page=foo and http://example.com/index.php?page=bar are but with a little effort i was able to figure out the differences...
For you, a FrontController application would have entrypoints that have the same hier_part (net_path | abs_path) parts in their URI and the differences are only allowed in the ?query part. Thus, whenever one chooses for a FrontController he forces himself into this URI scheme... Where you can get the same functionality with auto_prepend (or a simple include in the parts of the application that want to use it) without the URI constraint.
Last edited by timvw on Fri Apr 21, 2006 7:47 pm, edited 1 time in total.
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Yes index.php is certainly not the model at all. index.php would be a sort of request redirector if you please.arborint wrote:index.php is definitely not the Model -- the Model which should be kept in separate files in all but the simplest apps.
In MVC (everyone has their own view on this) I see this:
Model: A database layer via one or two classes to connect to a DBMS and manage queries, along with somme module-specific data handlers.
View: Templates, and the engine that handles them... end of!!!
Controller: The part that deal with what the user does: i.e. changing the result of what GET, POST and SESSION contain, it looks at what the user does, communicates with the model and passes the result back to the view (what the user sees) possibly using a response handler in the process.
Sounds great in writing but admittedly I often find my controller and my model blending together
I think some are confusing MVC with 3-Tier Architecture (Presentation, Business Logic, Database). Here is a quote from wikipedia on MVC
I also found this article that explains 3-Tier architecture quite well. http://www.zend.com/zend/tut/tutsweatpart1.php* Model: The domain-specific representation of the information on which the application operates. The model is another name for the domain layer. Domain logic adds meaning to raw data (e.g. calculating if today is the user's birthday, or the totals, taxes and shipping charges for shopping cart items).
* View: Renders the model into a form suitable for interaction, typically a user interface element. MVC is often seen in web applications, where the view is the HTML page and the code which gathers dynamic data for the page.
* Controller: Responds to events, typically user actions, and invokes changes on the model and perhaps the view.
* Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention this data access layer, because it is understood to be underneath or encapsulated by the Model.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
This actually shows the subtle difference between Front and Page Controllers. The upshot for me is that with Page Controllers there are multiple places for my bad habits to create bad code. With the Front Controller, all of my bad decisions are all in one place for me to enjoy.timvw wrote:It first i found that http://example.com/foo.php and http://example.com/bar.php are as different entry points as http://example.com/index.php?page=foo and http://example.com/index.php?page=bar are but with a little effort i was able to figure out the differences...
(#10850)
- AKA Panama Jack
- Forum Regular
- Posts: 878
- Joined: Mon Nov 14, 2005 4:21 pm
Re: Single index.php or Multiple Script
Interesting how most people posting went off on tangents without really answering your question.Hockey wrote: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?
First question they should have asked is...
"Are you using a CMS backend that controls all of the menus, selections and content?"
If you are using a CMS backend then you will probably be using a single index.php program to build each page based upon the get/post values. This usually results in a much SMALLER index.php for controlling everything instead of a massive index.php or many smaller php files for each page.
If you are NOT using a CMS backend then using a monolithic index.php is going to be detrimental in the long run. It really is considerably harder to debug, expand and track down issues that may arise. You would be better off sectioning out every page into seperate page files. This will make it considerably easier to maintain and upgrade. If you had a problem with one page you can disable it EASILY without affecting the entire site which is what usually happens with a monolithic index.php.
This site http://www.aatraders.com/ doesn't use a CMS backend. The index.php controls 4 different pages and quite frankly is a pain in the butt to update and maintain. Fortunately all of the other pages are individual php files that are about 2-3k in size. Every page uses the Template Lite templating engine which makes the program code for each page tight and concise. If I were to make one large index.php it would be over 200k and a complete and total NIGHTMARE to maintain.
I would always stay away from monolithic index.php files as they will cause more harm than good. Plus they take up alot of server resources for no good reason loading and compiling all that unused code. You should only load what is needed for that page and nothing else.
BTW, as a side note...
Search engines tend to spider seperate pages with different names while ignoring pages that have the same name referenced through many get/post variables.
If you had a web site with 100 pages but they all started as index.php
and another web site with 100 pages and they all were different IE: index.php, showthis.php, newstuff.php, ... , mythings.php
you will find that search spiders will follow and save the data from the 100 pages with different names more often than the 100 pages that had the same index.php page. The spiders tend to stop following and saving data if every page has the same page name after a few pages. Having different get/post variables is usually ignored since they focus mainly on the base url. This is why you see mods for phpBB2 that turn forum topic URLs into plaintext.html links. It causes the spiders to actually follow and save the forum content.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
- AKA Panama Jack
- Forum Regular
- Posts: 878
- Joined: Mon Nov 14, 2005 4:21 pm
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
Re: Single index.php or Multiple Script
I have Front Controllers [no search engine friendly URLs] with 100+ pages that are fully indexed by Google and Yahoo. Even the thousand plus individual entries are indexed. Not all search engine are created equal though. Ask.com (Teoma) screens dynamic URLs.AKA Panama Jack wrote:Search engines tend to spider seperate pages with different names while ignoring pages that have the same name referenced through many get/post variables.
If you had a web site with 100 pages but they all started as index.php
and another web site with 100 pages and they all were different IE: index.php, showthis.php, newstuff.php, ... , mythings.php
you will find that search spiders will follow and save the data from the 100 pages with different names more often than the 100 pages that had the same index.php page. The spiders tend to stop following and saving data if every page has the same page name after a few pages. Having different get/post variables is usually ignored since they focus mainly on the base url. This is why you see mods for phpBB2 that turn forum topic URLs into plaintext.html links. It causes the spiders to actually follow and save the forum content.
Ask.com seems to love my static content (.HTML) but so do most search engines. I don't have a single php listing in Ask.com. So is that a Front Controller/Page Controller problem (as I have both) or is that a search engine characteristic?Q. Does the Ask crawler include dynamic URLs?
A. We include a select number of dynamic URLs in our index. However, they are screened to detect likely duplicates before downloading.
http://about.ask.com/en/docs/about/webmasters.shtml#15
I prefer Page Controllers but I wouldn't rule out using a Front Controller when appropriate to the problem. I'm just open minded like that.When you develop an web application which technique do you prefer or use?
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Single index.php or Multiple Script
AKA Panama Jack wrote:Interesting how most people posting went off on tangents without really answering your question.Hockey wrote: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?
First question they should have asked is...
"Are you using a CMS backend that controls all of the menus, selections and content?"
If you are using a CMS backend then you will probably be using a single index.php program to build each page based upon the get/post values. This usually results in a much SMALLER index.php for controlling everything instead of a massive index.php or many smaller php files for each page.
If you are NOT using a CMS backend then using a monolithic index.php is going to be detrimental in the long run. It really is considerably harder to debug, expand and track down issues that may arise. You would be better off sectioning out every page into seperate page files. This will make it considerably easier to maintain and upgrade. If you had a problem with one page you can disable it EASILY without affecting the entire site which is what usually happens with a monolithic index.php.
This site http://www.aatraders.com/ doesn't use a CMS backend. The index.php controls 4 different pages and quite frankly is a pain in the butt to update and maintain. Fortunately all of the other pages are individual php files that are about 2-3k in size. Every page uses the Template Lite templating engine which makes the program code for each page tight and concise. If I were to make one large index.php it would be over 200k and a complete and total NIGHTMARE to maintain.
I would always stay away from monolithic index.php files as they will cause more harm than good. Plus they take up alot of server resources for no good reason loading and compiling all that unused code. You should only load what is needed for that page and nothing else.
BTW, as a side note...
Search engines tend to spider seperate pages with different names while ignoring pages that have the same name referenced through many get/post variables.
If you had a web site with 100 pages but they all started as index.php
and another web site with 100 pages and they all were different IE: index.php, showthis.php, newstuff.php, ... , mythings.php
you will find that search spiders will follow and save the data from the 100 pages with different names more often than the 100 pages that had the same index.php page. The spiders tend to stop following and saving data if every page has the same page name after a few pages. Having different get/post variables is usually ignored since they focus mainly on the base url. This is why you see mods for phpBB2 that turn forum topic URLs into plaintext.html links. It causes the spiders to actually follow and save the forum content.
That always happens...I ask a question and expect a pragmatic answer, but get some theory insteadInteresting how most people posting went off on tangents without really answering your question
It's long been known to me I am horrible at asking questions I want answers too...
But yes, thank you for seeing it my way
I have a designed a CMS, which uses as single application entry point index.php for the backend, but generates physical web pages, which are powered by a template engine.If you are using a CMS backend then you will probably be using a single index.php program to build each page based upon the get/post values. This usually results in a much SMALLER index.php for controlling everything instead of a massive index.php or many smaller php files for each page.
So in a sense, my CMS also doubles as a RAD tool if you were interested in building a web site or application using seperate scripts as opposed to single entry index.php type programs...
I agree, however, for my CMS application a single index.php is not that difficult to maintain...I personally find that, it's easier to work with than 10 or so seperate scripts, although I have used separate scripts in the past due to parsing and execution times being an issue with a massive index.phpI would always stay away from monolithic index.php files as they will cause more harm than good. Plus they take up alot of server resources for no good reason loading and compiling all that unused code. You should only load what is needed for that page and nothing else
I really like the idea of being able to authenicate a user in one single place as opposed to having to call it in every script which needs it...
Especially in during initial development, because I always change my API like crazy...
Perhaps now I could consider using separate scripts, but initially IMHO it was a good idea to use a monolithic index.php
I think it has more to do with the fact it's a dynamic URL than it does a web page having the same name.Search engines tend to spider seperate pages with different names while ignoring pages that have the same name referenced through many get/post variables.
I believe Google stills suggests static URL's although they do spider some dynamic pages, it does stop after a while.
Cheers and thanks for the input
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
I don't see that being true at all. There is always very little or even no code (at least in my applications) that will be loaded that won't be used. Could you please elaborate on this?AKA Panama Jack wrote:I would always stay away from monolithic index.php files as they will cause more harm than good. Plus they take up alot of server resources for no good reason loading and compiling all that unused code. You should only load what is needed for that page and nothing else
Aside from this, don't you find it kind of ugly to include the same sections of code in multiple different files? Isn't that, to an extent, a bad design?