Можливо, вас втомили постійні ігрища з wf_checkGet()/wf_CheckPost, постійні перевірки типу isset або прямі звернення до $_GET/$_POST у пошуках даних, що прилетіли до вас з URL або з ваших форм. Рівень абстракції у вигляді класу ubRouting має допомогти вам розв'язати ці проблеми, і дати більше свободи в написанні вашого чудового коду.

Ні! Ніхто вас ні в чому не обмежує і не примушує використовувати будь-що таке специфічне у вашому новому коді, і тим паче навіть не натякає, що ви маєте переписати весь ваш старий код з використанням цього об'єкта. Можливо, вам просто сподобається, який вигляд може мати ваш код без прямих звернень до суперглобальних масивів.

Чому з маленької літери, а не як пише біблія в UpperCamelCase? Тому, що оскільки всі методи класу static і можуть бути викликані за допомогою :: безпосередньо з класу, без створення об'єкта, це зроблено для того, щоб вам потрібно було менше шифрувати під час пошуку його імені в автокомпліті, якщо у вашій IDE він case sensitive. Знову ж таки, очікуване UbillingRouting було б занадто довгим, а UbRouting має трохи стрьомнуватий вигляд сам по собі. Також іменування UbillingSomething перекривалося б з іншими наявними класами і вони б плуталися в автокомпліті постійно під ногами. Тому вирішено було скоротити цей рух тіла до набору трьох символів виду ubr/ubR перед тим, як можна буде тицьнути Enter.
У будь-якому разі вам ніхто не забороняє зробити щось на кшталт

$routing=new ubRouting();

і використовувати це з таким іменуванням як вам завгодно.

До речі так. Це все доступно починаючи з Ubilling 1.0.0 rev 6925.

Якщо ви вже раніше розробляли код для Ubilling або хоча б вдумливо його вивчали, то подібні конструкції мають бути для вас дуже знайомими:

if (wf_CheckGet(array('test'))) {
    deb('gotcha!');
}

Зрозуміло, так? А як же можна переписати цей самий код за допомогою ubRouting, щоб було красиво і цікаво? Ну давайте якось так для початку:

if (ubRouting::checkGet(array('test'))) {
    deb('gotcha!');
}

Стоп, але ми ж перевіряємо на прилітання всього одну змінну, навіщо описувати її в array і таке інше. Крім того, ми знаємо, що вона буде не порожньою. Окей, давайте ще простіше:

if (ubRouting::get('test')) {
   deb('gotcha!');
}

А взагалі правильним варіантом може бути перевірка у вигляді

if (ubRouting::checkGet('test')) {
   deb('gotcha!');
}

Так, тепер ми можемо перевіряти як масив параметрів aka змінних, так і одиночний, описавши його як string.

А якщо ми знаємо, що ця або інші змінні, які ми хочемо отримати, можуть бути порожніми або мати значення 0, але все одно нам треба якось відреагувати на їхню появу? Раніше ми брутально використовували для цього щось типу if (isset($_GET['test']) AND isset($_GET['another']])) та інший бардак. Тепер можна зробити красиво? Так:

if (ubRouting::checkGet(array('test', 'another'), false)) {
    deb('GOTCHA!');
}

З чого, власне, очевидно, що встановивши другий параметр $ignoreEmpty в false, ми будемо задовольнятися самим фактом наявності цих змінних незалежно від їхнього вмісту. Природно таким чином, ми отримаємо GOTCHA! як реакцію на URL виду ?module=ourmodule&test=&another=0. Якщо ж ми хочемо бути впевнені, що нам прилетіло щось на кшталт ?module=ourmodule&test=notempty&another=1, то нам слід використовувати ubRouting::checkGet як

// За замовчуванням $ignoreEmpty має значення true, 
// хоча можете і вказувати його безпосередньо як ubRouting::checkGet(array('test', 'another'),true)
if (ubRouting::checkGet(array('test', 'another'))) { 
    deb('GOTCHA!');
}

Окей, це все зрозуміло. З GET розібралися. А що якщо ми хочемо перевірити факт прильоту даних з POST форми, скажімо такої як нижче?

$inputs= wf_TextInput('newname', __('Name'), '', true, 10);
$inputs.= wf_TextInput('newsize', __('Size'), '', true, 10);
$inputs.= wf_Submit(__('Create'));
$form= wf_Form('', 'POST', $inputs, 'glamour');
deb($form);

Ви не повірите. Все повністю ідентично. Воно ж зроблено для вашої зручності. Знали? ;)

if (ubRouting::checkPost(array('newname','newsize'))) {
    deb('Not empty form data received');
}

(так, ми очікуємо обидва поля не порожніми)

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

if (ubRouting::checkPost(array('newname','newsize'))) {
    $newName= ubRouting::post('newname');
    $newSize= ubRouting::post('newsize');
    show_window(__('Form data received'), $newName.' + '.$newSize);
}

и да, получать значения из GET мы можем точно так же, например так:

$variableName=ubRouting::get('another');

