Nice

We could add ?:

I would put layout/ under application/

Hi Wil, I have a few feedbacks:

1. I would move /config from /application folder to root.
It seems more appropriate because there are some project wide configuration that not necessary could find a logic place under /application.

2. What about using /task instead of /jobs?

3. What is the meaning/purpose of /extras and /application/apis?

I like the idea, however some things are missing:

• vendor folder, used for abstractions of the Zf; Eg ProjectName_Controller_Action (i suggest to put it in /vendor)
• folder for build scripts (i suggest /<project-root>/build-tools)
• i'd personally rename the "config" folder to "etc"
• the <module name> section should also have an extra folder "locale" for locales per module

Hi Wil,

My own comments!

1. The proposal suggests a default directory structure, but doesn't offer any justification for the decision on a case by case basis. From a feedback point of view - how can commentors debate the unjustified?

2. What are extras, apis?

3. config should be present in root if we're allowing for other top level directories besides public.

4. bootstrap.php I suggest would be better as Bootstrap.php reflecting the PEAR convention to a degree since it likely contains a class.

5. The proposal doesn't note the default content for bootstrap.php, index.php, and .htaccess. No doubt out of this proposal's context but I think the goal should be to generate an initial structure which responds almost immediately to requests (afterall who cares where it's put on a devel server). Over to Zend_Build then...

6. My favourite question: What can be removed as unnecessary? My thoughts are with apis, extras, data, jobs

7. I think either more should be moved to application, or move more to the root. Leave me less navigation clicks through PDT

8. Where is my tmp directory for sessions and other temporary data ops?

Best,
Paddy

Wil,

I 2 pretty imporant ones: tests, *tmp. I suggest to put this one in <project-root>/tests, <project-root>/tmp.

I also wrote a short description once on folder names (not all of them are covered yet), but its a start:

The controllers/ directory
The controllers/ directory contains all the controllers for the application.

The etc/ directory
Configuration and database schema files will go here.

The jobs/ directory
Cron jobs, database schema migration scripts or import scripts to be written. These are run using the PHP CLI executable and are stored here.

The models/ directory
Holds model classes, some of which are derived from database abstraction layer

The scripts/ directory
This contains a sub-folder for each controller (named after the controller) and also some layout template files. Within each sub-directory there is a template file named after the action and possibly some additional helper templates which I prefix with 2 underscores.

The application.php/bootstrap.php file
This file will contain all the different stages of the application, such as loading configuration data, setting up a database connection, etc.

The library/ Directory
Any third party library is stored in here. Most of the time, this directory is maintained by svn:externals.

The public_html/ Directory
This one is pretty obvious I think ...

The tests/ directory
Unit tests (mostly for models) will go here.

The tmp/ directory
This is the base folder for all sort of files that can be deleted! Anything transient is stored here.

I'd rename "data/" to "var/".

"config/" should be in the project root, and also renamed to "etc/".

For the "document_root", I'm also voting for "public_html/", or "htdocs/".

Reason for renaming - all of them are (more) well known, and since most people will run on Linux/Unix and most likely have Apache it fits a scheme they are used to.

What I am personally missing in this proposal is support for different instances of an application.

Let's say the application is a content management system that serves several sites. Each site is administered by a different person. So there have to be at least several "public"-directories. But what if I want to separate the cache, the data directory etc. per site?

Imagine having to give the site admins ftp-access to their site-directories, where they can upload images, templates, data etc, but preventing them from breaking the application or accessing some other peoples' site.

Maybe this is too advanced a request for this proposal, but I am already working on two projects with multiple instances so this might be worthwile to consider. It makes things a heck more complicated though - i.e. if some sites have access to certain modules that others don't have or you support custom modules that clients develop themselves and plug into my application.

Haha, I was in the middle of building a Python app that would do the same thing.

I think this is an excellent idea and please stick with XML for building the project profile, primarily because my apps use a very different structure than the default one proposed and I would like it to be non-troublesome for me to edit the profile accordingly.

Just reiterating - having a directory for jobs/tasks/build. Does it meet the 80/20 needs level only? I seriously doubt it. I really think the default should be minimal with most of the application level directories moved to root (or vice versa is application specific). If we're putting in everything plus the kitchen sink we're far more likely to thread on toes where people end up with a billion directories they either never ever use, or whose naming they inevitably disagree on. If it's not essential to a new application, or is not inevitable of a new application, it probably isn't needed...

• On layout directory:
  • I too think ./layouts/ should be under application. The reason is that Zend_Layout could not only support global site layouts (which i think is what you are referring to here), but also module specific layouts.
  • Think in terms of a situation where you have dropped in a blog MODULE that has a blog layout (think buttons for creating new posts, editing, controls, etc) and it in turn needs to be part of a much larger global layout. Zend_Layout supports this notion, which is why it probably would fit better in ./application/.
• On public:
  • Do other names make more sense here? httpdocs seems pretty common across the board.
• On bootstrap.php
  • I am on the fence for the necessity for a bootstrap.php file. Do we have a standard interface for this? What does it look like.
  • In previous projects httpdocs/index.php has sufficed as the bootstrap file, with the reasoning that your main(..) executable code is essentially boostrapping code.
  • With the addition of a bootstrap.php file, our index.php file essentially looks like this
    require_once './path/to/bootstrap.php'; Bootstrap::run();

On the whole I think it's pretty good. Like everyone here I have a slightly diverged structure - I'm not precious about it and I'm open to changing it, but here's a few differences/notes:-

• Is there going to be a template specific to hosted environments that don't give write access to any other folder than httpdocs (yeah, Plesk, I'm talking about YOU!). Could thought be given to creationg a 'framework' or 'zf' folder with a ready-made .htaccess file (containing 'deny' directives)?
• My experience is that the application folder works quite well with:-
  /application/default - contains 'default' module (controllers, views, config, layout, models)
  /application/module1 - same as above but developer-designed module
  /application/module2... etc
  Any reason why the 'default' module folders aren't similarly organised?
