Jump to content

Модификатор перевода текста


Recommended Posts

Системные уведомления в симпле сделаны на мой взгляд очень топорно.
К примеру имеем такой набор условий:

{if $message_error=='url_exists'}Товар с таким адресом уже существует{elseif $message_error=='empty_name'}Введите название{else}{$message_error|escape}{/if}

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

Я решил это упросить и привёл к такому виду:

{if $error}<div class="alert alert-danger"><i class="fa fa-exclamation-triangle"></i>{$error|translate}</div>{/if}


Собственно и сам модификатор выглядит вот так:

public function translate_modifier($text){	$translations = array(		'empty_email'       => 'Вы не ввели e-mail',		'empty_password'    => 'Вы не ввели пароль',		'user_disabled'     => 'Пользователь не активирован',		'user_not_found'    => 'Пользователь не найден',		'login_incorrect'   => 'Не верный логин или пароль'	);		if(is_null($translations[$text]))	{		$translate = $text;	}	else	{		$translate = $translations[$text];	}		return $translate;}


Ниже прикрепил модифицированный файл, заменить нужно api/Design.php предварительно создав бекап заменяемого файла.

Меня интересует мнение разработчиков в том числе Пикусова, кто что скажет на этот счёт?

Design.rar

Design.rar

Link to post
Share on other sites

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

 

А если уж делать такое, то сюда же надо добавлять и сообщение об успехе, а не только об ошибках. То есть чтоб обрабатывались как минимум сообщения трех типов:

1. Успех, ничего не требуется,

2. Неуспех, требуется действия от пользователя,

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

 

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

Edited by ЯкЦинДрак
Link to post
Share on other sites

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

И чем плохо сделать доп. вызов функции через смарти? Если речь о экономии, то это экономия на спичках.

А если уж делать такое, то сюда же надо добавлять и сообщение об успехе, а не только об ошибках. То есть чтоб обрабатывались как минимум сообщения трех типов:

1. Успех, ничего не требуется,

2. Неуспех, требуется действия от пользователя,

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

Во первых модификатор предназначен для подмены текста error => ошибка, во вторых обрабатывать ошибки должен контроллер\модуль но никак не модификатор, в третьих в симпле нет трёх типов сообщение\уведомлений.

Тексты для успеха нужно же конечно дописать, там далеко не весь список.

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

Конечно же это оффтопик но все же чем плох метод выбора категорий?
Link to post
Share on other sites

Конечно же это оффтопик но все же чем плох метод выбора категорий?

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

В частности, вытаскивает всегда все описания.

А на какой странице сайта или админки нужны ВСЕ до одного описания категорий?

И этот момент далеко не единственный...

Link to post
Share on other sites

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

В частности, вытаскивает всегда все описания.

А на какой странице сайта или админки нужны ВСЕ до одного описания категорий?

И этот момент далеко не единственный...

Я не силён в оптимизации SQL запросов, но чем плохо выбирать все ячейки сразу?

Вон Пикусов писал как-то про модульность что если он ее все же сделает, то все запросы будут выбирать сразу все поля, к примеру:

select * from s_categories
Link to post
Share on other sites

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

В языке SQL не зря ведь предусмотрен выбор избранных полей.

Link to post
Share on other sites

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

В языке SQL не зря ведь предусмотрен выбор избранных полей.

Было бы куда понятней если привели это в цифрах, а не продуктах.
Link to post
Share on other sites

Если непонятно на словах, попробуйте на практике.

Купите на семью какой-нибудь клубники килограммов 200 сразу, и сложите в квартире, лучше на кухне поближе к плите.

Если через день-другой идея по-прежнему не будет понятна, повторите опыт, но купив раз в 10 больше.

 

Или, когда будете покупать ребенку одежду к школе, то для экономии времени не примеряйте ничего в магазине, а купите сразу все варианты товаров - по одному каждого размера и цвета - а дома разберетесь...

 

Случай из практики. Сайтовладелец жаловался, что сайт стал медленно работать. Оказалось, у него накопилось около 1000 категорий, из них активных менее половины. Возникали тормоза немалые - 5-10 сек на страницу.

