Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend Framework Default Project Structure Component Proposal

Proposed Component Name Zend Framework Default Project Structure
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend Framework Default Project Structure
Proposers Wil Sinclair
Liaison: Ralph Schindler
Revision 0.1 - January 21, 2008: First draft.
1.0 - January 30, 2008: Final draft for review. (wiki revision: 23)

Table of Contents

1. Overview

This proposal covers the Zend Framework default project structure. This will be the project structure generated be default when using Zend_Tool. It will also serve as our recommended project structure for basic projects that do not call for more specialized project organization and in environments where the developer has appropriate file system/web server admin privileges.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This project structure must support all project requirement for core components in an environment where the developer has appropriate file system and web server admin privileges.
  • This project structure will not support all project requirements or constrained environments where, for example, apache directives can not be overridden.
  • This project structure must reflect all PHP application security best practices, including minimizing code under the web server document root.
  • This project structure will require that URL rewrite is enabled on the web server to work properly and properly secure the application.
  • This project structure must be extensible/expandable to handle new requirements.
  • This project structure should minimize the complexity of the project directory for the given project. For example, if the project does not use Zend_Search_Lucene, an index folder should not be recommended.
  • This project structure should allow modules to be added to a non-modular application without having to manually update the project directory structure.
  • This project structure should be consistent in best-practices recommendations with the project structures that have been documented in the reference guide.

4. Dependencies on Other Framework Components

5. Theory of Operation

Many developers seek guidance on the best project structure for a Zend Framework project in a relatively flexible environment. A 'flexible' environment is one in which the developer can manipulate their file systems and web server configurations as needed to achieve the most ideal project structure to run and secure their application. The default project structure will assume that the developer has such flexibility at their disposal.
The following file/directory structure is designed to be maximally extensible for complex projects, while providing a simple subset of folder and files for project with simpler requirements. This structure also works without alteration for both modular and non-modular ZF applications. The .htaccess files require url-rewrite functionality in the web server as described in this document: Rewrite Configuration Guide.
It is not the intention that this project structure will support all possible ZF project requirements. The default project profile used by Zend_Tool will reflect this project structure, but applications with requirements not support by this structure should use a custom project profile.

6. Milestones / Tasks

  • Milestone 1: Gather community feedback and finalize project structure.
  • Milestone 4: Document the project structure in reference guide.

7. Class Index

8. Use Cases

These use cases will necessarily be very high level.

UC-01

The users creates a project without specifying a project profile.
The system finds the default project profile and creates the components of the project structure below necessary for a basic MVC ZF application.

UC-02

The users creates an index for Zend_Search_Lucene in his/her existing project.
The system creates the required index directory for the Lucene indexes and creates necessary files to facilitate index building.

9. Class Skeletons

The following reflects the file system structure of the proposed default project structure:

Please note that the directory layout described here can be duplicated under modules with the exception of the Bootstrap.php.
Justifications for the above.


application/ - This directory contains your application. It will house the MVC system, as well as conifgurations, services used, and your bootstrap file.

services/ - This directory is for your application specific web-service files that are provided by your application.

configs/ - The application-wide configuration directory

controllers/models/views/ - These directories serve as the default controller/model/view directories. Having these three directories inside the application directory provides the best layout for starting a simple project as well as starting a modular project that has global controllers/models/views.

controllers/helpers/ - These directories will contain action helpers. Action helpers will be namespaced either as "Controller_Helper_" for the default module or "<Module>Controller_Helper" in other modules.

data/ - This directory provides a place to store application data that is volatile and possibly temporary. The disturbance of data in this directory might cause the application to fail. Also, the information in this directory may or may not be committed to a subversion repository. Examples of things in this directory are session files, cache files, sqlite databases, logs and indexes.

layouts/ - This layout directory is for MCV-based layouts. Since Zend_Layout is capable of MVC- and non-MVC-based layouts, the location of this directory reflects that layouts are not on a 1-to-1 relationship with controllers and are independent of templates within views/.

Bootstrap.php - This file is the entry point for your application. The purpose for this file is to bootstrap the application and make components available to the application by initializing them. This file should not call dispatch() on the front controller.

modules/ - Modules allow a developer to group a set of related controllers into a logically organized group. The structure under the modules directory would resemble the structure under the application directory minus the Bootstrap.php file.

docs/ - This directory contains documentation, either generated or directly authored.

