TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Подключение статических файлов из модуля
  • Не могу разобраться как правильно подключать css/js/image файлы из модулей. Хотелось бы что бы файлы лежали в папке модуля MODULE_NAME/media/{css,js,images}

    Пока что мне попался модуль https://github.com/aberdnikov/kohana-static-files И еще нашелся контроллер из другого модуля https://github.com/vimofthevine/kohana-admi...admin/media.php

    Со вторым у меня пока что ничего не вышло.

    В принципе я мог бы вынести все эти файлы в /public и указать в конфигурационном файле модуля путь к статическим файлам. Но как быть с изображениями которые я указываю в самом css файле + js файле.

    В общем я в полном замешательстве. Помогите чем нибуть.

  • <?php echo HTML::style('modules/modulename/media/css/style.css') ?>

    http://kohanaframework.org/3.3/guide-api/HTML#style

    HTML::image, HTML::script по аналогии.

    А что сложного в css? background: url(/modules/modulename/media/images/bg.jpg)

  • Ну на сколько я понял только для папки в которой будут лежать css/js и изображения нужно открыть полный доступ, а остальные каталоги должны быть защищены. А ваш способ не безопасен, на сколько я могу судить. Но опять таки я основываюсь исключительно на всем том материале который мне довелось прочитать.

    Тогда каков смысл модулей типа https://github.com/aberdnikov/kohana-static-files и роутов типа https://github.com/vimofthevine/kohana-admi...admin/media.php если все так просто как вы описали?

  • nazarov, в дефолтном .htaccess есть RewriteRule ^(?:application|modules|system)\b.* index.php/$0 [L], что как бы намекает....

  • @serieznyi, всем там безопасно. Эти директории из браузера не откроются, более того, там придется отдачу делать через php. Если грамотно отдавать заголовки то можно добиться вполне нормальной работы :) Подобный подход используется в userguide-е коханы, там ее статика именно так отдается.

  • Хм... ну тогда меня просто ввели в заблуждение )

  • @serieznyi даже не нужно ни каких модулей со стороны :) Это делается элементарно - у меня один дополнительный роут и экшен, аналогичный экшену из модуля userguide для обработки статики :) И все :)

  • rex, такой подход ущербный с точки зрения производительности. На каждый файл будет запускаться целый instance приложения. Т.е. если на странице 4 скрипта и 3 стиля, то на одну страницу запустится 8 инстансов приложения (каждый из которых пройдет полный путь, от index.php->bootstrap.php->routes->controller->action->render). 1000 человек - и даже vps ляжет к верху лапками. Статику нужно отдавать nginx безо всякого этого.

    Я пошел немного дальше :) использую этот модулек https://github.com/azampagl/kohana-compress собираю им все скрипты, он их сжимает,сохраняет и отдает url на файл. Таким образом можно хранить статику где угодно и производительность не пострадает, а даже наоборот, за счет того, что файлы мержатся в 1 и сжимаются

  • rockwill Вот фрагмент из вышеуказанного модуля

    $result = Compress::instance()->scripts(array('media/js/jquery.js', 'media/js/jquery.ui.js', 'media/js/my-scripts.js')); // E.g.

    <

    script type="text/javascript" src="/media/cache/0a21d9d23a9fa5e19ea62a49dd5cd85680a2c63f.js"> echo HTML::script($result);

    Я так полагаю указав все нужные мне скрипты я получаю файл который и подключаю.

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

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

  • в файле htaccess перед строкой

    RewriteRule ^(?:application|modules|system)\b.* index.php/$0 [L]

    вставьте

    RewriteRule ^modules/.*/static/ - [L]

    это даст исключение в перенаправлении на index.php директории static в любом модуле.

    Для безопасности создайте в папке modules еще один файл htaccess со строкой

    Options All -Indexes

    Это не даст просмотреть директорию

  • DimkOf , спасибо. Буду иметь в виду. Но мне очень понравился вариант rockwill. Можно в модуле генерировать файл стилей и скрипт в публичную директорию. Которую после можно просканировать и найденные файлы подключить.

    Правда у меня возникли сложности. Я скачал модуль, прописал его в bootstrap, в конф. файле модуля указала путь к директориям выхода. В контроллере от которого унаследованы все остальные контроллеры основных страниц прописал.

    Compress::instance()->scripts(array('public/js/autocomplite.js'), 'global_script.js');

    Но мне выдает ошибку

    ErrorException [ Fatal Error ]: Class 'Compress' not found

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

  • DimkOf, вариант, но не гибкий. Такой подход вомзожен только в случае, когда папка modules лежит в webroot. я, например, выношу на уровень выше всегда, чтобы в webroot оставался только index.php и статика. Ну и запретить просматривать папку можно просто убрав RewriteCond %{REQUEST_FILENAME} !-d

  • serieznyi, покажите ваш Kohana::modules() из bootstrap. Какой версией Kohana кстати пользуетесь? В 3.3 был изменен autoloader.

  • rockwill Версия одна из последних 3.2 или 3.3. Я не знаю где я могу это посмотреть.

    Kohana::modules(array( 'kohana-compress' => MODPATH.'kohana-compress', 'A2ACLdemo' => MODPATH.'A2ACLdemo', 'ulogin' => MODPATH.'ulogin', 'a1' => MODPATH.'a1', 'a2' => MODPATH.'a2', 'acl' => MODPATH.'acl', 'debug-toolbar' => MODPATH.'debug-toolbar', //'auth' => MODPATH.'auth', // Basic authentication // 'cache' => MODPATH.'cache', // Caching with multiple backends // 'codebench' => MODPATH.'codebench', // Benchmarking tool 'database' => MODPATH.'database', // Database access // 'image' => MODPATH.'image', // Image manipulation 'orm' => MODPATH.'orm', // Object Relationship Mapping // 'unittest' => MODPATH.'unittest', // Unit testing //'userguide' => MODPATH.'userguide', // User guide and API documentation 'auth2' => MODPATH.'auth2', // модуль авторизации/регистрации пользователей ));

    DimkOf Это вариант я так полагаю удобен в случае подключения файлов непосредственно из папки модуля. Я пытался подключить изображения из /modules/memodule/media/images Но в ответ я получаю 404

  • @rockwill, это просто вариант) Сам я пользуюсь модулем, который собирает всю подключеную статику в контроллерах и модулях, в зависимости от типа файла обрабатывает и отдает мне ссылку на скомпилированый файл.

    Css и LESS сливаются в один файл и минифицируются, js - аналогично.

    Если файл существует и ни один из составляющих не редактировался, то ничего заново не происходит, а просто отдается ссылка.

    Вариантов уйма, просто нужно немного пофантазировать)

    DimkOf Это вариант я так полагаю удобен в случае подключения файлов непосредственно из папки модуля. Я пытался подключить изображения из /modules/memodule/media/images Но в ответ я получаю 404

    В этом случае нужно прописать не static, а media и все будет норм.

    RewriteRule ^modules/.*/media/ - [L]
  • и да, я статику вообще не храню в папке с модулями, по причине, что мне не совсем удобно копаться по всему движку в поисках нужного css, гораздо проще если все лежит в одном месте, в какой нибудь папке а-ля templates

  • DimkOf, не путайте Ваш вариант с тем, что предложил rex. Мой ответ про множественную инициализацию приложения относился к нему:)

  • serieznyi, system/classes/kohana/core.php

  • DimkOf Я считаю что логичнее статические файлы модулей держать в самих модулях.

    С файлами скриптов в принципе все понятно. Главное что бы модуль заработал. Как я уже писал раньше при инициализации модуля генерировать сжатый общий файл стилей/скриптов модуля в публичную директорию(/public/{css,js}) , а в базовом контроллере получать все файлы директории /public/{css,js} и подключать их. И мне такой подход нравится. К тому же не придется каждый раз что то прописывать ручками для определенного модуля.

    А вот что делать с изображениями? Если я указываю путь от /modules/mymodule/media/images в файле вида, то получаю 404.

  • если Вы прописали в htaccess так, как я написал выше, но все равно выдает ошибку - проверьте роуты

  • @rockwill,не отрицаю. Но не постоянно, если вы будете отдавать правильно заголовки кэширования то особой нагрузки не будет. Другой вариант - выносить эти файлы в доступную папку (css, public и прочее). Можно при PRODUCTION режиме копировать эти файлы а в dev использовать то как я говорил - можно даже это автоматизировать. Вариантов море :)

  • Как я уже писал раньше при инициализации модуля генерировать сжатый общий файл стилей/скриптов модуля в публичную директорию(/public/{css,js}) , а в базовом контроллере получать все файлы директории /public/{css,js} и подключать их. И мне такой подход нравится.

    Плохой вариант. Намного логичнее собирать за время выполнения нужные скрипты, например так

    public function action_derp(){
      $this->template->scripts[] = 'path/to/script.js';
    }

    А потом уже все эти скрипты сжимать в конце и размещать на странице. Таким образом не будет загружаться неиспользуемый js/css/

    оофтоп: надеюсь, тут никому не нужно напоминать, что скрипты нужно размещать перед закрывающим тегом

    body

    ? :)

  • Да. И правда плохой вариант сжимать абсолютно все скрипты и стили, а потом подключать их )

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

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

    А изображения я думаю можно просто скопировать в публичную папку. Проверять есть ли в /public/images папка mymodule и если нет, то создать ее и скопировать в нее все изображения. А в файле конфигурации хранить путь к директории изображений.

    Можно ли эти действия производить непосредственно в файле конфигурации модуля? Просто я не совсем понимаю где! Или в файле init.php. Наверное лучше в init.php

    rockwill С чем может быть связана моя ошибка работы модуля о котором вы писали? Пытался поставить последнюю версию Kohana, но у меня страница вообще не грузится. Кажется выдает ошибку 500.

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

    Щито? Зачем добавлять из модуля, не понимаю. На странице возникает необходимость в наоборе скриптов и стилей. По всей цепочке вызовов before->action->after подключаете нужные в нужной последовательности. При чем подключать их из модуля?

    Объясните задачу и каким Вы видите решение,потому как я пока вообще Вас не понимаю.

  • По всей цепочке вызовов before->action->after Я не совсем понимаю что это значит.

    У меня есть Controller_Basic который унаследован от Controller_Basic. В нем указан главный шаблон вида страниц и массивы стилей и скриптов

    $this->template->styles = array( ... );

    Этот массив я использую в шаблоне вида

    <?php foreach($styles as $style) echo HTML::style($style)."\n"; ?> В этом контроллере я указываю все файлы скриптов и стилей которые нужно подключить.

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

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

    Вот так я думаю подключать статику из модулей с использованием модуля kohana-compress. Исправьте если что то не правильно.

    В файле init модуля (надеюсь такие операции можно там проводить) сжать все css и js файлы модуля и сохранить их в директорию /public/css и /public/js Compress::instance()->scripts($scripts, 'global_script.js'); Compress::instance()->styles($stules, 'global_styles.js');

    После чего в контроллере Controller_Basic сканировать директории /public/css, /public/js и подключать все найденные там файлы.

    А вот с изображениями не знаю как. Почти уверен что способ который пытается мне объяснить rockwill более правилен, потому надеюсь на более детальное его описание.

    Я совсем недавно начал изучать Kohana, и вышеуказанный способ подключения статики я нашел на сайте http://kohanaframework.su/ По руководству с этого сайта я и начал писать свой сайт.

  • До сих пор не понимаю почему возникает ошибка ErrorException [ Fatal Error ]: Class 'Compress' not found при использовании $result = Compress::instance()->scripts(array('public/js/jquery/jquery-1.7.2.min.js'), 'out.js');

    Модуль в директории MODPATH, в bootstrap модуль указан, директория для вывода указана.

  • Я все-равно слабо понимаю как Вы работаете со статикой, объясню, как делаю я.

    Допустим,у вас есть куча контроллеров Controller_XXX унаследованых от Controller_Base, который в свою очередь унаследован от Controller_Template.

    в Controller_Base дописываем поля public $scripts = array() и public $styles = array()

    На абсолютно всех страницах сайта используется jquery.js и xxx.css, поэтому подключаем их в базовом классе Controller_Base, для этого существует метод before(), который вызывается до любого action в контроллере. Значит код в Controller_Base такой

    <?php defined('SYSPATH') or die('No direct script access.');

    abstract class Controller_Base extends Controller_Template {

    public $template = 'template';
    
    public  $scripts = array();
    public $styles = array();
    
    public function before(){
        parent::before();
        $this->scripts[] = 'путь/к/твоему/скрипту/jquery.js';
        $this->styles[] = 'путь/к/твоему/стилю/xxx.js';
    }
    

    }

    Теперь у нас в абсолютно любом контроллере, наследованным от Controller_Base есть jquery и xxx.css

    Допустим, во всех action-ах в контроллере Controller_Ololosh нужно еще подключить jquery ui.

    Тогда нужно в этом контроллере аналогичным образом определеить метод before

    public function before(){ parent::before(); $this->scripts[] = 'путь/к/твоему/скрипту/jquery.ui.js'; } Добавление для action мне писать уже просто впадлу, оно аналогичное.

    Потом определи метод after и в нем передавай массив стилей и скриптов в шаблон

    Читайте про before тут - http://kohanaframework.su/starting/base_controller Про after в официальной документации.

    В файле init модуля (надеюсь такие операции можно там проводить) сжать все css и js файлы модуля и сохранить их в директорию /public/css и /public/js Compress::instance()->scripts($scripts, 'global_script.js');
    Compress::instance()->styles($stules, 'global_styles.js');
    
    После чего в контроллере Controller_Basic сканировать директории /public/css, /public/js и подключать все найденные там файлы.

    Пожалуйста, не делайте так. мне потом такие проекты еще поддерживать.

    Если нужен скрипт из модуля, просто возьмите его и подключите

    ...Some controller...some action ..... $this->scripts[] = '/путь/к/скрипту/в/папке/модуля/xxx.js'

  • п.c.

    Если Вы еще раз напишете, что будете собирать в init.php все скрипты модуля, сохранять в папку,а потом искать и подключать все найденные файлы,у меня выпадут волосы и зубы, пожалейте меня :)

  • Суть в том, что на выходе Вы получите 1 (один!) скрипт на страницу, который содержит все (ВСЕ!) подключенные по дороге (в том числе и скрипты из модулей, если такие были подключены)

  • Если нужен скрипт из модуля, просто возьмите его и подключите ...Some controller...some action ..... $this->scripts[] = '/путь/к/скрипту/в/папке/модуля/xxx.js'

    Я хотел бы что бы не приходилось этого делать. К примеру у меня есть модуль авторизации с формой авторизации.

    Я его добавляю в bootstrap.php и теперь мне нужно вывести форму авторизации на всех страницах. Я базовом шаблоне делаю внутренний запрос Request::factory('')->execute();

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

    Я так полагаю Compress::instance()->styles($stules, 'global_styles.js'); мне нужно использовать в parent?

    public function before(){ parent::before(); $scripts = array( ... );

        Compress::instance()->scripts($scripts, 'global_scripts.js');
    
        $this->scripts[] = 'путь/к/твоему/скрипту/global_script.js';
    }</code>
    

    Я все еще не пойму почему не работает модуль. Версия Kohana 3.2. Ошибку писал выше и неоднократно.

  • п.c. Если Вы еще раз напишете, что будете собирать в init.php все скрипты модуля, сохранять в папку,а потом искать и подключать все найденные файлы,у меня выпадут волосы и зубы, пожалейте меня :)

    Все сводится к тому что я не знал что нужно пользоваться after и before. Но тепер знаю и попытаюсь осознать.

    Суть в том, что на выходе Вы получите 1 (один!) скрипт на страницу, который содержит все (ВСЕ!) подключенные по дороге (в том числе и скрипты из модулей, если такие были подключены) Вы наверное имеете в виду что в конце я получу массив со всеми скриптами которые я подключал.

  • Вы наверное имеете в виду что в конце я получу массив со всеми скриптами которые я подключал.

    После вызова Compress Вы получите 1 файл скриптов и 1 файл стиелей.

    Я хотел бы что бы не приходилось этого делать. К примеру у меня есть модуль авторизации с формой авторизации.
    Я его добавляю в bootstrap.php и теперь мне нужно вывести форму авторизации на всех страницах. Я базовом шаблоне делаю внутренний запрос Request::factory('')->execute();

    Это Вы в видеошколе "Kohana от " А" до "Я"" подсмотрели? Плохой вариант. Объяснять почему?

    Вообще kohana это в первую очередь фреймворк. Я понимаю, что Вы хотите делать что-то наподобие автономных плагинов "включил и пользуйся", но в Kohana такие решения обычно кривые или не оптимальные. Модуль в кохана - это что-то типа библиотеки функций. Никаких контроллеров, и тем более статики туда пихать не нужно. Вам нужно выбирать между гибкостью и простотой использования. Если Вам нужна принципиальная такая автономность, то пользуйтесь вышеописанными вариантами c htaccess и забейте на этот модуль, но я бы рекомендовал использовать фреймворк как было задумано.

    Насчет ошибки с модулем, выложите код на гитхаб или в архив,я гляну, как время будет.

  • После вызова Compress Вы получите 1 файл скриптов и 1 файл стилей. Просто вы своем примере не использовали Compress, вот я и подумал что вы говорите о массиве. Тогда в каком месте мне нужно использовать Compress?

    Это Вы в видеошколе "Kohana от " А" до "Я"" подсмотрели? Нет. Просто мне показалось что так было бы удобнее.

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

    То есть такая вот писанина не верна?

    Обратите внимание на строку с внутренним запросом.

    // Базовый контроллер abstract class Controller_Basic extends Controller_Template { public $template = 'main'; public function before() { parent::before(); View::set_global('title', 'mysite2');
    View::set_global('description', 'Самый лучший сайт');

        $this->template->menu_bar = View::factory('parts/menu_bar');
        $this->template->auth_panel = Request::factory('auth2/index')->execute();       
        $this->template->footer = View::factory('parts/footer');        
        // CSS
        $this->template->styles = array(
        'public/css/main.css',
        );      
        // JS
        $this->template->scripts = array(
        'public/js/jquery/jquery-1.7.2.min.js',     
        'public/js/main.js',);
    } 
    

    } // End Common

    Контроллер моего модуля авторизации. class Controller_Auth2 extends Controller { public function before() { View::set_global('auth2_media_path',Kohana::$config->load('auth2.media_path')); $this->a2 = A2::instance('auth2'); $this->a1 = $this->a2->auth(); $this->user = $this->a2->get_user(); } // auth2/media/css/auth2.css public function action_index() { if( $this->user ) { $content = View::factory('user');
    View::set_global('user', $session->get('username')); View::set_global('avatar', "_noavatar"); }
    else{ $content = View::factory('guest'); View::set_global('user', 'Гость'); View::set_global('avatar', '_guest'); }
    $this->response->body($content); } }

  • rockwill Единственный достаточно понятный и не плохо оформленный гид по KOHANA который я смог найти - http://kohanaframework.su Быть может вы подскажете мне какой-то конкретный ресурс или литературу в которой я смогу найти ответы на большинство интересующих меня вопросов, и быть может тогда я перестану задавать глупые вопросы на этом форуме )

  • Так а в чем собственно заключается модуль авторизации? В Kohana есть можудуль авторизации - Auth. Чтобы "вкурить" что значат модули, пробегитесь по коду модулей Auth, ORM.

    Источники знаний:
    -старые темы этого форума
    -www.brotkin.ru
    -официальные гайды и документация.
    -Собственный опыт

  • Я показал лишь фрагмент модуля. Я использую модули A1/A2/ACL. Нашел демо использования этой связки и взял за основу своего. Хочу как минимум добавить views.

    Вы так и не ответили по какой причине нельзя использовать контроллеры в модулях. В стандартных модулях их конечно же нет, но во множестве других они присутствуют. Быть может я их использую не совсем по назначению.

  • Я не сказал, что нельзя, я сказал, что модули для этого не предназначены. Модуль в Kohana - это не плагин! Модуль в kohana - это просто библиотека, при этом максимально абстрактная и ни к чему не привязанная. В Вашем же случае она будет как минимум нести с собой "неуниверсальный" внешний вид.

    Я думаю, поймете со временем, о чем я :)

  • В общем на сколько я понял мою конкретную реализацию нужно хранить непосредственно в application.

  • Ну быть может с переносимостью, как целью написания конкретно моего "модуля" я загнул, но мне казался такой способ разделения вполне удобным )

    Тогда как можно назвать вот такое https://github.com/mixu/useradmin ?

    Ну если все хранить в application, то большинство проблем отпадает само собой.

  • Да полно таких модулей,просто ИМХО если нужна готовая админка, то лучше писать на CMS (Drupal, Wordpress). фреймворк используется для кастомных решений

  • Согласен с @rockwill, в модулях нужно хранить максимально абстрактые "вещи". Судя по вышенаписаному, Вам хочется написать свою джумлу)).

    По-моему, в kohana и так достаточно написано по дефолту, чтобы существенно сократить количество написаного самостоятельно. Меньше букв == меньше гемороя с проектом, и Вам, и тем, кто будет после Вас.

    P.S. есть замечательно написаная cms на kohana http://www.kodicms.ru/, взгляните, может передумаете писать свой велосипед, или хотябы посмотрите как пишут люди с опытом.

    Страница на github https://github.com/butschster/kodicms

    Обсуждение на форуме http://forum.kohanaframework.org/discussion/11027/frogcms-on-kohana

  • @serieznyi, есть такая вещь как Assetic от Криса Уоллсмита (Kris Wallsmith). Это средство используется для управления/подключения статики в Symfony. Советую обратить на него внимание. Ну и на способы подключения самой статики.

    Если вы так желаете хранить статику в модуле - используйте системы построения, которые будут обрабатывать статику по указанному вами алгоритму (сжатие, слитие в один файл - не важно). Такой подход используется в RoR, в Yii, в Simfony. Не думаю что данный вариант плохой :)

    По поводу ресурсов - советую просмотреть код kohana для полного понимания всех принципов ее действия. Это заметно сокращает количество проблем. Советую stackoverflow.com/google.com с запросом типа "assets managemenet howto" или "assets deploing howto" - там очень много чего есть, разрозненно правда.

  • Судя по вышенаписаному, Вам хочется написать свою джумлу)).

    И как вы к этому пришли? Я пытался просто написать свою реализацию модуля авторизации с использованием модулей A1/A2/ACL + мой шаблон вида. Как мне сказали это можно назвать неким плагином. Мне показалось весьма удобно разместить все что относится к авторизации и администрированию пользователей в отдельную логическию единицу сайта. Я неоднократно искал примеры похожего и находил их. Ссылки можете найти выше.

    Я нашел демоверсию использования вышеописанной связки в виде модуля A2ACLdemo который имеет в себе возможность авторизации, регистрации пользователей, возможности публикации комментариев. Я решил переписать этот модуль под себя добавив скользящую панель авторизации/регистрации. Вот чего я хотел добиться. Быть может мое представление о назначении модулей в Kohana несколько искажено, но путь тому виной будут множество "модулей" которые я нашел на github.

  • @serieznyi, прошу прещения, если мои слова задели Вас. Я не имел ввиду ничего плохого. На то он и фреймворк, чтобы вести разработку максимально комфортно без ограничений, которые есть практически в любой cms.

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

    Судя по вышенаписаному, Вам хочется написать свою джумлу)).
    И как вы к этому пришли?

    Вы сами к этому пришли

    Мне показалось весьма удобно разместить все что относится к авторизации и администрированию пользователей в отдельную логическию единицу сайта.

    там все именно так и есть. Я вспоминаю с ужасом моменты, когда мне приходилось делать правки в шаблоне на сайте собраном на joomla. Поиск нужной вьюшки занимал в 5 раз больше времени, чем сами правки в ней. А как страшно выглядят модули со своим дизайном - это вообще отдельная история. Тоже самое с magento - там вьюшки разбросаны по всему движку и пока чтото напишешь... Я от того и пришел к помощи фреймворка, потому что ни одна cms не удовлетворяла меня в плане удобства разработки.

    Но это опять же, это мое субьективное мнение, которое Вы можете прочитать и забыть, или чтото принять во внимание.


    P.S. извиняюсь за оффтоп и разведение полемики

  • 1) Я пишу исключительно для себя. И поддерживать сайт который я пишу буду так же я.

    2) Я как то по прежнему не пойму в какой момент времени я стал писать систему управления контентом?!

    3) Для авторизации и управления правами я взял демо в виду A2ACLdemo. Это демо сделано в виде отдельного модуля. Демо использует модули A1/A2/ACL. Я не уверен что могу вынести все из модуля в application, да и не уверен что это стоит делать. К тому же как вы можете знать в A1/A2/ACL используется ORM с которой я не особо дружу и которая меня немного нервирует. Мне было бы куда проще работать непосредтвенно с SQL, но я не в состоянии самостоятельно написать драйвер.

    Вот по этим причинам у меня есть "модуль" авторизации из-за которого все это и началось.

    А по поводу использования CMS - я не думаю что я смогу добиться нужно мне результата используя CMS.

  • Низкий уровень абстракции и "конструкторная" архитектура характерны для CMS Высокая абстракция характерна для паттернов и фреймворков( которые собственно и я вляются набором паттернов) ИМХО, какое-то хождение по кругу бесполезное

  • Хм ... ну тогда видимо вы правы.

  • Я надеюсь что кто нибуть поможет мне разжевать старый вопрос ) Статика дял каждого из модулей хранится в директории модуля - assets. Далее я вижу 2 способа отдачи статики. 1) Создание символических ссылок на директорию статики модуля в DOCROOT/www/assets/ на которую и ссылаться при использовании статики. (/assets/css/some_module/some_style.css) Этот вариант в данный момент я и использую. Но я недостаточно знаком с архитектурой Unix систем что бы утверждать что это безопастно. Все таки символическая ссылка указывает на директорию которая находится за пределами DOCROOT. Поясните пожалуйста!

    2) Использование способа отдачи статики как в стандартном модуле USerguide. На сколько я понял только первый запрос обрабатывается сервером, а остальные возвращают 304. Правда этот вариант мне кажется несколько накладным в плане производительности т.к. для каждого пользователя хотя бы раз каждый файл обрабатывается php. JS и CSS конечно можно сжать и объединить для уменьшения кол-ва запросов. А вот с изображениями так не поступишь.

  • 3) Модуль статики (static-files), использующий соглашение - все статические файлы должны браться из не-паблика, но быть доступны извне. Для этого они (в первый раз) копируются в DOCROOT (попутно можно их сжимать, версионировать и тд) и в дальнейшем доступны напрямую. При этом, так как файлы обрабатываются фреймворком, доступны все плюшки каскадной ФС.

  • Лирическое отступление. В кохане-из-коробки совершенно ужасно обстоит дело с такими бытовыми вещами как темплейты и modules-friendly вывод статики (например, модуль типа kohana-static-files, включенный в стандартную комплектацию фреймворка наряду с auth и т.п). Точнее, этого просто нет. И сверху вишенка в виде неюзабельного класса Controller_Template, где свойство $template меняет свой тип в процессе выполнения (жутчайший WTF и говнокодинг). Какие там неймспейсы, кстати, пока в коде такое ?

    Имхо, в первом способе ты перемудрил. Зачем статику выносить за докрут ? Есть два варианта - или у тебя код фреймворка находится в docroot (в кохане по дефолту) или ты переписал index.php и virtualhost в апаче так, что у тебя docroot находится, например, в папке public. В первом варианте папки модулей доступны веб-серверу и можно размещать css и js прямо в них, ставя во вьюхах прямые на них ссылки. Во втором - папки модулей недоступны, css и js, который в них есть, надо при изменении копировать специальный модулем (каким, кстати?) куда-нибудь в public, как советует biakaveron, и им же формировать ссылки для вьюх.

    Мне кажется, хранение файлов фреймворка ниже докрута переоценено и влечет за собой больше проблем чем решений. Есть, конечно, индивидуальные особенности типа xml-конфигов, sqlite-баз и прочего, но в остальном - главное, defined('SYSPATH') or die('No direct script access.'); не забывать писать в начале - и все будет ок.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion