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