library/ - This directory houses the library/Zend/* folder which contains Zend Framework. Developers should also place their application's library code under this directory in a separate namespace- ie, a namespace that does not begin with 'Zend'.

scripts/ - This directory contains maintenance and/or build scripts. Such scripts might include command line, cron, or phing build scripts that are not executed at runtime but are part of the correct functioning of the application.

temp/ - The temp folder is set aside for transient application data. This information would not typically be committed to the applications svn repository. If data under the temp/ directory were deleted, the application should be able to continue running with a possible decrease in performance until data is once again restored/recached.

tests/ - This directory contains application tests. These could be hand written, phpunit tests, selenium based tests or based on some other testing framework. By default, library code can be tested by mimicing the directory structure of your library/ directory. Additionally, functional tests for your application could be written mimicing the application/ directory structure (including the application subdirectory).

public/ - This directory contains all public files for your application. index.php sets up the PHP environment, include the Bootstrap.php file from your application/ directory and finally dispatch() the front controller. The web root of your web server would typically be set to this directory.

]]></ac:plain-text-body></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jan 30, 2008

    <p>Nice <ac:emoticon ac:name="smile" /></p>

    <p>We could add ?:</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    modules/
    config/

    data/
    sessions/
    ]]></ac:plain-text-body></ac:macro>

    <p>I would put <strong>layout/</strong> under <strong>application/</strong></p>

    1. Jan 30, 2008

      <p>I agree with you on these.</p>

      <p>It's important to note that while these directory locations are specified in the project layout, unused items dont need to exist. For exmaple, if you application doesnt use web-services, the api's directory is not needed. Same with modules, and modules/config.</p>

  2. Jan 30, 2008

    <p>Hi Wil, I have a few feedbacks:</p>

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

    <p>2. What about using /task instead of /jobs? </p>

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

    1. Jan 30, 2008

      <p>I am not sure I agree on the config being at the project level, considering everything inside the /config directory applies to things within the application directory.</p>

      <p>Can you supply a use case that supports an instance of something that exists outside the application directory that needs configuring?</p>

      1. Jan 30, 2008

        <p>For instance, Rails and Symfony usually stores in /root/config database schema, /vendor settings (propel settings for Symfony) and CLI overall configuration.</p>

        <p>/root/config might include as well project constants or environment files.</p>

  3. Jan 30, 2008

    <p>I like the idea, however some things are missing:</p>

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

    1. Jan 30, 2008

      <blockquote><p>vendor folder, used for abstractions of the Zf; Eg ProjectName_Controller_Action (i suggest to put it in /vendor)</p></blockquote>

      <p>I agree with you.<br />
      In my previous comment I requested the purpose of /extras folder just because I guess /extras does what /vendor should do.<br />
      I agree with /vendor.</p>

      <blockquote><p>folder for build scripts (i suggest /<project-root>/build-tools)</p></blockquote>

      <p>Same as before.<br />
      I suppose Wil called this folder /jobs.</p>

      <p>I would suggest to extend this proposal with a short description of each folder purpose.<br />
      Many of us already has experience with other MVC frameworks and folder name without a small explanation might cause a kind of misunderstanding. <ac:emoticon ac:name="smile" /></p>

      1. Jan 30, 2008

        <p>Indeed, 'extras' is our version of 'vendor'. I would need to check with some business folks about the naming since Zend has true 'vendors' and we wouldn't want to cause confusion with ZF partners.</p>

    2. Jan 30, 2008

      <p>In that case, how does the idea of a "vendor" plug into the FrontController system, specifically with respect to the current module paradigm?</p>

      <p>Also, wouldn't locale data be site wide? Does a good place for locales not seem like it would be data/locales?</p>

  4. Jan 30, 2008

    <p>Hi Wil,</p>

    <p>My own comments! <ac:emoticon ac:name="smile" /></p>

    <p>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?</p>

    <p>2. What are extras, apis?</p>

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

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

    <p>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...</p>

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

    <p>7. I think either more should be moved to application, or move more to the root. Leave me less navigation clicks through PDT <ac:emoticon ac:name="smile" /></p>

    <p>8. Where is my tmp directory for sessions and other temporary data ops?</p>

    <p>Best,<br />
    Paddy</p>

    1. Jan 30, 2008

      <blockquote>
      <p>2. What are extras, apis?</p></blockquote>

      <p>I agree, this needs to be explained.</p>

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

      <p>+1</p>

      <blockquote>
      <p>8. Where is my tmp directory for sessions and other temporary data ops?</p></blockquote>

      <p>In my first comment I proposed to rename "data/" to "var/", and "tmp/" could either go in the project's root, or (to follow the naming conventions on my Linux/Unix systems) "var/tmp/".</p>

      1. Mar 20, 2009

        <p>BTW, we also considered *nix names in creating this proposal. But Windows and other users will be using this project structure, and these names might obscure the purpose of the folder for them.</p>

  5. Jan 30, 2008

    <p>Wil,</p>

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

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

    <p><strong>The controllers/ directory</strong><br />
    The controllers/ directory contains all the controllers for the application.</p>

    <p><strong>The etc/ directory</strong><br />
    Configuration and database schema files will go here.</p>

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

    <p><strong>The models/ directory</strong><br />
    Holds model classes, some of which are derived from database abstraction layer</p>

    <p><strong>The scripts/ directory</strong><br />
    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.</p>

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

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

    <p><strong>The public_html/ Directory</strong><br />
    This one is pretty obvious I think ...</p>

    <p><strong>The tests/ directory</strong><br />
    Unit tests (mostly for models) will go here.</p>

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

  6. Jan 30, 2008

    <p>I'd rename "data/" to "var/".</p>

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

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

    <p>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.</p>

  7. Jan 30, 2008

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

    <p>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?</p>

    <p>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.</p>

    <p>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.</p>

    1. Feb 25, 2008

      <p>This seems like a good candidate for a custom project profile. It is a use case I hadn't considered up to this point, so I'll have to think about this WRT Zend_Build, but it certainly is not common enough to complicate the default project structure, which must be as simple as possible for most projects.</p>

  8. Jan 30, 2008

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

    <p>I think this is an excellent idea and <strong>please</strong> 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.</p>

    1. Jan 30, 2008

      <p>I don't want to double post, but, here is my directory structure for those that might find it useful. This is just an example of what mine looks like - I use XSLT transforms instead of .phtml views to handle rendering of the page; but adaptation shouldn't be an issue if you find anything in this that seems suitable.</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      /app_project_name
      /abstract
      /controller
      /model
      /xml
      /xslt
      /config
              config.php
      /modules
      /home
      /controllers
      /models
      /xml
      /data
      /xslt
      /uploads
      /logs
      /utilities/webroot
      /cache
      /feeds
      /media
      /imgs
      /icons
      /css
      /screen
      /print
      /mobile
      /js
      /libs
      /addons
      /data
      .htacces
      index.php
      ]]></ac:plain-text-body></ac:macro>

    2. Jan 30, 2008

      <p>Support for Yaml wouldn't hurt either. Since it's pretty "hip". <ac:emoticon ac:name="wink" /></p>

      1. Jan 30, 2008

        <p>Reviews, and lack of Review updates to Proposals aside, from the "review" I received from someone at Zend in autumn YAML support is not being currently considered. The reasoning was basically use ext/syck from PECL and wait for it to support YAML 1.1. I was a bit busy at the time so I don't recall all the details, suggested a lighter wrapper for the syck-less, and went back to my overtime and stress running into December <ac:emoticon ac:name="wink" />.</p>

        <p>So effectively not going to happen.</p>

        1. Feb 25, 2008

          <p>Well, I wouldn't say that we have it in for YAML. <ac:emoticon ac:name="wink" /> But we are considering not doing it as Zend_Config data at all because of the limitations that come along with it. Ultimately XML is a very good match as a data format for project profiles: the data is highly structured and hierarchical, it can be read in most runtime environments if anyone wants to create their own tools in other languages (I know this is becoming the case with YAML, but I think XML still has an edge here), and it's not going to be transferred over the wire so size isn't much of a concern. <ac:emoticon ac:name="wink" /><br />
          Ultimately, the YAML issue is orthogonal to this debate, and we probably have enough to consider already without opening up the whole YAML issue. Let's assume that project profiles will definitely support XML, and possibly support all formats supported by Zend_Config.</p>

  9. Jan 30, 2008

    <p>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...</p>

    1. Jan 30, 2008

      <p>If you look at this directory structure as placeholders, wouldn't be as minimal or maximum as your application needs?</p>

      <p>For example, if an application does not consume or supply any web-services, it seems like to me that the api's directory simply wouldn't be there until its needed. Like wise with data/sessions modules/ etc.</p>

      <p>Its not an all or nothing per-se, but when a feature is used, the cli tool would create the necessary directory/directories based on need.</p>

  10. Jan 30, 2008

    <ul>
    <li>On layout directory:
    <ul>
    <li>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.</li>
    <li>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/.</li>
    </ul>
    </li>
    <li>On public:
    <ul>
    <li>Do other names make more sense here? httpdocs seems pretty common across the board.</li>
    </ul>
    </li>
    <li>On bootstrap.php
    <ul>
    <li>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.</li>
    <li>In previous projects httpdocs/index.php has sufficed as the bootstrap file, with the reasoning that your main(..) executable code is essentially boostrapping code.</li>
    <li>With the addition of a bootstrap.php file, our index.php file essentially looks like this
    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[ require_once './path/to/bootstrap.php'; Bootstrap::run(); ]]></ac:plain-text-body></ac:macro></li>
    </ul>
    </li>
    </ul>

    1. Jan 31, 2008

      <p>I agree on the need for app level layouts.</p>

      <p>I think public is just fine. I've never seen a httpdocs directory before, and moving to htdocs as some have suggested is Apache oriented. Not everyone uses Apache remember? <ac:emoticon ac:name="wink" /></p>

      <p>We need a bootstrap file. Bootstrapping has gone beyond a procedural spaghetti exercise and needs to have a little structure in a class. It needs to be on an application level since it contains all the setup code, and not public, since public is likely in a completely different location at the end of the day to the app code (with obvious outs). Finally it's a simple index.php include of Bootstrap.php - in a simpler deployment scenario, index.php becomes the marginal symlink to different app versions with different Bootstrapping code.</p>

      <p>There's also the need for grouping bootstraps with application code for testing - one possible example is using a Bootstrap class to split discrete bootstrapping steps into callable methods, where several can be reused by external tools. Obvious one springing to mind is bootstrapping a Front Controller via a callback method taken from Bootstrap - a bit simpler than going completely into homebrewed testing solutions with a lot of typing overhead. I'm sure someone more imaginative than I can find other uses...</p>

  11. Jan 30, 2008

    <p>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:-</p>

    <ul>
    <li>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)?</li>
    <li>My experience is that the application folder works quite well with:-<br />
    /application/default - contains 'default' module (controllers, views, config, layout, models)<br />
    /application/module1 - same as above but developer-designed module<br />
    /application/module2... etc<br />
    Any reason why the 'default' module folders aren't similarly organised?</li>
    <li>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.</li>
    <li>I'm happy with 'httpdocs', 'public_html', 'document_root' or 'www' for placing all public files</li>
    <li>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.</li>
    <li>I also agree that 'apis' should be optional (first time I read it I was a little confused)</li>
    <li>I like 'tasks' better than 'jobs' (only because I'm a snob <ac:emoticon ac:name="smile" /> )</li>
    </ul>

    <p>Will look forward to giving this a try-out!</p>

  12. Jan 31, 2008

    <p>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?</p>

  13. Feb 08, 2008

    <p>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.</p>

    <p>Either public/ directory outside the application directory or inside the application directory - in this example it is outside the application dir.<br />
    (For this example i copied Wils proposal directory structure and modified it - so do not care about the names)</p>
    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    application/
    config/
    modules/
    <module name>/
    controllers/
    models/
    views/
    bootstrap.php
    data/
    cache/
    logs/
    indexes/
    locales/
    docs/
    jobs/
    library/
    tests/
    public/
    images/
    js/
    css/
    .htaccess
    index.php
    ]]></ac:plain-text-body></ac:macro>

  14. Feb 09, 2008

    <p>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.</p>

  15. Feb 14, 2008

    <p>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.</p>
    <ac:macro ac:name="panel"><ac:rich-text-body>
    <p>etc/   (Global application configuration, datasources, log, front controller config, etc.)<br />
    lib/   (Libraries required for the application)<br />
    bin/   (Scripts to run from the CLI or via crond)<br />
    docs/ (Application documentation specific)<br />
    tests/ (Tests for the application code)<br />
    var/    (Data that changes frequently) <br />
        cache/    (store cached resources here)<br />
        tmp/    (temporal  store)<br />
        log/    (directory to store the logs generated by the application)<br />
    modules/ (Bundles or plugins of the application)<br />
       <module_name>/<br />
          controllers/<br />
          models/<br />
          views/<br />
          locale/<br />
    public/    (public content)<br />
        images/<br />
        js/<br />
        css/<br />
        .htaccess<br />
        index.php</p></ac:rich-text-body></ac:macro>
    <p>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.</p>

    <p>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.</p>

    <p>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. </p>

    <p>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. </p>

  16. Feb 27, 2008

    <p>Though <ac:link><ri:user ri:username="thomasfr" /></ac:link> nearly breaks the subject, I didn't see anyone else ask the following directly:</p>

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

    1. Feb 27, 2008

      <p>There's always room for community contributions with different setups. These could/should be easy plugable. </p>

      <p>Imagine:<br />
      php init-project.php <a class="external-link" href="http://framework.zend.com/setup/modular-setup-for-shared-hosting.xml">http://framework.zend.com/setup/modular-setup-for-shared-hosting.xml</a></p>

      <p>Where for instance Zend could host a few standard setups, or make them downloadable.</p>

  17. Mar 04, 2008

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

    <p>"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><em>Form</em>'."</p>

    1. Mar 04, 2008

      <p>What about inside models?</p>

      <p>Models, generally speaking, are environment agnostic classes containing the business logic of your application.</p>

      <p>While forms do speak towards the view and some controller and some model aspects. I can see the argument for keeping forms at the top level. We should revisit this after some best practices emerge with respect to forms and applications.</p>

      <p>Also, I would see it as "<Module><em>Form</em>" to keep it consistent with what people do with Models and Controller prefixing.</p>

      <p>-ralph</p>

  18. Mar 04, 2008

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

    <p>-ralph</p>

  19. Mar 05, 2008

    <p>I like the structure and i am looking forwards when the whole Zend_Build thing is ready!! Great work so far!!</p>

  20. Jun 07, 2008

    <p>I'm always a bit confused with 'scripts' directories. I've come to terms with them in application/views, although they could contain template files that do not contain any scripting. The confusion comes in again with<br />

    Unknown macro: {root}

    /scripts. How do these relate?<br />
    Maybe 'maint' or 'maintenance' is a better, more descriptive name?</p>

  21. Mar 30, 2008

    <p>With the default module not in the modules directory, addModuleDirectory() isn't going to work as a one-liner. Is it expected that each module will have to be added manually in the Bootstrap class?</p>

    <p>Rob...</p>

    1. Mar 30, 2008

      <p>To answer my own question, the code looks something like this:</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      $frontController->setControllerDirectory(ROOT_DIR . '/application/controllers');
      $frontController->addModuleDirectory(ROOT_DIR . '/application/modules');
      ]]></ac:plain-text-body></ac:macro>

      <p>Rob...</p>

  22. May 10, 2008

    <p>I have always a problem with seperating models into the single modules, because most of the time you have, for instance, a frontend and an admin module, and both modules share the same models. Also there may be a forums module, which may share the users model with the other modules.</p>

    <p>So in general there should <strong>always</strong> be a models directory directly within the application directory.</p>

  23. May 13, 2008

    <p>While I understand the concept of a 'bootstrap.php' file, I personally would rather see these tasks captured in an 'Initialization' plugin. This would provide a standard location to create routes, load additional plugins, and perform other startup-related tasks. Additionally, by being a plugin, you then have access to the class via Zend_Controller_Front::getPlugin() – allowing your application to have some introspection into the configuration environment.</p>

    1. May 13, 2008

      <p>As of today (May 08) we have not had a formalism of a few concepts that would encourage this to be part of this proposal, namely:</p>

      <ul>
      <li>The "which environment are we in" question</li>
      <li>The "what are all the steps to initialization" question</li>
      <li>The "what is the use to having an OO application bootstrap" question</li>
      <li>The "isn't boostrapping procedural anyway" question<br />
      and </li>
      <li>The "if a bootstrap represents the glue of all my application peices, shouldnt it be the first file you see" question</li>
      </ul>

      <p>I am all for answering these questions, then moving to formalize a solution that represents best practices, but currently we are not there. I would propose that once these questions have been answered, then we can look at including an "initialization plugin" as part of the default project structure.</p>

      <p>-ralph</p>

  24. May 15, 2008

    <p>My view on the subject...</p>
    <ul>
    <li>Modules inside the application folder increases clutter, nesting and denies special use of permissions on OS level. I say drop the simple app aproach and do everything modularized. It is a better practice anyway.</li>
    </ul>

    <p>     application -> default -> ...  <br />
         application -> module1 -> ...<br />
         application -> module2 -> ...</p>
    <ul>
    <li>What's the data/indexes/ for?</li>
    <li>The data and temp folder look a little redundant, most of the stuff in data is always volatile and some even rarely saved besides the web server. Merge them?</li>
    <li>Large apps/sites don't use global locale/language files unless they are trying to kill the server. I for exemple use tmx files and i place them inside a content folder under each module. Thus my sugestion:</li>
    </ul>

    <p>        application -> module -> content  <br />
            (to place tmx, sqlite, other files with content usable by each module, default->content beeing usable by all)</p>
    <ul>
    <li>I vote on Bootstrap.php too.</li>
    <li>public/ should either be www/ or public_html/ to allow for instant integration with automatic usage of svn/rsync with running websites.</li>
    <li>Forms (beeing the beast of web development) really need a place for themselves and their viewscript decorators.</li>
    <li>Never having used the filters/ and helpers/ folders i have to ask... do we really needed those extra nesting inside a modular structure? <br class="atl-forced-newline" /></li>
    </ul>

  25. May 20, 2008

    <p>The only thing I don't like about the proposed structure is that there are two folders called 'scripts' that have slightly different uses. One is the Zend_View default for templates, the other for cron/build scripts. 'scripts' seems appropriate for cron jobs and such, but it would be easier to rename this folder than the view/scripts/ once since the latter needs to use the Zend_View default.</p>

    <p>Two other things to consider:</p>

    <p>Where would be the logical place for partial-style templates used by layouts? E.g. a site might have several different layouts that each included a standard 'footer.phtml'. Is it logical for this file to also live in the 'layouts' folder, or should this sit somewhere in views/scripts/ (or somewhere else)?</p>

    <p>Applications sometimes include non-PHP files that need to be accessible through the web root, e.g. a Javascript library. Should such files always go inside public/, or live in the libraries folder and be accessible either via. symlink or through ZF routing?</p>

  26. Jun 11, 2008

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Comments</ac:parameter><ac:rich-text-body>
    <p>The proposal is approved for incubator development.</p></ac:rich-text-body></ac:macro>

  27. Jun 22, 2008

    <p>/public needs to be modular enough to allow for the separation of "public files" per module. I regularly use sub domains and modules together to identify customer gateways.</p>

    <p>admin.customer.com<br />
    phpmyadmin.customer.com<br />
    www.customer.com<br />
    blog.customer.com</p>

    <p>In most cases each gateway has its own set of css, js, images and bootstrap. Some gateways might not even make use of ZF components.</p>

    <p>I would have an apache entry for each directory/symlink in /public.</p>
    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    /app
    /www
    /controllers
    /views
    /admin
    /phpmyadmin
    /wordpress-2.0
    Bootstrap.php
    /lib
    /ZF
    /Zend
    Zend.php
    /My
    Db.php
    /public
    /www
    /css
    /js
    .htaccess
    index.php
    /admin
    index.php
    .htaccess
    /phpmyadmin
    /blog
    ]]></ac:plain-text-body></ac:macro>

  28. Jul 01, 2008

    <p>I think, best is store all classes to one folder.</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    application/
    config/
    layouts/
    views/
    classes/
    api/
    controller/
    model/
    module/
    filter/
    ]]></ac:plain-text-body></ac:macro>

    <p>Name of classe will be containt package prefix like model_User, api_StatusInformation.<br />
    Maybe controller should be separately, but this is also class.</p>

    <p>The same model use Java in web application. It's easy for class loader to find any class, easier for user to find class, etc.</p>

  29. Jul 08, 2008

    <p>I, and others I've talked with, would really like to see a folder called 'library' inside 'application. The reason for this is that at some point you're likely to add an application-level library, and this would fit better inside the 'application' folder than in the root 'library' folder.</p>

    <p>Example of application-level library classes:</p>
    <ul>
    <li>MyApp_Validate_UsernameAndPassword</li>
    <li>SomeApp_Controller_Action_Helper_Jokelist</li>
    </ul>

    <p>Another reason for putting 'library' in 'application' is this: "dir layout here can be duplicated under modules/", quoted from this proposal. Having a library folder in module folders makes the module self-contained, meaining it would be a lot easier to plug in modules in your application, either by manually dropping a module in your 'modules' folder, or by using svn:externals.</p>

    1. Jul 08, 2008

      <p>+1</p>

      <p>I feel that module folders should be able to act as self-contained applications. Why should they be allowed models but not a library?</p>

  30. Jul 08, 2008

    <p><ac:image><ri:url ri:value="http://localhostr.com/files/98c415/Picture+1.png" /></ac:image></p>

    <p>This is the directory structure we have been using for zym. Its mainly a symfony/rails type of structure.</p>

    <p>What I see here is that the name "web" is more natural and explains exactly what the public folder would contain. Generally we do not have anything else inside the public folder besides web related files.</p>

    <p>We have an application level library folder because with most application there will be non-reusable application classes.</p>

    <p>While we can have configs at the module level, configs/ should be located outside of the application folder because we can then move that folder elsewhere or have multiple instances of an application running different sets of configs.</p>

    <p>The naming of images, styles, scripts is very clear and consistent compared to js, css and images/</p>

    <p>"Batch" was chosen because ZF already has multiple scripts folders and adding another one would lead to confusion.</p>

    <p>Overall the naming of the folders also has a nice feel to their location when sorted. "app" and "web" are clearly at the top and bottom of the list.</p>

  31. Jul 08, 2008

    <p>I'm writing a module which uses the following structure:</p>

    <p><ac:image><ri:url ri:value="http://oss.jasoneisen.com/wp-content/uploads/structure.png" /></ac:image></p>

    <p>I stick the module-specific library inside the module. Integrating into your app is done simply by adding a couple of lines to your bootstrap, which does all of the module's setup and adding it's library/models to your include path. This allows the module to use the library as well as for you to do so in your app outside of the module.</p>

    <p>This is necessary for a few reasons:</p>

    <p>1) Packaging. A single external that can be easily updated without being fragmented throughout your app.</p>

    <p>2) Installation. On top of packaging, it's much simpler to install into your app when there's just a single point of entry.</p>

    <p>3) Dependency. You can code your own libraries all you want to, do all kinds of crazy weird stuff, but the module wont depend on or even care about it; it all operates all on it's own and only cares that ZF is in your include path. This allows it to reliably do what it's supposed to do.</p>

    <p>As this structure stands now, re-usable modules can't be readily made available. Modules need to be viewed from a different angle, more "a project inside a project" rather than the current "set of related controllers". This is something ZF needs in my opinion, and is one of the major things which the competition has over it. What better way to spread ZF than to have a base library of user contributed, re-usable, ready to use modules you can drop right in to your app?</p>

    <p>Of course, this directory structure isn't the only issue keeping such a thing from happening, more needs to happen, like maybe a "plugin framework", a streamlined bootstrap, etc., but currently this is what is affecting my module. I don't like that it's currently breaking best practice, but I see no other correct way to do it from my perspective.</p>

  32. Aug 21, 2008

    <p>Could you provide an example implementation of the index.php and bootstrap.php?</p>

    <p>The way I understand it after reading the text, it would look something like this:</p>

    <p>index.php</p>
    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    <?php
    require getcwd() . '/../application/bootstrap.php';

    $bootstrap = new Bootstrap();
    $bootstrap->dispatch();
    ]]></ac:plain-text-body></ac:macro>

    <p>bootstrap.php</p>
    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    class Bootstrap
    {
    public function __construct()

    Unknown macro: { $this->_setupEverything(); }

    // .. setup methods

    public function dispatch()

    Unknown macro: { $frontController->dispatch(); }

    }
    ]]></ac:plain-text-body></ac:macro>

  33. Sep 12, 2008

    <p>I am not sure if I understood correctly how to set up the modules. So please think of a project with the two modules user and shop besides the default module. Will this be the prefered setup?</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    <project name>/
    application/
    apis/
    config/
    controllers/
    helpers/
    layouts/
    filters/
    helpers/
    scripts/
    models/
    modules/
    user/
    apis/
    config/
    controllers/
    helpers/
    layouts/
    filters/
    helpers/
    scripts/
    models/
    views/
    filters/
    helpers/
    scripts/
    shop/
    apis/
    config/
    controllers/
    helpers/
    layouts/
    filters/
    helpers/
    scripts/
    models/
    views/
    filters/
    helpers/
    scripts/
    views/
    filters/
    helpers/
    scripts/
    bootstrap.php
    ]]></ac:plain-text-body></ac:macro>

    <p>If this is the prefered way I am a little afraid that this is quite confusing for beginners. Why not suggest two directory layouts? One with modules and one without modules? The one will modules could look like this (the modules/ directory could even removed to keep things simpler):</p>

    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    <project name>/
    application/
    modules/
    default/
    apis/
    config/
    controllers/
    helpers/
    layouts/
    filters/
    helpers/
    scripts/
    models/
    views/
    filters/
    helpers/
    scripts/
    user/
    apis/
    config/
    controllers/
    helpers/
    layouts/
    filters/
    helpers/
    scripts/
    models/
    views/
    filters/
    helpers/
    scripts/
    shop/
    apis/
    config/
    controllers/
    helpers/
    layouts/
    filters/
    helpers/
    scripts/
    models/
    views/
    filters/
    helpers/
    scripts/
    bootstrap.php
    ]]></ac:plain-text-body></ac:macro>

    <p>What do you think?</p>

  34. Oct 23, 2008

    <p>This is a great discussion. I would hope though that this decision, whatever that may be, be carried over to the Zend Studio team. Currently, the docs in ZF suggest a structure and code style, and when using the ZF wizard in Studio, it is completely different. For those who can access Zend Support Tickets, its #180119.</p>

    <p>Thank you.</p>

  35. Oct 30, 2008

    <p>So a module has its own controllers, config, layouts, views and models. </p>

    <p>I see no reason it shouldn't also have it's own library. </p>

    <p>It would be easy if Zend_Controller_Front added the modules library path to set_include_path().</p>

    <p>This way a module could be an extension to another module and share the library.</p>

    <p>I don't think you need a layouts directory. I haven't used more than 2 or 3 layout files in any module and they work nicely when you place them in the root of views/scripts.</p>

    <p>I really would like to see public modular. This way we could point apache to public/module_name.</p>

  36. Dec 01, 2008

    <p>Great discussion.<br />
    However I'm not sure that's a good idea put volatile data like 'caches' and 'sessions' with less volatile data like 'logs' or 'uploads'.<br />
    Maybe 'caches' and 'sessions' inside a /temp folder will be a best practice.</p>

  37. Feb 13, 2009

    <p>What about module bootstrap?<br />
    I have one bootstrap.php on each module to start module specific resources, like another db connection, chenge the layout, etc.</p>

    <p>file: application/bootstrap.php</p>

    <p>(..)</p>

    <p>$frontController->addModuleDirectory(APPLICATION_PATH . '/modules/');</p>

    <p>defined('MODULE_PATH')<br />
    or define('MODULE_PATH', $frontController->getModuleDirectory());</p>

    <p>(..)</p>

    <p>//Perform module bootstraping<br />
    if (is_readable(MODULE_PATH . '/bootstrap.php'))<br />
    include(MODULE_PATH . '/bootstrap.php');</p>

    <p>What do you think?</p>

    1. Feb 13, 2009

      <p>Module bootstrapping will be handled by Zend_Application.</p>

  38. Feb 24, 2009

    <p>There is one problem not mentioned before:</p>
    <ul class="alternate">
    <li>the fact that language files (let's suppose .csv for translated texts) are stored into data folder. From a developer point this is not "volatile" data...</li>
    </ul>

    <p>So i think this should go into application folder as well...</p>

  39. Mar 01, 2009

    <p>One more comment.</p>

    <p>Config should be rather configs, if we are going to keep the same format for all folders.</p>

  40. Apr 09, 2009

    <p>1. You say: "Since Zend_Layout is capable of MVC- and non-MVC-based layouts ..." – could you give an example of non-MVC-based layouts?</p>

    <p>2. As others have said, cache and sessions should fall under the tmp/temp directory.</p>

    <p>3. .htaccess is specific to Apache – you could allow the developer to pass the name of his/her web server to the CLI and use that to generate the appropriate file(s)? For example:</p>

    <p>zf create project webserver apache     < Generates .htaccess file(s)<br />
    zf create project webserver iis7          < Generates web.config file(s)</p>

    <p>4. I think /etc is a crappy name for a folder, and far too generic, it could contain anything.</p>

    <p>5. I also prefer /tasks to /jobs.</p>

    <p>6. WRT /application/[MVC] + /modules vs /application/modules/default/[MVC], even though the latter may look a little neater, I agree with the way it is at the moment, for two reasons:</p>

    <p>1) Modules are supposed to be re-useable – how would someone re-use your 'default' module (with application-specific MVC)?</p>

    <p>2) Think about nested modules:</p>

    <p>/application<br />
        /modules<br />
            /default<br />
                /controllers<br />
                /models<br />
                /modules    <- The default module couldn't have nested modules, because its modules are siblings (see /forums).<br />
                /views<br />
            /forums<br />
                /controllers<br />
                /models<br />
                /modules<br />
                    /users<br />
                        [MVC]<br />
                /views</p>

  41. Apr 10, 2009

    <ul>
    <li>-webserver can also be used to decide which folder name to use for public files (htdocs, public_html, www, etc.)</li>
    <li>I think I prefer /config to /configs</li>
    </ul>

  42. Apr 26, 2009

    <p>Hi,</p>

    <p>Quite some discussion over here, so I decided to have a look at all your comments, think about it and think of a structure that complies with <em>most</em> arguments. A perfect structure is the structure that fits your application the best, but of it as something 'default'. Below is way to complex, but i tried to be complete.</p>

    <p>Problems and solutions (completely my thoughts and I like comments!):<br />
    <strong>(1) Config should be on root level:</strong><br />
    No, config is part of the application, system spex do belong as input to the application to function correctly, but this does not require the config to be at top level at all. I can think of it when required at CLI. But that is an other application, so CLI application requires an own folder.<br />
    <strong>(2) Naming of folders:</strong><br />
    Naming of folders should not be OS/Server specific, as ZF is an independent application. Public seems still ok to me as 'public'. No need for 'etc' or 'var' either. Global names are clear.<br />
    <strong>(3) Locale data:</strong><br />
    Locale data is site-wide. As modules are dependent on each other (as a Admin module is in a CMS system), there is no need to seperate locale data. So keep it global.<br />
    <strong>(4) Bootstrapping:</strong><br />
    Since Zend_Application is introduced I think bootstrap file might become a class by default. Uppercase because its a class. No need for Initializers or such, since this is all/or should be all covered by Zend_Application.<br />
    <strong>(5) Defaulting the structure:</strong><br />
    Empty folders (so, when you dont use builds for example) shoudld be removed. This all should just be a blueprint. When you need something, you know where to place it.<br />
    <strong>(6) Placement of layout folders:</strong><br />
    Since every module can have more than one completely different look it makes much sense to not have all layouts centralized. Lets have them in their own module folders.<br />
    <strong>(7) Hosting without write access outside the public folder:</strong><br />
    Pretty poor hosting then, suggest you place everything in a special folder in your public. Make sure APPLICATION_PATH and such is set. Have a .htaccess to manage access.<br />
    <strong>(8) Having the default module in a own folder:</strong><br />
    Seems very logical, and I'm not sure about that. Maybe.. ? More comments on that? Maybe for the sake of clearity that the default is more important that its not placed in its own folder.<br />
    <strong>(9) Forms:</strong><br />
    I do not really see why one would like to have them in the application folder, and not module specific. A form belongs to a certain part of logic and mostly cannot be generalized.<br />
    <strong>(10) Models:</strong><br />
    It's a good idea to have shared models in application/models/. Modules may not depend to much on each other.<br />
    <strong>(11) Nesting modules:</strong><br />
    Complex, but should be possible this way, right?<br />
    <strong>(12) Independent installation of modules:</strong><br />
    Thinking about this for a while, it would be nice to 'install' some new logic (on large projects/websites - see post Georg van der Howen). For example, you might want to give your customer the possibility to buy and install a forum on his website. Important is that such 'installations', or better 'extensions' of your framework, may not share logic which each other (thats what modules can do - f.e. a CMS can read from other modules). A 'forum' extension may not take logic from a 'blog'. It is dependent though on the working of the application and its modules. This all is why I named it different and put it not in the application folder. There is need for a own public folder, which can 'add' public stuff. That means if something is not found in the top level 'public' folder, it might be found in its extension folder. It something which came in my mind, and I like some suggestions and critic on it.</p>

    <p>There we go..</p>
    <ac:macro ac:name="noformat"><ac:plain-text-body><![CDATA[
    <project name>/
        application/
            configs/
            controllers/
                helpers/
            layouts/
                filters/
                helpers/
                scripts/
         models/
            modules/
                <module_name>
                    controllers/
                        helpers/
                    views/
                        filters/
                        helpers/
                        scripts/
                    layouts/
                        filters/
                        helpers/
                        scripts/
            Bootstrap.php            
        data/
            indexes/
            locales/
            logs/
            uploads/
        docs/
        library/

    ;;;;extensions?;;;;
    ;   extensions/
    ;       <extension_name>
    ;           application/
    ;               configs/
    ;                   ownroute.ini
    ;                   extension.ini
    ;               controllers/
    ;                   helpers/
    ;               views/
    ;                   filters/
    ;                   helpers/
    ;                   scripts/
    ;               layouts/
    ;                   filters/
    ;                   helpers/
    ;                   scripts/
    ;    models/
    ;           docs/
    ;           data/
    ;               indexes/
    ;               locales/
    ;               logs/
    ;               uploads/
    ;           library/
    ;           override_public/
    ;               scripts/
    ;               styles/
    ;               images/
    ;;;;extensions?;;;;

        public/
            styles/
            scripts/
            images/
            .htaccess
            index.php
        scripts/
            tasks/
            build/
        temp/
            sessions/
            cache/
    ]]></ac:plain-text-body></ac:macro>

    1. Apr 26, 2009

      <p>First, I'm going to note that much of this is codified into Zend_Application_Module_Autoloader and Zend_Tool_Project at this time, and there will not be significant deviation from it.</p>

      <p>Second, I'll address a few items of your breakdown. First off, the directories under 'application/' are primarily those relating to the default module; module directories would basically mimic the layout of that directory. For this reason, items such as "forms/", "models/", and "layouts/" were included, as we understand that these are often module specific. Shared forms and models should normally be considered library code otherwise.</p>

      <p>Regarding nested modules, no, there is no support for that in Zend Framework's MVC at this time. Modules are not hierarchical. That said, we <strong>do</strong> support having subdirectories within controller directories; you just need to use an '_' in the controller name to indicate the nesting.</p>

      <p>Your discussion of "extensions" as a repository for third-party modules sounds interesting. However, this is largely where we saw modules coming into play. That said, you can specify multiple module directories, so this pattern is already supported.</p>

  43. May 18, 2009

    <p>Let's consider some changes on public folder:</p>

    <p> css/ <br />
    js/ <br />
    images/ </p>

    <p>Rather should be:<br />
    styles - more generic name<br />
    scripts - more generic name<br />
    media - here would be also other things: video, swf, aso...</p>

  44. Nov 15, 2009

    <p>What would you consider acceptable for a released ZF application (open-source or sold to client), which distributes a version of ZF?</p>

    <ac:macro ac:name="noformat"><ac:plain-text-body><![CDATA[
    <project name>/
    application/
    ...
    library/
    Zend/
    MyApp/
    LICENSE_ZEND.txt
    ]]></ac:plain-text-body></ac:macro>

    <p>or bundling the ZF in the same structure as the minimal zip:</p>

    <ac:macro ac:name="noformat"><ac:plain-text-body><![CDATA[
    <project name>/
    application/
    ...
    library/
    vendor/
    ZendFramework/
    bin/
    library/
    Zend/
    LICENSE.txt
    MyApp/
    ]]></ac:plain-text-body></ac:macro>

  45. Dec 08, 2009

    <p>I think, data/ folder should be splitted eventually also into modules. Let's assume we have indexes/ for every module (every module has some data to be indexed). What do you think?</p>

  46. Dec 08, 2009

    <p>Also, I agree that in the data/ folder should be stored also permanent (100% non-volatile) data (as files that generated some documents, original archives containing some data, images representing previews for some documents, and others )...</p>

  47. Dec 08, 2009

    Ami

    <p>data/ like</p>

    <p>data/production/session<br />
    data/production/upload<br />
    data/production/...</p>

    <p>data/developement/session<br />
    data/developement/upload<br />
    data/developement/...</p>

    <p>data/testing/session<br />
    data/testing/upload<br />
    data/testing/...</p>

  48. Jun 29, 2010

    <p>One of need of web application is client's side version control. It's really need because when you update the sources client use old js, css and image file and may your web app have many problem with those.</p>

    <p>When use JavaScript files and CSS files in project in.</p>

    <ac:macro ac:name="noformat"><ac:plain-text-body><![CDATA[
         public/
    .htaccess
    index.php
            0.6/
               styles/
               scripts/
               images/
    ]]></ac:plain-text-body></ac:macro>
    <p>When you change the new version of your software the folder must be renamed and cache of client for any .js, .css, .jpg, .png, .gif and etc will not found in new address.</p>

    <p>For this one we need a resource plug-in for using in client.<br />
    Or maybe version resource will be used in any component and classes.</p>