Меню
Что нового?

Организация файловой структуры сайта? (Ядро + модули)

Гриша К.

Новичок
Организация файловой структуры сайта? (Ядро + модули)

Здравствуйте.

Я пытаюсь выбрать файловую структуру для сайта интернет-магазина и способ обращения к неободимым скриптам (при помощи url).
Я смотрел организацию файловой структуры в разных проектах (bitrix, oscommerce, php-nuke, phpbb), полностью в их устройстве разобраться не смог.

Я предполагаю структуру сайта организовать таким образом, чтобы было ядро сайта (в моем понимании это общий необходимы набор скриптов), и подключаемые модули, каждый модуль находился в отдельной папке, таким образом чтобы была видна его полная структура. Информацию о модулях хранить в БД. Информацию об скриптах обработчиках хранить в БД, с таблице файловой структуры сайта.

Придумал вот такой вариант структуры:
Прошу вас написать какие-либо советы по организации структуры сайта (ссылки), возможно какие-то сооброжения по приведенной структуре.
Ядро сайта
PHP: 
/admin/ #АДминистрация
/includes/ #Набор общих функций, классов и тд.
/templates/ #Шаблоны
/css/ #Стили
/modules/ #Модули
index.php
Пример структуры модуля каталога
PHP: 
/modules/catalog/admin/ #Администрирование каталога
/modules/catalog/public/includes/ #Набор необходимых функций, классов и тд.
/modules/catalog/public/templates/ #Шаблоны каталога
/modules/catalog/public/css/ #Стили каталога
/modules/catalog/public/catalog/index.php
/modules/catalog/index.php #Настройки модуля
Необходимые минимальные действия для установки модуля (пункты 1 и 2 - если модуль работает самостоятельно, а не как дополнение, например новости могут показываться только на главной странице сайта)
PHP: 
1) создание файла catalog.php в /admin/
следующего содержания <? include('/modules/catalog/admin/catalog.php'); ?>
2) копирование содержимого папки /modules/catalog/public/ в корневую директорию
3) загрузка данных в БД: список модулей (modules), список структуры сайта (pages), таблицы для работы модуля.
В итоге url для обращения к каталогу: http://localhost/catalog.php (catalog.php?catid=12 и т.д.)
url для обращения к управлению каталогом: http://localhost/admin/catalog.php
 

ix

Новичок
ну, раз соображения принимаются, то могу сказать, что логичнее хранить css и шаблоны в одном месте, а не разбивать по разным каталогам - это если имеются ввиду шаблоны, которых может быть несколько (по типу как в joomla/xt:com)
 
bgm

bgm

&nbsp;
Не касаясь остального: зачем в БД загружать список модулей, список стурктуры и т.д.?
 

Гриша К.

Новичок
ix, спасибо за ответ.
Модуль загружается на сайт, например /modules/catalog/
Содержимое папки /modules/catalog/public/ копируется в корень сайта, следующим образом:
например содержимое папки /modules/catalog/public/css/ копируется в папку /css/, если в корне такой папки не существует, то она создается.
Т.е., в итоге все /modules/.../public/css/, /modules/.../public/templates/, /modules/.../public/includes/ модулей, хранятся в соответсвующих корневых папках сервера: /css/catalog.css, /templates/catalog.tpl, /includes/function.catalog.php и т.д.


bgm, спасибо за ответ.
Я решил загружать список модулей в БД, для того чтобы потом сравнить их с загруженными на сайт папками модулей, и выдать список установленных и неустановленных модулей. Возможно есть другой более рациональный варианты?

В БД я также решил загружать данные скриптов обработчиков (id, url срипта, файл скрипта, название), для того чтобы потом выдавать список всех страниц и на них назначать права доступа.
 

die_hard

Новичок
не боитесь конфликты словить?
Что вам мешает хранить ваши модули не копируя никуда. а инициализацию регулировать другим способом? например флагом в бд.
 

Гриша К.

Новичок
die_hard, спасибо за ответ.

Вообще папки /modules/.../public/ предназначены только для установки модуля, после установки они и не нужны. Т.е. по идеи файловая структура сайта может выглядить следующим образом:
PHP: 
/admin/ #АДминистрация 
/admin/catalog.php #Управление каталогом
/includes/ #Набор общих функций, классов и тд. 
/includes/function.catalog.php #Набор функций, классов и тд. для каталога 
/templates/ #Шаблоны 
/templates/catalog.tpl #Шаблоны каталога 
/css/ #Стили 
/css/catalog.css #Стили для каталога
/modules/catalog/index.php #Инфо о модуле
/catalog/index.php #СТраницы каталога
index.php
В итоге получаются следующие url модуля каталога:
http://localhost/admin/catalog.php
http://localhost/catalog/index.php
и т.д.
А не http://localhost/modules/catalog/index.php
Я видел что модули например загружают таким образом:
http://localhost/module.php?module=catalog,
но мне вид этого url Не нарвится, mod_rewrite применить неполучается, так как например url обращения к каталогу может содержать множество параметров фильтра.

а инициализацию регулировать другим способом? например флагом в бд.
Нажмите для раскрытия...
Если модуль не установлен, то соответсвенно информации в БД, о нем нет, и флага в БД на него не поставить. Либо я вас неправильно понял?

Какие могут быть конфликты в данном примере?
 
bgm

bgm

&nbsp;
Гриша К.
Данные о скриптах, судя по всему, будут использовать только сами же скрипты. Т.е. логично будет данные о скриптах хранить там же, где и скрипты. Для этого разумно будет использовать или стандартные ini-файлы или xml.
 

Гриша К.

