Автор Тема: Доработка basemodule.class, install, рендеринг  (Прочитано 3622 раз)

0 Пользователей и 1 Гость просматривают эту тему.

spirit13

  • Гость
Опять я со своими мыслями и амбициями тут вылез... Не пинайте! Просто когда я работаю над сантой, то мое присутствие тут оживляется.
Так вот сегодня я со следующими идеями и предложениями.
Время движется вперед и php развивается? А в существующих модулях появляются ошибки типа strict standarts. Решаем.
1. Install.php модулей пора обновить. на такой код:
    function install($id_module, $reinsatall = false){
        parent::install($id_module, $reinsatall);
...
    function install_children($id_module, $reinsatall = false){
...
Ну и создание экземпляра тоже изменяем на:
new module_install('module');

2. Многие модули(почти все) делают такое
$tpl = 'module/example/templates_user/';
$tpl_admin = 'module/example/templates_admin/';
а потом вот так
$kernel->pub_template_parse($this->templates_admin_prefix.'date_picker.html')и это хоршо, что так, а не $kernel->pub_template_parse('module/example/templates_admin/date_picker.html')Т.е. все все модули делают проперти, в которой определяют путь к админским и пользовательским шабонам, но никто не делает этого в .... ДА! базовом модуле! А я делаю и вам советую вот так:
abstract class BaseModule{
    public $path_templates_admin ='';
    public $path_templates_user ='';
    public static $language = array();  //новая мультиязычность

    public function __construct(){
        global $kernel;
        $il = array();
        $this->path_templates_admin = 'modules/'.get_called_class().'/templates_admin/';
        $this->path_templates_user = 'modules/'.get_called_class().'/templates_user/';
        //новая мультиязычность
        require_once('modules/'.get_called_class().'/lang/'.$kernel->priv_langauge_current_get().'.php');
        self::$language = $il;
        unset($il);
    }

и теперь в модуле можно делать так:
$kernel->pub_template_parse($this->path_templates_admin.'date_picker.html')Но мне этого было мало и я подумал об доп обертке....(ну не совсем так, я думаю об еще большей оптимизации рендеринга шаблонов) и сделал так (без всяких проверок и т.д.):
    public function pub_template_parse_admin($filename, $createlevel = false){
        global $kernel;
        return $kernel->pub_template_parse($this->path_templates_user.$filename, $createlevel);
    }

    public function pub_template_parse_user($filename, $createlevel = false){
        global $kernel;
        return $kernel->pub_template_parse($this->path_templates_user.$filename, $createlevel);
    }
и я могу в модуле теперь делать вот так
$this->pub_template_parse_user('date_picker.html')
Зачем лишний вызов функции? Ну это для дальнейших моих мыслей... А так он абсолютно не нужен, можно и примером выше обойтись...

3. Вот тут меня разрывает несколько мыслей. Уже давно разрывает) И я периодически экспериментирую с движком.
3.1. Это недо MVC. Почему я считаю недо?
3.1.1. Модель я не трогаю(ее по сути и нет).
3.1.2. Представление - вроде бы есть (наши шаблоны html)
3.1.3. И вот тут контролллер - а он то и контроллер и view! Когда разрабатывается модуль (например, каталог), то сложно отделять где контролллер, а где представление - везде что-то строится и отрисовывается... Было неудобно работать.
3.1.4. Пока не думал над вопросом создания классов view для модуля, в котором были бы только функции по отрисовке, зато придумал другой рендеринг шаблона и попробовал его реализовать(так же был затронут механизм мультиязычности, который меня тоже волновал... может я параноик и надо проверить что лучше: лишний раз в базу за меткой лезть или обратиться к файлу).

Рендеринг(код просто для теста и не претендует на идеальность, просто концепция). Базовый модуль.
    protected function render($tpl_type, $template, $data) {
        $output = '';
        switch ($tpl_type){
            case 'user' :
                $template = $this->path_templates_user . $template;
                break;
            case 'admin':
                $template = $this->path_templates_admin . $template;

        }
        if (file_exists($template)) {
            extract($data);

            ob_start();

            require($template);

            $output = ob_get_contents();

            ob_end_clean();

            return $output;
        } else {
            trigger_error('Error: Could not load template ' . $template . '!');
            exit();
        }
    }
Рендеринг модуль:
$html .= $this->render('admin','template_admin.html', $data);
А шаблон - это просто кусок html со вставками php...

Ввиду этих изменений ... изменил мультиязычность.
Базовый модуль
    public static function getLanguageLabel($label){
        return isset(self::$language[$label]) ? self::$language[$label] : $label;
    }

шаблон выглядит так:
<div>
    <?php echo self::getLanguageLabel('label_pub_show_menu'); ?>
</div>

либо если мержить $data с массивом меток.
<div>
    <?php echo $label_pub_show_menu?>
</div>

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

Получилось много, но надеюсь концепция ясна. Как вам?
Прикрепляю тестовый basemodule.

sanchez

  • Гость
Re: Доработка basemodule.class, install, рендеринг
« Ответ #1 : 22 ноября 2012, 00:09:29 »
мысли хорошие, но есть нюансы
например get_called_class - это с php 5.3, а мы пока хотим, чтобы у нас работало и на 5.2
а если поменять шаблоны, то многим не понравится это - люди привыкли, проекты будет просто так не обновить на новую версию движка с новыми шаблонами

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

spirit13

  • Гость
Re: Доработка basemodule.class, install, рендеринг
« Ответ #2 : 22 ноября 2012, 11:08:49 »
мысли хорошие, но есть нюансы
например get_called_class - это с php 5.3, а мы пока хотим, чтобы у нас работало и на 5.2
а если поменять шаблоны, то многим не понравится это - люди привыкли, проекты будет просто так не обновить на новую версию движка с новыми шаблонами

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

Ну вообще да, многие модули не наследуются от базового... Шаблоны, конечно, менять не надо, это капец будет) Но вот я задумался о создании фалов .model для классов... ладно, будем дальше экспериментировать.