ФорумПрограммированиеPHP для идиотов → строение файловой системы для не большого проекта

строение файловой системы для не большого проекта

  • Trieg

    Сообщения: 41 Репутация: N Группа: Адекваты

    Spritz 15 января 2010 г. 7:46

    условные обозначения:
    [badNameList] - в данный момент index, modul, admin, captha, ajax, user, page
    [all] - любое строение и именование фалов\директорий

    {ext} - расширение файлов соответствующие определеннуму типу (к примеру видео, картинки, флеш)
    {name_1} - больше 3 меньше 32 символов, только английские буквы нижнего регистра, знак подчеркиванья.
    {name_2} - тоже самое что и {name_1} но можно использовать точку.
    {name_3} - тоже самое что и {name_1} но можно использовать верхний регистр.
    {controller} - контроллер *ограничения как у {name_2}
    {modul} - модуль контроллера *ограничения как у {name_2}
    {plugin_name} - тоже самое что и {name_2}, нельзя использовать в качестве имени [badNameList]
    {theme_name} - имя темы *ограничения как у {name_1}
    {lang_name} - имя языка *ограничения как у {name_1}
    {lang_fname} - либо {controller}.php либо {controller} . {modul}.php, исключение (core.php ***)
    {class_name} - имя класса *ограничения как у {name_3}
    {namespace} - пространство имен (с версии php5.3 можно юзать это счастье)
    {plugin_name} - имя плагина *ограничения как у {name_1}
    {hook_name} - больше 4 меньше 64 символов, только английские буквы нижнего регистра и точка.
    {user_id} - уникальный id пользователя
    {temp_name} - временное имя файла *ограничения как у {name_3}.


    /themes/{theme_name}/core.{controller}.{modul}.tpl - файл шаблона (то что его вызвало является частью ядра)
    /themes/{theme_name}/theme.{name_2}.tpl - не обязательный файл шаблона, подключается в других шаблонных файлах
    /themes/{theme_name}/{plugin_name}.{controller}.{modul}.tpl - файл шаблона пренадлежащий плагину с именем {plugin_name}
    /themes/{theme_name}/style/{name_2}.css - всякие css файлы
    /themes/{theme_name}/javascript/{name_2}.js - js файлы
    /themes/{theme_name}/language/{name_1}.php - доступные языки
    /themes/{theme_name}/image/[all] - картинки, по идее сюда можно положить что угодно
    /themes/{theme_name}/plugin/{name_2}.php - специфическая логика для данного шаблона (фишки, рюшки, расширение для компилятора шаблона)
    /themes/{theme_name}/flesh/{name_2}.{ext} - флешки
    /themes/{theme_name}/{theme_name}.php - информация о авторе и секция для действий инсталяции и деинсталяции (яз что там понадобится, так на всякий случай)

    /system/language/{lange_name}/{lang_fname} - файл с куском локализации
    /system/image/[all] - картинки что использует ядро
    /system/javascript/[all] - js скрипты для ядра
    /system/engine/class/{class_name}.php - файл с php классом
    /system/engine/class/{namespace}/{class_name}.php - файл с php классом что находится в {namespace}
    /system/engine/controller/{name_1}.php - контроллер
    /system/engine/moduls/{controller}/{name_1}.php - модуль контроллера {controller}

    /system/engine/compatibility.php - отвечает за проверку на совместимость
    /system/engine/function.admin.php - функции которые подключаются только для контроллера admin
    /system/engine/function.php - куча функций, используется везде где тока можно

    /system/config.php - типичный конфиг файл что нужно отредактировать перед работой с системой

    /plugins/{plugin_name}/{plugin_name}.php - файл с информацией для инсталяции и деинсталяции компонентов плагина (создание нужных таблиц, получение нужной инфы при установке, дефолтные настройки для acl)
    /plugins/{plugin_name}/hook.{hook_name}.php - файл плагина что используется системой как один из хуков
    /plugins/{plugin_name}/modul.{modul}.php - файл плагина что используется системой как модуль контроллера
    /plugins/{plugin_name}/language/{lang_name}.php - файл локализации
    /plugins/{plugin_name}/language/{name_1}.php - файл локализации, вызывается ручками из любого места текущего плагина
    /plugins/{plugin_name}/class/{plugin_name}_{class_name}.php - Класс доступен только в том случае если вызов произошел из файла что находится в нутри директории {plugin_name}
    /plugins/{plugin_name}/template/{plugin_name}.{controller}.{modul}.tpl - подключается в случае отсутствия файла с таким же именем в нутри активной темы.
    /plugins/{plugin_name}/template/[all] - все что надо для шаблона (картинки, скрипты, стили)


    /datas/cache - хранилище для файлового кеш драйвера и для компилятора шаблонов (все свалено без поддиректорий (имена файлов не md5, пример - config.core.php и tpl.innocence.core_error404_tpl.php)
    /datas/user/{user_id}/ - тут хранятся все файлы пользователя с {user_id} (авка, фотка, картинки в подписи и все что он залил в личный архив или на форум)
    /datas/html/{name_1}.html - статистическая страница
    /datas/temp/{temp_name} - временный файл созданный ядром (как правило надо тока при обновлении какого либо компонента или иногда служит индикатором лока)
    /datas/store/{name_1}.{ext} - файлы которые автоматически обновляются (к примеру база geoIp и browscap.ini)
    /datas/system/{name_1}.php - файлы что требуется подключить до инициализации системы (пока ет некоторые конфиги)


    Пока я думаю внести следуйщие изменения:
    1 - убрать файлы что лежат в корне папки /system/engine/, создать папку /system/engine/helper и хранить файлы с набором функций, именовать так же как {lang_fname}, подрубать их автоматом, по аналогу с этим сделать папку в плагине.
    2 - убрать папку /system/javascript/ и /system/image/, в замену создать /system/хз что/ и там хранить подобную дребедень (в общем все что отдается клиенту)
    3 - все что в /system/engine/ выкинуть в /system/ а прошлую диру делитнуть

    Вопросы на которые хочется получить ответы:
    1 - Каждая тема должна содержать дизайн для админ панели, диз админки не часто меняют.. может как то по другому организовать?
    2 - Стоит ли максимально ужесточить правила для именования директорий темы и плагина?
    3 - Все имена дир и файлов в нижнем регистре кроме тех что system/engine/class стоит ли так делать? (честно скажу так сделал тока ради красоты и сам понимаю Возможные трудности но ведь их не возникнет если следовать правилам =) )
    4 - Можно ли злоупотреблять (ну ет громко сказано, не более 120 вызовов и все к частям системы что не измены) функцией file_exists для автоматизации подключения классов, наборов функций, контроллера, модуля, хуков, ланг файлов, шаблонов (по идее после первого вызова результат функции кешируется, и обращение к файловой системе на второй раз не идет.. я правильно думаю?)
    5 - Что по вашему мнению необходимо изменить\удалить\добавить?

    Чтоб не создавать еще один топик сразу спрошу про utf8:
    1 - Какие подводные камни при использовании кодировки utf8?
    2 - Какие ограничения\правила в использовании регекспов и строковых функцый с utf8?
    3 - Какие стандартные функции могут начать чудить заметив utf8?
    4 - Сколько % проблем покроет mbstring.func_overload и выставление нужной локали при учете того что регекспы не используются (это не так, но давайте представим)
    5 - mbstring.func_overload > Changeable = PHP_INI_SYSTEM | PHP_INI_PERDIR, PHP_INI_PERDIR значит что я магу менять значение юзая .htaccess?
    6 - Какие дополнительные настройки\действия вы можете порекомендовать при переходе на utf8?
    7 - Существует ли сумермегакласс который решит львиную часть возможных проблем?
    8 - Есть ли в природе список рекомендаций от разработчиков самого интерпритатора или его ядра?


    Сейчас все крутится на cp1251/PHP5.3.1/Apache2.2/дорога мне в ад но os Windows XP, объем php кода более 17к строк, весь код знаю идеально с utf-8 дела не имел(тока по мелочи), бд набита ненужной тестовой инфой, не каких парсеров пока не использую (исключение компилятор шаблонов, но если я прально понимаю то те регекспы что там не пострадают). Интересует только личный опыт, или актуальная информация из надежного источника. + ктонить может адекватно оценить время которое потребуется на переход учитывая предоставленную информацию? У кого есть полезный и проверенный код которым не жалко поделится приму в дар =).

    PS: в первую очередь интересуют ответы по теме а на utf-8 решил перейти так как многие сервисы юзают именно это кодировку так же заколебало чудить с аяксом ну и само собой этож блять теперь модно.. запарился набирать так что сори за ошибки и опечатки, я не олень =))
  • md5

    Сообщения: 11960 Репутация: N Группа: в ухо

    Spritz 15 января 2010 г. 9:08, спустя 1 час 21 минуту 54 секунды

    ох, ебать :))
    сложно оценить по времени - 17к строк кода
    т.к. не везде же надо будет только кодировку поменять,с тем же аяксом - код переписать и все иконвы поубирать

    но не в ручную че все это конвертить..
    все умрут, а я изумруд
  • Абырвалг

    Сообщения: 6480 Репутация: N Группа: Джедаи

    Spritz 15 января 2010 г. 12:28, спустя 3 часа 19 минут 28 секунд

    1 - Какие подводные камни при использовании кодировки utf8?

    регулярки в MySQL некорректно работают
  • Trej Gun

    Сообщения: 5305 Репутация: N Группа: в ухо

    Spritz 15 января 2010 г. 16:08, спустя 3 часа 40 минут 2 секунды

    Абырвалг, ага ты их каждый день используешь
    Спустя 40 сек.
    а линукс хуевый тем что из консоли нельзя выполнить команду 2Гб длиной
  • artoodetoo

    Сообщения: 5147 Репутация: N Группа: в ухо

    Spritz 15 января 2010 г. 18:25, спустя 2 часа 17 минут 43 секунды

    про легенду:
    так хорошо начал, а почему-то name* обозначения выбрал неговорящие. почему бы не назвать
    {name} - больше 3 меньше 32 символов, только английские буквы нижнего регистра, знак подчеркиванья.
    {name_dot} - тоже самое что и {name} но можно использовать точку.
    {Name} или {name_ci} - тоже самое что и {name} но можно использовать верхний регистр.

    подводные камни utf-8 и кириллицы:
    - не забывать mb_internal_encoding() :)
    - в mysql пишем "utf8" без дефиса :)
    - utf-8 может содержать символы до 4 байт длинной
    - я отказался от оверлоадинга, чтобы четко видеть где у меня строка считается набором байтов, а где мультибайтной цепочкой.
    - кажется в preg_* функциях, даже при указании модификатора "u", неадекватно отрабатываются \w и \W для нелатиницы. + модификатор "i"… хотя может быть это уже исправлено. давно это было…
    - файлы и папки никогда не именую кириллицей. даже в Windows. где-нибудь да вспывет косяк


    ιιlllιlllι унц-унц

Пожалуйста, авторизуйтесь, чтобы написать комментарий!