А когда поправили запросы, все вошло в норму...

 

И менее колоритных подобных случаев было около десятка. Причина все в том же - в недостаточной продуманности архитектуры автором CMS.

Link to post
Share on other sites

Тоже как-то где-то писал что этот метод совершенно не эффективен. 

Писать кучу if else, как в допотопном веке...

 

Должен быть единый файл, допустим ru.php, в формате:

; Языковые настройки
; Русский язык

error           = 'Ошибка'
saved           = 'Сохранено'
removed         = 'Удалено'
added           = 'Создано'
updated         = 'Обновлено'
exists          = 'Такой объект уже существует'
no_permission   = 'Установите права на запись в папку'
upload_error    = 'Ошибка загрузки'

...

Читаться так-же как и config.php, примерно так:

<?php

require_once('Simpla.php');

class Lang extends Simpla
{
	// Языковой файл
	public $config_file = 'config/ru.php';

	private $vars = array();
	
	// В конструкторе записываем настройки файла в переменные этого класса
	public function __construct()
	{		
		// Читаем настройки из дефолтного файла
		$ini = parse_ini_file(dirname(dirname(__FILE__)).'/'.$this->config_file);
		// Записываем настройку как переменную класса
		foreach($ini as $var=>$value)
			$this->vars[$var] = $value;
	}

	// Возвращаем переменную языкового файла
	public function __get($name)
	{
		if(isset($this->vars[$name]))
			return $this->vars[$name];
		else
			return null;
	}
}

При этом ошибки выводить как массив с ключами: ($messages['success'][] = ['key' => 'updated'];)

// Не допустить одинаковые URL материалов и нельзя создавать материалы с пустым названием
                    if(($a = $this->article->get_article($article->url)) && $a->id!=$article->id)
                    {
                        $messages['error'][] = ['key' => 'url_exists'];
                    }
                    elseif(!$article->name)
                    {
                        $messages['error'][] = ['key' => 'name_empty'];
                    }
                    else
                    {
                        if(empty($article->id))
                        {
                            $article->id = $this->article->add_article($article);
                            $article = $this->article->get_article($article->id);
                            $messages['success'][] = ['key' => 'added'];
                        }
                        else
                        {
                            $this->article->update_article($article->id, $article);
                            $article = $this->article->get_article($article->id);
                            $messages['success'][] = ['key' => 'updated'];
                        }
                    }

 

и самое главное, ошибки выводить в TPL как:

{if $messages.success}
    {foreach $messages.success as $message}
    <div class="info success clear">
        <i class="icon-check"></i>
        <span>{$lang->$message.key}</span>
        {if $message.data}
            <div class="info__data">{$message.data}</div>
        {/if}
    </div>
    {/foreach}
{/if}

+ возможность формировать массив как $messages['success'][] = ['key' => 'updated', 'data' => 'Тут допустим техническая информация'];

 

 

По идее должно быть одно API для вывода уведомлений в шаблон, такое-же как и Notify.php (для отправки почты).

 

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

 

Похожая система допустим в более продвинутом (с точки зрения ООП) движке ImageCMS.

Link to post
Share on other sites

В Simpla всего 8 файлов шаблонов с выводом  ошибки типа

 

        {if $error == 'empty_name'}Введите имя{/if}
        {if $error == 'empty_email'}Введите email{/if}
        {if $error == 'captcha'}Капча введена неверно{/if}
 

А предлагаемый Вами код даже по размерам (не говоря уже о сложности) существенно превосходит текущую организацию.

А если еще придется формировать данные об ошибках как массив, то и в обработчиках переделывать надо.

 

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

 

Если это ради того, чтобы организовывать вывод ошибок в разных языках, то это бег впереди паровоза. При существующих темпах обновления Simpla придет к языковой организации разве что в будущих веках.

 

Про модульность говорится давно, но дальше разговоров пока не идет.

Link to post
Share on other sites
×
×
  • Create New...