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