Можливо, вас втомили постійні ігрища з 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. Хочете створюйте його екземпляри і звертайтеся до методів за допомогою - >, хочете успадковуйте і розширюйте функціонал як вам завгодно.