Новичок
bgm, спасибо за ответ.
Я предполагаю настройки о модуле, например /module/catalog/ хранить в /catalog/options.php
а информация о модуле (название, расположение, файлы инсталляции) будет храниться в /module/catalog/index.php
Предполагаю, что таким образом, я смогу вывести список всех закаченных модулей, сопоставить его со списком загруженных модулей в БД, и увидеть информацию о расположении частей модуля.
 

die_hard

Новичок
Автор оригинала: Гриша К.
die_hard, спасибо за ответ.

Вообще папки /modules/.../public/ предназначены только для установки модуля, после установки они и не нужны. Т.е. по идеи файловая структура сайта может выглядить следующим образом:
PHP: 
/admin/ #АДминистрация 
/admin/catalog.php #Управление каталогом
/includes/ #Набор общих функций, классов и тд. 
/includes/function.catalog.php #Набор функций, классов и тд. для каталога 
/templates/ #Шаблоны 
/templates/catalog.tpl #Шаблоны каталога 
/css/ #Стили 
/css/catalog.css #Стили для каталога
/modules/catalog/index.php #Инфо о модуле
/catalog/index.php #СТраницы каталога
index.php
В итоге получаются следующие url модуля каталога:
http://localhost/admin/catalog.php
http://localhost/catalog/index.php
и т.д.
А не http://localhost/modules/catalog/index.php
Я видел что модули например загружают таким образом:
http://localhost/module.php?module=catalog,
но мне вид этого url Не нарвится, mod_rewrite применить неполучается, так как например url обращения к каталогу может содержать множество параметров фильтра.


Если модуль не установлен, то соответсвенно информации в БД, о нем нет, и флага в БД на него не поставить. Либо я вас неправильно понял?

Какие могут быть конфликты в данном примере?
Нажмите для раскрытия...
Скорее всего структуру шаблонов по вашему плану надо все-таки

вот так сделать.

PHP: 
/templates/ #Шаблоны 
/templates/catalog/index.tpl #Шаблоны каталога. Номер 1. главный раздел каталога
/templates/catalog/category_details.tpl #Шаблоны каталога. Номер 2. свойство како-то категории
-~{}~ 22.08.06 16:51:

кстати раз пошла такая пьянка с разделением файлов. неплохобы и жабаскрипт отдельно убрать.
 

Гриша К.

Новичок
die_hard, спасибо за ответ.
Действительно так будет удобнее. Я думаю тогда так сделать и с папкой admin (/admin/catalog/).
А папка /js/ была уже запланирована.

С помошью всех отвечавших в топике, я практически пришел к единому мнению о построение файловой структуры на разрабатываемом проекте. Проект уже сделан на 50%, изначально структура была несколько другая, но при большом количестве скриптов (модулей), мне она уже увиделась не подходящей.
 

Гриша К.

Новичок
Alexandre, спасибо за ответ.
Если модули в ini файле (записывать построчно информацию о новом модуле), то при получение списка модулей буду например открывать файл list_modules.ini, вот оказывается есть даже такая функция parse_ini_file, то будет ли это работать быстрее чем запрос к БД (возможно вы тесировали и знаете), и какие приимущества при хранение настроек в файлах ini?
Так же прочитал что настройки хранятся еще и в xml файлах, но с xml я пока еще не работал, возможно стоит использовать такой вариант, какие приимущества, незнаетили?
 

dub

Новичок
Гриша К.
в xml не храни, ини тут мне кажетяся намного удобней. особенно если у тебя пхп 4. (по крайней мере работа будет однозначно медленнее чем с базой это точно, да и нормальной sax обработки пока нету). собственно тебе ничего не мешает хранить ini файлы в отдельной папочке ini за пределами www, обращаясь к ним из под php-шки, так они и для внешнего мира будут недоступны.
 

LOG

Новичок
зачем городить... посмотри как сделано в *nix и сделай так же
 

Гриша К.

Новичок
dub, спасибо за ответ.
С хранением настроек теперь несколько не могу определиться.

Чтобы сделать файлы настройки недоступными для пользователей:
1) А если парсить файл типа catalog.ini.php, будет ли это дольше чем catalog.ini.
2) Или настроить .htcasses
<Files "*.ini">
Order allow,deny
Deny from all
</Files>

Большинство настроек (Подключение к БД, базовый адрес и т.д.), храниться будут в файле, я думаю например config.php (так есть сейчас). А например список подключенных модулей в БД.

-~{}~ 23.08.06 16:30:

LOG, спасибо за ответ.
Что за файлы *nix незнаю, щас поищу в поиске.
 

Alexandre

PHPПенсионер
Если модули в ini файле (записывать построчно информацию о новом модуле), то при получение списка модулей буду например открывать файл list_modules.ini, вот оказывается есть даже такая функция parse_ini_file, то будет ли это работать быстрее чем запрос к БД (возможно вы тесировали и знаете), и какие приимущества при хранение настроек в файлах ini?
Так же прочитал что настройки хранятся еще и в xml файлах, но с xml я пока еще не работал, возможно стоит использовать такой вариант, какие приимущества, незнаетили?
Нажмите для раскрытия...
Гриша К.1) скорость выбора данных из файла или БД зависит от многих причин, но основная из них - это нагруженность БД. Соответственно, если БД сильно нагруженна, то соответсвенно выбор данных будет осуществляться быстрее из ини-файла.
2) Раз с XML не работал, то лучше не заморачивайся. Скорость работы с XML файлами всегда медленее аналогов.
У меня будет реализовано сл. образом
- все настройки в XML файле.
- XML файл парсится специальным скриптом и генерится файл config.ini.php
- инклудится файл config.ini.php
Хочется отметить, что XML файл парсится ни каждый раз - при загрузки скрипта, а только при изменении конфига через админку или запуском спец скрипта, типа configCompile.
 
Войдите или зарегистрируйтесь для ответа.
Сверху