I was reading through Kevin Yanks latest book PHP & MYSQL NOVICE TO NINJA and it got me to thinking.
In his example it seems each page has its own folder. Surely thats just more work.
The effect is a url that looks something like this
[noparse]www.mysite.com/about/[/noparse]
instead of the traditional
[noparse]www.mysite.com/about.php[/noparse]
I found the problem of saving all main files in the root directory makes it extremely difficult to upgrade to a new version or to be able to work on an separate online test version.
And if at some point you’d just want to go with Python at server side… and somebody was bookmarking this page? Broken links are not making for happy users.
No.
Your desktop storage scheme is also folders and subfolders, having, hopefully, meaningful names, containing your files. Why this should be any different?
URL is folder path.
It’s not the Unix “/” standard folder separator, it’s [noparse]www.*.com[/noparse] that’s throwing you off, probably.
[QUOTE=itmitică;5149712]
Why would you do that? Test versions belong an a local development server.
Besides, the good that comes from not storing the files in the root, is security related.
[/QUOTE]
>>> Test versions belong an a local development server.
The local test versions are validated then uploaded and personally tested again.
After online validation is complete the test version is made live and log error/warning messages monitored.
>>> Besides, the good that comes from not storing the files in the root, is security related.
I am led to believe that source files should be stored above the root for even better security.
Using tried and tested PHP Frameworks make it easy to store both system and application files above the root.
By adopting the above practice changing to another version means the site is offline only momentarily while the new base file route index.php file is updated.
Creating folders to put your code in is a pretty quick and easy thing, so if you’re just trying to get rid of the .php extensions folders is the simplest way.
What you’re really looking for is a routing mechanism so that you can work with pretty url’s and pass the different parts of the url through as strings.
John, I’ve never seen that done before. If it’s working for you keep using it, but I think most people just keep versioning under control in source control and not in directories. Versioned apps / sites are painful to work with anyway, I’d always opt for One Version To Rule Them All.
[QUOTE=itmitică;5149711]Actually, that’s pretty much the way you store your files: you create meaningful folders and you store the files there.
URL is folder path.
It’s not Kevin’s structure, it’s normal folder and subfolder way of keeping files since… a long long time.[/QUOTE]
No, URL’s do not mean folder paths.
That’s quite often the case, but they aren’t directly related, it’s often not the best way to store them either.
URL’s should be designed for the users, make them as short, simple and explanatory as possible.
Folder structures are purely for the developers organisation, you can use whatever works for you, if you want to try putting all the files in the root directory give it a shot and see how it works. Depending on the size of the site that may work, but if you get more than 13 files you’ll want to split them out.
http:// - the name of the protocol www.sitepoint.com - a name for an IP address, a domain name that identifies a specific computer on the Internet
forums - a pathname, a hierarchical description that specifies the location of a file in that computer
<hr>
If you mean that intercepting user requests and redirecting them it means pointing to a different resource, that’s another thing altogether. URL, at its core, it is folder path, UNIX folder path to be precise.
http:// - the name of the protocol www.sitepoint.com - a name for an IP address, a domain name that identifies a specific computer on the Internet
forums - a pathname, a hierarchical description that specifies the location of a file in that computer
If you mean that intercepting user requests and redirecting them it means pointing to a different resource, that’s another thing altogether. URL, at its core, it is folder path, UNIX folder path to be precise.[/QUOTE]
You are wrong here, requests are made to a server and it’s up to the server how to respond to it.
The URL does not mean a file path on the server.
Somewhere along the line we realized that URL’s should be awesome and our code well organised too.
Ever since then URL routing has become the norm for web applications and frameworks.
“URL is folder path” hasn’t been true of any web application I’ve worked on in the last 4 years
–
Back to the topic at hand, personally speaking MVC is the best way to structure web applications.
If it’s just a handful of PHP pages you don’t need to go to that level of complexity, but if you’re working on larger applications with a lot of moving parts the structure of MVC will help keep it under control and easy to find things.
I think at this stage putting all your pages together should be fine
Routing is a process handled by a bootstrap file.
It works by catching and handling the error response for a request, when the folders and files specified in the URL’s folder path are not found.
It’s an exploit, but it boils down to the same normal UNIX folder path for a given URL.
High level web frameworks, have handy scripts to automate the creation of folder structures for the developer: CakePHP, Ruby on Rails, Django.
It’s
Convention over configuration. Use sensible defaults to avoid having to configure everything.
The developer can fiddle with the settings files and change things around, but that’s not what the high-level stands for.
Low level web frameworks however, are flexible, less intrusive and less demanding about that.
The developer gets to make its own decisions about the folder structure of its project, amongst other things.
I guess you’re more involved with high level web frameworks.
But normally, high level or low level, none of it means “putting all your pages together”.
<hr>
There is a distinction to be pointed out: a web server and an application server for a server side language.
A web server, by default, will follow the URL’s folder path and “execute” certain type of files it may find there.
An application server for a server side language is the one that may or may not receive the control after the web server decides what type of file is the one in the URL’s folder path.
Pretty much like how a user “double clicks” on a .doc file and Windows calls up on WinWord to “execute” the .doc file.
Only that the remote user doesn’t “double click” but “requests” the index.php, and the Apache web server calls up on the PHP application server to “execute” the .php file.
As you may have noticed from the other posts I use a PHP Framework which accesses the ROOT index.php file. All URL’s are routed from the “application path” which I have called ver-001, ver-002 and ver-003. In practise instead of having links in the index.php file the application version path is hard-coded.
A demo is online and also a link to the zipped source files.
Mine have all been moved back to url folder = dir folder, for me it’s easier to keep things logical backend. It makes it easier for people when they update their website with FTP, as you can’t upload from iPhone and they’ve started using their phones to update their sites. By keeping the structure the same both server and client it’s easy for people with little knowledge to add media to the directories they want. I have a small default file in each directory that includes the files needed. It also makes it easier to switch between php and asp as when I last looked classic asp has nothing smilar to mod rewite, as the global.asa file only gets triggered after a file is called and .htaccess gets triggered before. I do use url rewrites for sub-sub folders though, but that is to uncomplicate the visible URL and usually it’s a category with subcategories. Most of the time they are running from the same scripts.
For me it depends how many other files I want to include within the folder. If most sub folders of a particular folder are likely to have their own media files I will give them their own folder. But if most of it’s text, or a variation of its parent then I’ll use a rewrite.
But my main reason of doing it the way I do is so I am not constrained to keep with asp or php. Once I’ve worked on .NET a bit more I may change again, as I think that has similar to .htaccess, but I doubt if I’ll deviate much, as I like to keep things categorised backend for easy navigation.
