Как организовать структуру каталогов библиотеки программирования общего назначения?

поскольку это многоцелевая библиотека, предназначенная для решения универсальных проблем или обеспечения интерфейсов для общих функций, лучше иметь структуру subject который может быть типом данных / технологией / языком / протоколом etc. вот так:

+ Http
  - request
  - response
  + util
    - status_codes
+ Html
  - Validator
  + Form
    - UploadFile
  + Tag
+ JavaScript
  - JSON
+ Ajax
+ XML
  - Reader
  - Writer
  - Parser
+ DataType
  - Array
  - Integer
  - String
  - Double
  - Float
  + util
    - datatypes_cast_lib

сверху у нас есть:

• адресу http который является протоколом, так как Http.request будет интерфейсом для выполнения Http-запроса
• HTML-код который является языком разметки, так что Html.Form.UploadFile будет предоставьте разработчику функции для создания форм файлов загрузки
• JavaScript который является языком программирования, поэтому ваш Javascript.JSON решит проблемы преобразования из JSON в массивы, возможно
• Ajax что технологии
• XML который является языком разметки
• тип, который является ... ну, типа данных.

обратите внимание, что status_codes оставаться под util на Http. Каждая суб-библиотека может иметь свои собственные функции util, такие как DataType Либ может понадобиться datatype_cast_lib уметь жонглировать типов.

этот способ организации библиотеки в основном напоминает организацию PECL

хороший вопрос, кстати! Я сам часто задавал себе этот вопрос. Я организовывал и реорганизовывал свою структуру каталогов в течение многих лет. Это действительно зависит от проекта. Я адаптировал структуру выше, соответствующую структура, которую вы предоставили здесь.

Я бы предложил вам посмотреть, как все организовано в двух последних фреймворках php 5.3,в Symfony2 и лития.

основные разработчики за ними были активны (наряду с другими крупными разработчиками фреймворков и знаменитостями php) в определении стандартных соглашений об именах php 5.3, чтобы их соответствующие компоненты могли играть друг с другом, Zend и другими библиотеками/фреймворками, которые могут следовать за тем же условные обозначения:

http://groups.google.com/group/php-standards/web/php-coding-standard

в обоих случаях пакеты/библиотеки первого сорта, и две похожие модели, когда дело доходит до организации их.

литиевое ядро, в частности, является библиотекой в своем собственном праве. Он организован так:

$ ls
LICENSE.txt analysis    core        g11n        security    template    tests
action      console     data        net         storage     test        util

(Я, как правило, нахожу Symfony 2 немного более беспорядочным/менее предсказуемым, но это только мое собственное мнение.)

пожалуйста PSR-0 совместимый, любая структура вы идете использовать.

Я лично предлагаю использовать структура каталогов PEAR2 .

Я бы сказал, что хорошее место для начала-посмотреть, как это делают другие фреймворки и/или библиотеки.

лично мне нравится, как Zend Framework организован с довольно плоским пространством имен, имеющим все основные компоненты в каталоге Zend. При использовании структуры проекта Zend MVC вы получаете добавленный автозапуск, переводящий _ в / все классы с именем Zend_Form и поместите в файл под названием Form.php внутри каталога Zend, так что при вызове new Zend_Form - загрузчик ищет Zend/Form.php. Только "основной" класс находится непосредственно внутри папки Zend, любые дополнительные файлы классов, такие как исключения и абстрактные, помещаются внутри Zend/Form папка и имена классов с именем Zend_Form_Exception - которые заставляют автозапуск искать Zend/Form/Exception.php.

другой момент, чтобы держать логику бэкэнда подальше от любой папки public_html. Например, здесь должны быть только файлы, которые должны быть непосредственно доступны пользователям (javascript, css и ваш загрузчик.РНР+ .реврайт). Тогда есть погрузчик.php включает файлы, которые ему нужны, как правило, на один уровень выше.

внешние библиотеки обычно рассматриваются как таковые и отделяются от остальной части кода в папке /lib, /library и/или /vendor, чтобы указать, что внешние авторы несут ответственность за эти классы.

Я бы сказал, что это зависит от того, как/если вы используете namepaces и т. д. В противном случае я бы увидел использование чего-то вроде макета каталога ZendFramework (хотя это уродливо, как грех... хе-хе). Тогда у меня обычно есть Coreкоторый содержит базовую функциональность, которую все другие части могут использовать как манипуляции с массивом и строками, шифрование/дешифрование

+ Core
 - Array
 - String
 + Encryption
   - MD5
   - SHA1
   ...

затем я пытаюсь думать обо всех последующих папках как об изолированных частях / модулях. У меня есть папка с jQuery с помощью jQuery хелперы? Тогда это может быть хорошей папкой для добавления.

+ Core
 - Array
 - String
 + Encryption
   - MD5
   - SHA1
   ...
+JQuery

требует ли мой JQuery некоторых особенностей HTML, которые могут также использовать другие "модули"? Тогда это должно войти в ядро. Например, мои помощники JQuery могут использовать JSON.

+ Core
 - Array
 - String
 + Encryption
   - MD5
   - SHA1
   ...
 + Encoding
   - JSON
+JQuery

если это конкретные jQuery здесь следует recide под jQuery.

+ Core
 - Array
 - String
 + Encryption
   - MD5
   - SHA1
   ...
+ JQuery
  - Datepicker

всегда задавая вопрос "это то, что другие части моей библиотеки будут использовать и/или расширять?- вы получите хорошее представление, если рассматриваемая функциональность должна быть частью вашего ядра или частью вашего конкретного библиотечного модуля.

<project name>/
    application/
        configs/
            application.ini
        controllers/
            helpers/
        forms/
        layouts/
            filters/
            helpers/
            scripts/
        models/
        modules/
        services/
        views/
            filters/
            helpers/
            scripts/
        Bootstrap.php
    data/
        cache/
        indexes/
        locales/
        logs/
        sessions/
        uploads/
    docs/
    library/
    public/
        css/
        images/
        js/
        .htaccess
        index.php
    scripts/
        jobs/
        build/
    temp/
    tests/

источник:http://framework.zend.com/manual/en/project-structure.project.html