开放的编程资料库

当前位置:我爱分享网 > PHP教程 > 正文

关于表单验证的思考

我最近一直在思考表单验证问题。除此之外,我想在工作中使用一套标准的工具来验证表单输入;我也在用PHP重写家庭网站,并希望在那里也保持一致。最后,我真正相信ChrisShiflett的两个安全实践:过滤输入、转义输出。验证应该始终进行,并且应该严格进行;不允许任何超出完成工作所需的事情。

在过去的一个月里,我曾短暂地接触过HTML_QuickForm。作为CGI::Application邮件列表的观察者,HQF看起来像是PHP对perl的Data::FormValidator的回答。HQF在php-pear-general列表上的帖子频率很高。很多人似乎对此很满意。我决定尝试将其作为最新版本的Cgiapp的示例插件。

我的问题是我希望能够在脚本之外的文件中定义表单验证。这样做的原因是,当我扩展和重用类时,我经常发现我可以对方法使用相同的通用运行模式……只要表单验证逻辑是独立的即可。例如,这允许我决定在一个应用程序实例中我将需要字段A-M,但在另一个应用程序实例中,我只需要A-E(反之亦然)。但它不需要更改实际的应用程序逻辑,因为验证是分开保存的,而且我让应用程序实例指示要使用哪个验证文件。

我使用HQF的方法是创建一些用于从配置文件设置表单的实用方法。这将允许程序员在文件中定义表单,然后将该文件的位置传递给实例脚本中的类。然后,在应用程序类中,程序员只需将参数传递给实用方法,瞧!表单验证完成。

不幸的是,HQF非常简单,几乎不可能以这种方式编码。我做了一些非常认真的努力来这样做,但我得到的最好的结果是在一个被eval()的文件中利用嵌套数组——对于一个有安全意识的程序员来说,这不是一个可行的解决方案。我看到的问题是:

  • 验证和过滤与实际的元素定义分开。在我看来,验证和过滤是在一个元素上;元素应该是基本块,而验证和过滤器是它的属性或属性。虽然我理解HQF决定背后的想法,但我发现它在实践中不直观,而且感觉它创建了更多代码。
  • 元素、验证和过滤器通常接受难以在静态文件中定义的参数(诸如表单操作属性或配置数组之类的东西)。特殊元素太难创建。选择具有选项的元素等太难通过定义文件创建。

最后,我创建的用于解析包含表单验证的文件的代码比我可以用HQF手写的任何代码都大得多。并且formvalidation文件本身的大小与手动编码等效的HQF代码相似。

上周我开始研究表单验证库,经过几个小时的努力,我意识到我正在创建与HQF一样大的东西。当然,我构建它的想法是使用一个SimpleXML文件来包含验证逻辑,它会适应这一点,但最终,这是一段毛茸茸的代码,对于我的大多数表单来说,杀伤力太大了​​。

然后我突然想到:几乎我创建的每个表单都略有不同,而且,一般来说,我发现会出现以下情况之一:

  • 输入量非常小,与使用已建立的库相比,我自己可以用更少的行来验证它。
  • 有很多数据,但大部分都在收音机、复选框中或下拉列表,并且可以通过检查数组来验证。
  • 数据量是高度专业化的,无论如何我都必须手动验证。

总而言之:我很少从使用单一验证库中获得任何开发收益。我所说的发展收益是指节省时间或精力。

那会把我留在哪里?好吧,在进一步的分析中,我意识到我可以看到使用库的主要原因是我经常需要验证的那些数据集,但PHP中没有内置的方法来验证这些数据:电子邮件地址、URI、电话号码、日期等。此外,我可能需要一些预过滤器——比如去除所有非数字或非字母、去除标签、trim()ing等。我仍然希望尽可能自动化,但仅限于常见类型。

我设想能够使用如下INI样式的文件:

[name]
label="Name:"
error="Please provide your name; use only alphabetical characters, commas, hyphens, periods, and single quotes"
required=true
rule1type=regex
rule1data="/^[a-z .,'-]+$/"
filter1type=trim
filter2type=htmlentities

[email]
label="Email:"
error="Please provide a valid email address"
required=true
rule1type=email
filter1type=trim

[state]
label="State of residence:"
error="Please select your state from the drop-down list provided"
required=false
rule1type=in_array
rule1data=ME,NH,VT,MA,NY,CT,RI

这种风格可以捕获我所拥有的80%的案例,这将简化和加快我的开发,让我只处理其他20%。

我正在考虑如何编写代码——在类中使用什么结构,是需要类实例化还是使用静态方法等——然后意识到PaulM.Jones给了我一些关于使用的指示ofSolar_Valid当我向他建议我想将它作为插件包含在下一个版本的Cgiapp中时。我查看了他的课程,它所做的正是我考虑的验证编码。使用类似的过滤类(是的,Paul,如果你愿意,我会贡献代码!),编写一个可以像上面那样解析文件然后按我的意愿执行的验证例程应该变得相当简单。

然而,这并不是要成为Paul的插件,也不是对开发人员的呼吁。我想激发讨论:其他人如何验证表单?在进行了数百次表单验证之后,我们是否都得出了相同的结论——没有灵丹妙药?还是我错过了灵丹妙药?一些自动化是好事吗?或者每种形式都应该有自己特定的程序逻辑吗?是否已经有一个不错的精益库可以很好而简单地完成这些工作?还是那是遥不可及的?我错过了HQF的机会吗?还是膨胀了?

留下你的评论!

未经允许不得转载:我爱分享网 » 关于表单验证的思考

感觉很棒!可以赞赏支持我哟~

赞(0) 打赏