views:

99

answers:

1

Hey guys, just a small question here.. (hopefully!)

I've been trying a bunch of different directory structures for my PHP MVC framework. While doing this, I thought of a few reasons to separate different parts of the application from each other.

For instance, let's say this is my current structure:

- index.php
- private/
    - application/
        - ... (MVC stuff. Irrelevant I think...)
    - config/
        - config.php
    - framework/
        - bootstrap.php
        - includes/
        - library/
            - ... (Framework classes)
    - libraries/
        - Zend/
        - PEAR/
 - public/
     - css/
     - images/

The way I have it, I can update the framework simply by overwriting the /private/framework/ directory, which won't affect the user's framework configuration in /private/config/, or the 3rd party libraries in /private/libraries/.

The /index.php file is used almost purely to load the /private/framework/bootstrap.php file, which will mean updating the /private/framework/ directory will also update the main bootstrapping file (Saving me from having to update the /index.php file, which will stay as is, as there's not much at all in it).

Also, the application is separate from everything to do with the framework too, so the user can switch/change/update their applications when needed without having to worry about other directories.

Am I on the right track here with regards to separating the directories from one another to make them easier to update?

I've seen in some frameworks that they have both their /private/libraries/ and /private/application/ directories inside their framework directory... but this seems to me like it would be hard to update to a newer version of the framework if needed. Or am I thinking about it the wrong way?

You can see my previous dir structure here if you're interested. My new one is a little different (hopefully better...), as is my question, so I thought it warranted the posting of a new question.

It's not as small of a question as I would have hoped, but ah well! ;)

Thanks in advance =)

+2  A: 

I would suggest separating framework code from application code. The framework should be under one top-level directory and the application under a different one.

Actually... I suggest you look at the directory structure used by CakePHP.

Kalium
Actually, Cake is one of the frameworks I've been studying lately. Do you mean that my dir structure above doesn't show the same amount of separation that Cake does? Apart from my main directories being inside the 'private/' dir, the two structures actually look quite similar to me. Also, their structure has a 'Cake/config/' directory, which would mean if you ever updated the 'Cake/' directory, 'Cake/config/' would be overwritten.. right? But I guess that wouldn't affect Cake much, since in that file only one variable seems to be set, and by the framework itself, not the user.
manbeardpig
Yes, that's what I mean. Cake has two sets of configuration files, though. There's app/config and cake/config. The former is application configuration - database, cache, salts, stuff like that. The latter contains a version identifier, configuration for the directory structure, and some unicode handling stuff. There is a world of difference between application configuration and framework configuration.I think 'framework' and 'application' should be top-level directories with 'public' somewhere under 'application'. This enforces better separation between framework code and app code.
Kalium
I had a feeling that was the case, since the one variable defined in the cake/config was for the Cake version. Alright, so if I did what you just proposed, and 'public/' is put under 'application/', would I use my framework to present all css/js/img files, or htaccess to route css/js/img calls to the /application/public/ directory?
manbeardpig
Assets, such as CSS, JS, and images belong to the application. Thus, they should be under the application directory. Perhaps some sort of "assets" directory under "public", or maybe just the generic "css", "js", and "images" under "public". I would say that the framework should be aware of the default asset locations in the directory structure but your application is ultimately responsible for any deviations from the established convention. That way you could put '$js->link('jquery.js')' in a view and it would know where to look.
Kalium
So when my Application views call $js->link('jquery.js'), the resulting link would be something like <script src="site.com/application/assets/js/jquery.js"></script>... right? which doesn't seem to be a link I'd want to share with the world. Having them in 'public' or the main public dir of the server would make a cleaner URL... like 'site.com/public/js/jquery.js' or 'site.com/js/jquery.js'. This seems to make more sense to me but I may be wrong..
manbeardpig
Your server's docroot doesn't have to be the root directory of your whole framework and application install. In fact, I suggesting using "public" under "application" as the docroot. The result would be that URLs produced for public consumption would be relative to the docroot and the information leakage you fear would not occur.
Kalium
Yep, I understand that.. but what if changing the docroot is out of my users' control? For instance, on some cheap web hosts, they allow access only to the public_html directory. I was hoping to create the structure so it would work well on multiple setups, so I thought having the public dir in a separate location would mean the user could specify it's location to the Framework, and the Framework would create the correct links accordingly. This isn't as good when updating the application, but it would mean it should work more safely on cheap hosts. Is this a 'one-or-the-other' situation?
manbeardpig
That's possible, yes. I'd also suggest lots of mod_rewrite work. It's possible to design in such a flexible way. One option is to minimize the amount of work to boot the framework itself from the front contoller - the ideal is 'include PATH/TO/boot.php'.
Kalium
The problem with mod_rewrite is that I would need to know the possible 'assets' that the app might use... ie to route from calls to 'site.com/css' etc. But I'd want to let my app decide which possible scenarios might happen, perhaps in the config file. With that second part, do you mean my /index.php should contain only the script "include 'framework/bootstrap.php';"? Currently it defines the location of the framework dir, then the framework bootstrap file, and then it checks for the existence of that file, loads it if possible, or throws and error if it doesn't. I think that's pretty simple
manbeardpig