организация параметров форм

Baranov_Dron

Новичок
организация параметров форм

Собственно думаю как организовать так, чтобы параметры форм были гибкие.
И легко изменяемые.
Параметры для текстовых полей это: может ли быть пустым, длина, разрешённые символы.
Для фоток: минимальное разрешение, размер, формат фотографии(jpg, bmp)
и тд....
Проблема такова, что ведь для разных разделов сайта разные параметры.
Попробывал сделать общий файл констант типа
PHP:
define("BOARD_FORM_COLOR","цвет|15|a-zа-я0-9 ,.-");//define("названиераздела_имя поля","название поля|макс_размер|используемые символы
притом используемые символы можно вставить в регулярку, и разбить запятыми, поставив между ними , тоесть a-z,а-я,0-9, ,.-
Но это на пратике оказалось неудобно жутко.
Дальше пробывал делать файл констант для каждого раздела. Но тоже неудобно. Повсюду файлы конфигов.
В общем интересно как люди с большим стажем, чем у меня разруливают конфиги?
 

dark-demon

d(^-^)b
PHP:
define( 'showtopic.php', 'topics|20|topics.tpl' ) // define( 'имя скрипта', 'таблиа в бд|результатов на страницу|имя шаблона' );
 

Baranov_Dron

Новичок
да) я чтото в конфиги сильно много всего положил...
но и все параметры в скрипте держать тоже не надо....
где золотая середина? что выносят в конфиг обычно?
 

dark-demon

d(^-^)b
обычно выносят повторяющийся код, либо значения, которые может потребоваться изменить сразу в нескольких местах.
 

FractalizeR

Новичок
Автор оригинала: dark-demon
обычно выносят повторяющийся код, либо значения, которые может потребоваться изменить сразу в нескольких местах.
Мне всегда казалось, что в конфиги выносят настройки, а уж никак не код...
 

Beavis

Banned
повторяющийся и т.п. код выносят наверно всё таки в библиотеки а не конфиги?)
 

Baranov_Dron

Новичок
Автор оригинала: Beavis
повторяющийся и т.п. код выносят наверно всё таки в библиотеки а не конфиги?)
вы товарищ меня путайте, не вижу связи между повторяющимся кодом и библиотекой...
Класс нужны, чтобы уменьшить количество повторяющегося кода, а не "чтобы в них вынести код"...

-~{}~ 12.02.08 11:10:

Автор оригинала: FractalizeR
Мне всегда казалось, что в конфиги выносят настройки, а уж никак не код...
ну а максимальный размер поля, разрешимые символы, максимальный размер загружаемых файлов по сути настройки. Но их по сути дофига... и как всё вынести в этом и состоит проблема...
 

FractalizeR

Новичок
Почему же проблема?

form_config.php
PHP:
<?php
define('FIELD_MAX_SIZE', 40);
define('ALLOWED_CHARS', '~A-Za-z0-9~');
define('MAX_UPLOAD_SIZE', '50M');
?>
или

form_config.php
PHP:
<?php
conf['FIELD_MAX_SIZE'] = 40;
conf['ALLOWED_CHARS'] = '~A-Za-z0-9~';
conf['MAX_UPLOAD_SIZE'] = '50M';
?>
или

form_config.php
PHP:
<?php
class FormConf {
    const FIELD_MAX_SIZE = 40;
    const ALLOWED_CHARS = '~A-Za-z0-9~';
    const MAX_UPLOAD_SIZE = '50M';
}
?>

Но в конфиги нельзя выносить исполняемый код. Только параметры для него.
 

С.

Продвинутый новичок
Но в конфиги нельзя выносить исполняемый код.
Кто это запретил? Алгоритм расчета некоего коэффициента, тоже может быть частью конфигурации. Что лучше, написать код и потом evalить его где-то, или сразу нормальную функцию в конфиге?
 

FractalizeR

Новичок
"нельзя" условно говоря. Также нельзя, как и "goto" использовать. Не рекомендуется, но если очень надо и вы действительно знаете, что делаете, то можно.

Что касается алгоритма расчета - я бы его в конфиг не записывал. Проще его в класс инкапсулировать (зависит от алгоритма, конечно. 2+2 незачем вообще никуда выносить).
 

dark-demon

d(^-^)b
"конфиги" - это "значения, которые может потребоваться изменить сразу в нескольких местах"

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

Baranov_Dron

Новичок
Автор оригинала: FractalizeR
Почему же проблема?

form_config.php
PHP:
<?php
define('FIELD_MAX_SIZE', 40);
define('ALLOWED_CHARS', '~A-Za-z0-9~');
define('MAX_UPLOAD_SIZE', '50M');
?>
или

