Вот накатал статейку. Оцените. Может подойдет для размещения в статьях..

Автоматизация очистки и проверки cgi-параметров

Одна из трудоемких задач в web-программировании для начинающих - очистка и проверка cgi-параметров.
Когда программа получает большое количество параметров программисты частенько забывают правильно обработать некоторые параметры. Из-за этого резко падает надежность программы.
Чтобы решить эту проблему, сначала разберемся, каким образом происходит процесс получения параметров и работа с ними.
1. Программист получает параметр с помощью, например, модуля CGI.pm
2. Этот полученный параметр можно проверить каким-либо регулярным выражением.
Пример:


Все параметры, по сути, можно отнести к определенному типу. Например, строка, дата, число, файл. На каждый тип можно написать свою проверку, которая будет точно проверять, подходит данный параметр под этот тип или нет. Напишем функцию, которая будет проверять параметр на принадлежность к каким-нибудь типам, и применим ее.


Таким способом мы полностью избавились от повторения одних и тех же проверок для разных параметров одного типа, упростили и улучшили читаемость программы.
Но еще осталось выражение, которое можно автоматизировать.

Здесь мы передаем параметр нашей функции очистки. А что если мы заключим в одну функцию и получение параметра и очистку?
Тогда для удобства можно написать модуль-интерфейс, который будет предоставлять 2 функции: получение очищенного и проверенного параметра и функцию только очистки параметра.


Использовать этот модуль можно следующим образом:

Получившийся модуль можно приспособить не только для работы с модулем CGI, но и с другими, более легкими модулями.

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

Боюсь такая стандартизация не очень хорошо скажется на гибкости 

Почему?

В этот механизм можно добавить возможность определять дополнительные типы.
И будет все гибче некуда.  

Встречный вопрос, что мне даст определение таких типов??? Сколько я не писал интерфейсы, проблемы с надежностью у меня не было. Более того, если у меня нет необходимости проверять все приходящие параметры, и все зависит от того, пришел ли какой-то ключевой параметр, с ключевым значением. В конце концов, меня больше интересуют значения по данным параметрам, а не они сами 

1. Удобство работы со стандартными данными. Один раз описываешь проверку и пользуешься. Без такой штуки приходится один и тот же код писать по многу раз.
2. Улучшается читаемость кода.
3. Увеличивается скорость написания программ




Я не говорю, что надо очищать все без исключения параметры и только этим способом. Это и не нужно. Но писать один и тот же код по нескольку десятков раз это по моему не любовь к себе.
А когда встречается уникальные данные, можно и ручками очистить, условия добавить.
Выше описанный способ ни коим образом не мешает этого делать. Это всего лишь один из многих способов. Я его использую, и мне нравится.

Vaneska, простой пример. Нередко в названии параметра присутствуют символы, которые также являются частью входных данных. Я делаю так, чтобы не перенасыщять количество передаваемых параметров, т.е. структурирую сами названия параметров. И в момент анализа входных параметров, также получаю определенную информацию из самого названия. А раз мне все равно приходится парсить само название параметра, то зачем мне еще и делать проверку на тип, причем как получается на свой тип, который мне еще придется дописать сюда ручками . Получается двойная работа. 


В том-то и дело, что со стандартными данными, лично мне и так просто работается, да и наверно не только мне. В том числе и код не сложный и хорошо читается. Кроме того, в перле все же отсутствуют стандартные данные, в таком виде. Разделение на string, int и т.п. это особенность ряда других языков 


А на это в большей степени вляет как ты его продумал в голове ;)

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

Такого мне в голову не приходило.. Наверно не было соответствующих задач..


Ну так это понятно, что велосипед. Здесь на форуме подобное вскользь упоминалось.. Я просто написал на эту тему статью. Никогда не писал, а тут как-то зацепило и написал  


И все-таки.
Вот ты как-нибудь борешься с повторяющимся кодом именно в анализе параметров? Ведь если проект большой, данных очень много, то однотипных данных будет тоже много, и код для их обработки, по сути,  будет один и тотже. А это значит, что придется писать одно и тоже по многу раз. А не проще ли это оптимизировать(автоматизировать)? Зачем тогда делаются разнообразные фреймворки? Ведь это, по сути, набор набор программных средств для автоматизации рутинных операций.

Или тебя вообще не напрягает написание одного и того же по нескольку раз?