Кстати, в случае, если вы пытаетесь получить переменную при помощи ::get или ::post а ее нету (да, она тупо не isset) оба этих метода будут честно возвращать false. Не забываем, что для таких проверок следует использовать сравнение типа !==false а не прямой if (!ubRouting::get('somevar')) так как он будет срабатывать как в случае пустой переменной так и ее несуществования в принципе.

Также вы можете фильтровать данные прямо в процессе их получения, налету. Допустим, мы хотим быть уверенными, что в newname у нас будут буковки, циферки и вообще что угодно но отфильтрованое для записи в MySQL а в newsize - только циферки.

if (ubRouting::checkPost(array('newname','newsize'))) {
    $newName= ubRouting::post('newname','mres');
    $newSize= ubRouting::post('newsize','int');
    show_window(__('Form data received'), $newName.' + '.$newSize);
}

Да. Это управляется вторым параметром методов get/post. Их возможные значения:

• raw (по-умолчанию) - данные будут возвращены “как есть” без какой либо предварительной обработки
• int - из данных будет отфильтровано вообще все, кроме циферок в диапазоне [0-9]
• mres - для данных будет предварительно запущена функция mysql_real_escape_string()
• callback - для данных будет запущена функция с именем указанным в третьем параметре собственно $callback.
• fi - данные будут пропущены через filter.

Пример того, как вы можете использовать коллбэк функции:

$newAnother= ubRouting::post('newanother','callback','vf');

Да. Точно также вы можете получать и фильтровать данные из GET переменных:

$newAnother= ubRouting::get('newanother','int');

Также для обоих методов ::get и ::post вы можете указывать множественные коллбэк функции, просто оформив их список в виде массива. Например так:

$filters = array('strip_tags', 'mysql_real_escape_string');
deb(ubRouting::get('another', 'callback', $filters));

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

$anotherData=ubRouting::post('another', 'callback', array('strip_tags', 'mysql_real_escape_string')));

А что если вам нужны одни и те же данные и в сыром виде и отфильтрованные? Да, вы без проблем можете точно так-же вызывать из объекта методы фильтрации с теми же параметрами, например так:

 $rawData= ubRouting::get('another');
 $filteredData=ubRouting::filters($rawData, 'callback', array('strip_tags','mysql_real_escape_string'));

Также вы можете использовать штатные механики filter указав режим фильтрования как fi (filter input):

$data = ubRouting::get('another','fi',FILTER_SANITIZE_NUMBER_INT);

Возможно вам захочется делать при помощи этого же объекта какую-то внутреннюю навигацию. Для этого есть короткий и удобный метод nav($url) который вы можете использовать как-то так:

ubRouting::nav('?module=yourmodule&somevar=1');

Да, это всего навсего просто удобный и короткий алиас для rcms_redirect($url)

Также можно получать копии суперглобальных массивов $_GET и $_POST целиком, при помощи соответствующих методов.

$postData= ubRouting::rawPost();
$getData= ubRouting::rawGet();

При попытках использования недопустимых $filtering или неверном указании коллбек-функции в ::get/::post методах а также пустых параметрах для ::check методов, будут выброшены соответствующие исключения:

• EX_WRONG_FILTERING_MODE - несуществующий режим фильтрования данных.
• EX_CALLBACK_NOT_DEFINED - коллбэк функция не существует/не объявлена.
• EX_CALLBACK_EMPTY - пустое имя коллбэк функции.
• EX_FILTER_EMPTY - пустое имя фильтра.
• EX_PARAMS_EMPTY - пустое имя или массив имен переменных для check

Вы вообще можете использовать это как угодно и обращаться к этому как угодно и удобно лично вам, в своей практической деятельности. Хоть так:

class MyClassName {
 
    /**
     * System routing object instance placeholder
     *
     * @var object
     */
    protected $routing = '';
 
    public function __construct() {
        $this->initRouting();
    }
 
    /**
     * Creates new protected routing object instance for further usage
     * 
     * @return void
     */
    protected function initRouting() {
        $this->routing = new ubRouting();
    }
 
 
    /**
     * Returns current system module name
     * 
     * @return string
     */
    public function getModuleName() {
        $result='';
        if ($this->routing->checkGet(array('module'))) {
            $this->routing->get('module');
        }
        return($result);
    }
 
 
    /**
     * Returns all available POST variables as array
     * 
     * @return array
     */
    public function getPostVars() {
        return(ubRouting::rawPost());    
    }
 
    /**
     * Returns all available GET variables as array
     * 
     * @return array
     */
    public function getGetVars() {
        return($this->routing->rawGet());
    }
 
}
 
$obj = new MyClassName();
show_window(__('Current module name'),$obj->getModuleName());
debarr($obj->getPostVars());
debarr($obj->getGetVars());

И вообще делайте что хотите. Хотите вызывайте методы при помощи paamayim nekudotayim (::) прямо из объекта ubRouting. Хотите создавайте его экземпляры и обращайтесь к методам при помощи - >, хотите наследуйте и расширяйте функционал как вам угодно.