form_config.php
PHP:
<?php
conf['FIELD_MAX_SIZE'] = 40;
conf['ALLOWED_CHARS'] = '~A-Za-z0-9~';
conf['MAX_UPLOAD_SIZE'] = '50M';
?>
или

form_config.php
PHP:
<?php
class FormConf {
    const FIELD_MAX_SIZE = 40;
    const ALLOWED_CHARS = '~A-Za-z0-9~';
    const MAX_UPLOAD_SIZE = '50M';
}
?>

Но в конфиги нельзя выносить исполняемый код. Только параметры для него.
Вот что то типа того и нужно, но вся проблема в том, что например
полю email: разрешимые символы a-z,0-9,@-_. длина 50
полю год 0-9 длина 4
поле марка 0-9a-zа-я- _ длина 10
и так далее, как видете полей много! И у каждого уникальные значения! поэтому длину конфига будет большой!
вот в чём все траблы

-~{}~ 13.02.08 10:28:

Автор оригинала: FractalizeR
"нельзя" условно говоря. Также нельзя, как и "goto" использовать.
Хм а goto разве в php есть? в сях помню был) полезная вещь...

-~{}~ 13.02.08 10:31:

Автор оригинала: triumvirat
это в шаблоне что ли??
причём тут шаблон? хотя и слово шаблон может иметь множественное значение, в веб программировании это:
1)patterns GOF(ну и grasp и другие)
2)шаблоны в шаблонизаторе
3) регулярное выражение иногда тоже шаблоном называется
а мне это нужно в классе, проверяющем значения.
 

FractalizeR

Новичок
Вот что то типа того и нужно, но вся проблема в том, что напримерполей много! И у каждого уникальные значения! поэтому длину конфига будет большой! вот в чём все траблы
Я не думаю, что это траблы. Просто не нужно все константы из всего проекта пихать в один файл, если их действительно очень много. Разбейте их тематически и все.

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

По сути, в вашем проекте наверняка можно выделить объекты (как то фотография, новость, статья и т.д.). Параметры форм, о которых вы говорите, суть - свойства этих объектов. Для проверки корректности введенных свойств обычно используют валидаторы.

Скажем, если у меня есть класс "Пользователь", то в конструкторе объекта можо было бы добавлять валидаторы таким образом:

PHP:
$this->_addValidationRule('user_role', new Fractal_Validator_Enum( array (self::USER_ROLE_ADMIN, 
    self::USER_ROLE_GUEST, self::USER_ROLE_RESELLER, self::USER_ROLE_SUPPLIER, self::USER_ROLE_USER )), 'User_InvalidUserRole');

$this->_addValidationRule('user_login', new Fractal_Validator_RegEx('/^[A-Za-z\d_]{6,20}$/'), 'User_LoginMalformed');

$this->_addValidationRule('user_passwordhash', new Fractal_Validator_RegEx('/^[A-Fa-f\d]{40}$/'), 'User_PasswordHashMalformed');
		
$this->_addValidationRule('user_email', new Fractal_Validator_Email(), 'User_EmailMalformed');
		
$this->_addValidationRule('user_firstname', new Fractal_Validator_RegEx('/^[A-Za-z\s]{1,40}$/'), 'User_FirstNameMalformed');
и так далее.

При вызове $user->save, происходит проверка всех полей класса валидаторами. Если есть ошибка, save возвращает false, а метод getErrors() возвращает коды возникших ошибок в массиве (типа array('User_FirstNameMalformed', 'User_PasswordHashMalformed')

Это, разумеется, только пример. Похожим образом все сделано в Vbulletin. Там используются так называемые дата-менеджеры. В конкретном наследнике класса vB_DataManager (например, vB_DataManager_Poll) переопределяется переменная класса $validfields, которая содержит типы полей и информацию для их проверки перед записью объекта в БД.

Если в вашем проекте формы конструируются динамически, можно было бы в каждом классе иметь метаинформацию о свойствах, такую как тип (чтобы знать, какое HTML поле использовать для ввода информации об этом свойстве), максимальную длину и т.д.)


Хм а goto разве в php есть? в сях помню был) полезная вещь...
Нету :) Я образно выразился.
 

Baranov_Dron

Новичок
хм долго разжёвывал твой материал! Даже в vbulletin поковырялся!
Но вроде понял! Очень интересное решение!
FractalizeR большое спасибо за помощь!!!
 

litvinenko

Новичок
да. для каждого типа сделать свой валидатор, который будет проверять как вы сами определите.
СОгласен с FractalizeR
 
Сверху