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
Разбиение сайта на модули
  • Не так давно мне пришла эта мысль в голову. Погуглив я нашел только вот эту тему http://forum.kohanaframework.org/discussion/11273/raskidyvat-li-sayt-po-modulyam/p1 Но аргументы представленные в ней не привели меня к конечному мнению. В данный момент у меня достаточно много файлов в директории appliсation и это вызывает сложности в поиске того или иного функционала. Я думал что если вынести логические группы файлов в отдельные модули помогло бы легче ориентироваться в коде. Помнится что можно создать отдельную папку для модулей (поправьте меня если я ошибаюсь) для логического разбиения и назвать ее например Site или Structure. вынести туда частную реализацию, в папке modules оставить все остальные МОДУЛИ, а в папке application - переопределения стандартных классов Kohana, классов модулей.

    Но меня интересует может ли это негативно сказаться на работе сайте и почему?

    P.S. Эта идея пришла мне в голову после того как я ближе познакомился с Drupal и его модульной системой. Она оказалась очень интересной и мне стало жаль что в Kohana вся логика свалена в одну кучу. P.S.S. Конечно же можно ве это сгруппировать по папкам в самом application, но все роуты все равно останутся в bootstrap огромной кучей.

  • что в Kohana вся логика свалена в одну кучу.

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

    мои идеи по этому поводу http://forum.kohanaframework.su/viewtopic.php?f=38&t=657

    негативного тут ничего нет, так все серьезные приложения и строятся.

  • Интересная структура. Правда Fronend в Web как мне казалось это CSS3, JS, Jquery. В общем все что работает на стороне клиента. Но пусть я это смог переосмыслить. Но тут другой момент. Есть у меня в Frontend работа с пользователем и нужна синхронизация демоном пользовательских данных 1-2 раза в сутки с другим сервисом. Выходит я разобью логику которая работает с пользовательскими данными между Frontend и CLI. А иначе все это могло быть в одной директории User в которой была бы директори CLI. Хотя может я просто заморачиваюсь. Но структура вашей CMS мне куда больше понятна и приятна чем, например, в KodiCMS

    P.S. Так же было бы не плохо, если возможно, хранить статику в той же директории (User). А отдавать только сжатый, закешированный файл.

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

    /kohana -- application/ ********************* Переопределяем классы модулeй. Фактически это частная реализация модуля ----- A2 ---------- classes --------------- A2 -- modules ********************* Модули ----- A1 ----- A2 ----- ACL ----- ORM ----- Minion
    -- structure/ ********************* Группировка частной реализациия ресурса ----- user ********************* "Модуль - Пользовател" ---------- classes --------------- CLI --------------- contoller ----- config ----- vendor --------------- css --------------- js --------------- img ----- init.php ----- market ----- rating ----- chat /www ********************* точка входа, статика, кеш ----- media ---------- cache ---------- css --------------- user_css_compressed.css ----------js --------------- user_js_compressed.js ---------- img --------------- ну изображения я думаю придется просто скопировать единожды. Хотя это мне не нравится

  • Правда Fronend в Web как мне казалось это CSS3, JS, Jquery.

    обычно такая директория называется assets

    Ты не до конца прочел\понял то, что я написал в том топике.

  • Прочел я фрагментами. Внимательно просмотрел только структуру файлов. ...(widget/news, page/news , 'ajax/news') И снова мне кажется что news/widget, news/ajax, news/page куда логичнее. Хотя это наверное зависит от личного восприятия.

  • @serieznyi

    Независимые части кода, разместим в отдельных модулях: пагинатор(paginator), капча(captcha) и т.д.

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

  • В application - переопределения классов модулей и конфигурационные файлы. Ведь как раз все так и делают. Просто разница в том что значительная часть кода уйдет в новую группу - structure.

    Я не буду утверждать что так нужно, просто мое предпочтение ведет меня к этому. Я пока что не уверен как лучше сделать.

    "Смысла загружать неиспользуемый функционал нет."

    А как это понимать?

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

  • WinterSilence, как ты понимаешь твой вариант структуры проекта меня не устраивает. Думаю тебя это мало волнует :) Но учитывая то что ты лучше в этом разбираешься то, я не отказался бы от твоих советов в определенных вопросах. Вот такую структуру проекта(-ов) я бы хотел реализовать. / --------- common ------------------ kohana 3.3 --------------------------- system
    --------------------------- application --------------------------- modules ------------------------------------ ACL ------------------------------------ A1 ------------------------------------ A2 ------------------------------------ ORM ------------------------------------ Minion --------- mysite.com --------------------------- production --------------------------- developer ------------------------------------ site --------------------------------------------- main --------------------------------------------- admin --------------------------------------------- user ------------------------------------------------------ view ------------------------------------------------------ config ------------------------------------------------------ classes --------------------------------------------------------------- Controller ------------------------------------------------------------------------ List ------------------------------------------------------------------------ Read ------------------------------------------------------------------------ Save ------------------------------------------------------------------------ SLI --------------------------------------------------------------- Model --------------------------------------------- market --------------------------------------------- auth2 ------------------------------------ www --------------------------------------------- index.php --------------------------------------------- media ------------------------------------------------------ css ------------------------------------------------------ js ------------------------------------------------------ img ------------------------------------------------------ font ------------------------------------ forum
    Предположим у меня имеется VPS на котором могут быть более 1-го сайта. common - там будут находится системные файлы kohana. mysite.com - корень сайта. Так как я не знаком с тем как продолжать разработку сайта после его запуска, я прошуршал сеть и понял(надеюсь что правильно) что dev версия - паралельная директоря prod версии в которую я буду вносить изменения, и которую в процессе обновления буду копировать в prod. Далее уже идут логические разделы сайта.

    В данной структуре application хранит только переопределенные классы модулей (modules). Ну например мне захотелось добавить хранение прав доступа/полей/действий/разрешений в базе данных

    Папка site в данном случае является той же modules, но с частными реализациями разделов. Наверное это уже что то ближе к плагину.

    У меня сразу возникают вопросы: 1) Как мне правильно подключить файлы из site? Так? - Добавить MODPATH2 указав путь к sites. - Передать список разделов(на аналог модулей) в Kohana::modules после добавления самих модулей. Наверное написать аналогичный метод, но для моих разделов.

    2) Хотелось бы всю статику относящуюся к логическому разделу хранить непосредственно в нем, а отдавать пользователю объединенную закешированную версию из media директории В данный момент моя статика лежит в www/media откуда я ее беру, группирую, кеширую, записываю и оттуда же отдаю.

    3) Что в моем решении кажется тебе не правильным ? :)

    И заранее благодарю!

    P.S. Мнению любого другого участника форума будет встречено так же с радостью! :)

  • Добавить MODPATH2 указав путь к sites. - проще всего добавить его в объявлении модулей. зачем на сервере dev версия? сложно как-то и запутанно, какие плюсы у такого подхода?

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

    "проще всего добавить его в объявлении модулей" А как правильно продолжать разработку запущенного ресурса с его последующим обновлением?

    "проще всего добавить его в объявлении модулей." Конечно можно, но это не совсем и модули. Модули - абстракция, у меня - конкретная реализация. Мне просто кажется глупо их путать

    Запутанно потому что придумали не вы. Для меня все как раз очень даже понятно :) Можете посмотреть на это с другой стороны. В данном подходе самое "странное", это вынесение основной части сайта в еще одну директорию модулей. В целом sites можно заменить application application --------- classes ------------------User ---------------------------List --------------------------- Read --------------------------- Save --------------------------- CLI ------------------ Market --------- config ------------------ user ------------------ market --------- views ------------------ user ------------------ market Но меня не устраивает такой способ агрегации т.к. файлы разделов разбросаны по разным директориям. Мне же хотелось бы хранить все что связанно с разделом в одной директории. А вот ранее описанный вариант очень даже мне нравится.

  • Плюсы в том что он мне кажется более логичным. - отличный аргумент! ну раз напридумывал так заодно сообрази как реализовать)

  • Ну так проблем с реализацией не вижу. Потому и спрашиваю - быть может ты что-то видишь. Ну раз нет, так нет!

Howdy, Stranger!

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

In this Discussion