• I'm all for a 'default' bootstrap that we can overwrite. To me it would look pretty similar in structure to an '.ini' file (in terms of having pre-defined examples for developers to uncomment and use as-is). This would be called from 'index.php' similarly to how Ralph describes it above.
• I'm happy with 'httpdocs', 'public_html', 'document_root' or 'www' for placing all public files
• Contrary to 'var' and 'etc' I'd prefer to stick with plain-english folder descriptions - simply because they require less explanation to non-Linux types.
• I also agree that 'apis' should be optional (first time I read it I was a little confused)
• I like 'tasks' better than 'jobs' (only because I'm a snob )

Will look forward to giving this a try-out!

Reading back I realise my minimalise comment was unnecessary since some of these directories are only created if required. Presumably than a default project, wouldn't have them. Any chance we can clarify the required from the optional in the directory snapshot?

Why not put all directorys under the application directory - since they are ALL application related! I do not see the benefit to put some directorys IN the application dir and others don't.

Either public/ directory outside the application directory or inside the application directory - in this example it is outside the application dir.
(For this example i copied Wils proposal directory structure and modified it - so do not care about the names)

Tiny comment to note that /views/layouts is not a current Zend_Layout default (defaults to having a layout.phtml in views/scripts). Might be worth leaving out a layout directory to avoid confusion. I've noticed the documentation for Zend_Layout appears to not mention this anywhere - something I'll report as a documentation improvement.

After read all the post, i can't figure out what is the prefered directory structure, for my point of view all dirs are application specific, and i use for long years a structure that i changed to make it as standard as posible. I think that familiar common names will help the people to identify easy the mean of a directory.

I think that some dirs can have mode deep structure, for example images under public can have a locale directory structure if images for diferent locales are required, some times certain modules need specific configuration this can go in their module directory, so it's decision of developer to create them.

Other directory that comes in place is build, that of cource will be a directory for development stage that will be left in final product.

I think that the best aproach is make the application always modular if the developer don't wnat modules or it's a simple application only one module will be created. 

Will be great that where any place to see the proposal structure updates based on the feedback so people can see the form that the structure are take. 

Though Thomas Fritz nearly breaks the subject, I didn't see anyone else ask the following directly:

How will this work with shared hosting, where the web server root is the only directory into which customers can upload files?

With the recent addition of forms they too will need a place in the structure. I posted a question about where on Nabble (http://www.nabble.com/Zend_Form%3A-Directory-for-subclass%27d-forms--tc15812272s16154.html) and Matthew Weier O'Phinney said:

"We haven't decided on a location for forms in the directory hierarchy yet. My prediction would be in application/forms/, and prefix them with 'Form_'; in modules, they'd then be prefixed with '<Module>Form'."

Proposal has been updated to take into account all of the above comments as well as Wil's responses and further clarificaitons.

-ralph