On 10 May 2010 18:17, Ashley Sheridan <ash@xxxxxxxxxxxxxxxxxxxx> wrote: > > >> >> 3} Unless the site is small and has few pages and applications, it is almost >> impossible to maintain. >> > > I disagree here. As long as there are useful naming conventions for all > of the files (I've seen projects where files have been named 1.php, > 2.php, etc. I wanted to bloody kill the developer who thought that was a > good idea!) It can be easier to maintain, especially when working in > teams, where one person can work on one area of the site and another > person can work on another. > > It makes sense sometimes to have different files for different sections > of a website. For example, blog.php, gallery.php, cart.php could deal > with the blog, gallery and shopping cart sections for an artists > website. Yes, it could all be achieved with one script handling > everything, but sometimes when the areas of the site differ greatly, it > results in a lot of extra code to deal with pulling in the right > template and content parts. I've always favoured only including the code > a page needs rather than a huge amount of stuff that it doesn't. I doubt anyone is proposing the "one script with all classes and functions" approach. Several files is obviously a preferable method. How you structure the code is completely different though: do you allow a user to run blog.php directly or do you funnel everything through one file and then handle request dispatching through that. Regards Peter -- <hype> WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 </hype> -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
