Как стать автором
Обновить

Комментарии 13

Там же можно создать папку model если вы планируете использовать ORM
classes/model имеет смысл создавать только, если данный модуль будет иметь собственные модели (собственно там они и должны храниться). Использование ORM само по себе не делает наличие данной папки обязательной, более того — модели могут быть использованы и без участия ORM ;)
НЛО прилетело и опубликовало эту надпись здесь
Добавил PHP в теги.
Думаю этой диаграммы очень не хватает, она как раз показывает порядок и приоритеты при использовании модулей.
KO3
Да, кстати, полезная диаграмма.

Еще и для того, чтобы избежать случайных накладок — мне кажется и есть смысл называть внутренние файлы модуля так же, как и сам модуль. Если, конечно, не ставиться другой цели.
ИМХО, более показательным будет передача в конструктор не значения $text, а конфигурации (массив или имя настроек в файле config/tester.php). В таком случае сперва конструктор загрузит дефолтные настройки, затем поверх них скопирует переданные. А сам текст уже передавать через специальный метод или магический __set(). Такая схема мне представляется более грамотной. Хотя бы потому, что так можно создать кучу элементов с одинаковой разметкой без лишних усилий. В таком случае вообще напрашивается хранение созданных объектов в статическом свойстве $_instances, а factory() будет к нему обращаться, и только в случае отсутствия запрашиваемой конфигурации — создавать новый через конструктор.

Да, и маршрут создавать необязательно, если УРЛ подходит под дефолтную схему приложения (controller/method/id).
ИМХО, более показательным будет передача в конструктор не значения $text, а конфигурации (массив или имя настроек в файле config/tester.php). В таком случае сперва конструктор загрузит дефолтные настройки, затем поверх них скопирует переданные. А сам текст уже передавать через специальный метод или магический __set().


Изначально подобный вариант и намечался.
Но потом сознательно было убрано всё, без чего можно обойтись, и оставлен только самый простой скелет модуля. Главная задача — сразу «въехать» в то, как собственно написать модуль для Ko3. Остально добавить будет не проблемным.
Жду еще статей о Kohana 3 =) Было бы интересно почитать, а то документации совсем не хватает
А зачем единственный конфиг-файл класть еще и в папку? Больше папок — солиднее фреймворк? :)
Это правило фреймворка. Единообразие структуры модулей позволяет переписывать конфигурационные файлы в application/config/ при необходимости.

Чуть выше в комментарии не зря привели диаграмму приоритетов.
Кстати, для описания маршрутов модуля не обязательно править bootstrap.php. В корневом каталоге модуля, где содержатся папки config, views, classes, достаточно создать файл init.php

/modules/ourmodule/init.php
<?php defined('SYSPATH') or die('No direct script access.');
Route::set('module', 'module(/<action>)')
    ->defaults(array(
        'controller' => 'module',
        'action'     => 'index',
    ));
Немного не верно написали в статье!
Вместо
$this->fontColor = $this->config['fontColor'];
$this->fontSize = $this->config['fontSize'];
Надо писать
$this->fontColor = $this->config['color'];
$this->fontSize = $this->config['size'];
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории