如何从一处控制 HTML 表单字段的定义、呈现、验证和存储？

Question

我希望能够在一个地方定义有关表单字段的所有信息，而不是在 DB 中、在 HTML 中、在 JavaScript 中、在 ASP 中保存一些信息......

为什么我必须担心可能会改变的事情当我想更改某个字段的某些内容时，可以在四个不同的位置（或更多位置）进行更改吗？

即，我不想：

• 在数据库中声明字段
• 并在 HTML 中的某处复制一些信息
• 并且在某些 JavaScript 中的某处复制一些更多信息
• 并在某个 ASP 中复制更多信息。

因为我是一名开发人员，所以我理想地寻找一种方法，而不是工具或软件包。 （我认为！）

目前，我通过将所有控制信息放入 SQL 的扩展属性“描述”文本区域来实现此目的。例如，必填电话号码字段将具有以下 SQL 声明：

[home_phone] [varchar](15) NOT NULL

，我将以下“控件”放入说明扩展属性中：

[ "家庭电话"][phone_text][user_edit][必需][allow_na][form_field_size_equals_size][default=""][group="home_address"][rollover="仅输入：数字、破折号、括号、空格"][解释=“输入n/a如果您没有家庭电话”]

在我当前的系统中，为家庭电话字段动态生成以下HTML：

<div class="div-item" id="item-FORM:FIELD:TABLE_HOME:HOME_PHONE">
    <div class="div-item-description" id="item_description-FORM:FIELD:TABLE_HOME:HOME_PHONE">
        <span class="rollover-explanation" title="enter only: numbers, dash, parenthesis, space">
            <label for="FORM:FIELD:TABLE_HOME:HOME_PHONE" id="item_label-FORM:FIELD:TABLE_HOME:HOME_PHONE">
                Home Phone
            </label>
        </span>
    </div>
    <div class="div-item-stipulation" id="item_stipulation-FORM:FIELD:TABLE_HOME:HOME_PHONE">
        <span class="stipulation-required" id="item_stipulation_span-FORM:FIELD:TABLE_HOME:HOME_PHONE" title="required" >
            *
        </span>
    </div>
    <div class="div-item-value" id="item_value-FORM:FIELD:TABLE_HOME:HOME_PHONE">
        <div class="individual-forms">
            <form class="individual-forms" id="FORM:TABLE_HOME:HOME_PHONE" name="FORM:TABLE_HOME:HOME_PHONE" action="" method="post" enctype="multipart/form-data" onsubmit="return(false);">
                <div class="individual-forms-element">
                    <input
                     class=""
                     type="text"
                     id="FORM:FIELD:TABLE_HOME:HOME_PHONE" name="FORM:FIELD:TABLE_HOME:HOME_PHONE"
                     size="15" maxlength="15"
                     value=""
                        FORM_control="true"
                        FORM_control_name="Home Phone"
                        FORM_control_is_required="true"
                        FORM_control_is_phone_text="true"
                    >
                </div>
            </form>
        </div>
    </div>
    <span class="spanExplanation">
        enter <strong>n/a</strong> if you don't have a home phone
    </span>
</div>

看起来像this（在 IE 7 中）：

客户端 JavaScript 验证由**FORM_control**... 参数，出错时会生成解释和字段突出显示。 （不幸的是，HTML 元素中的自定义参数并不完全符合标准。）

我的主要问题是这种使用“描述”字段的方法使用和维护起来一直很麻烦。 Description 属性只能是 255 个字符，因此我有很多缩写。随着系统的扩展，控件的数量也大大增加，超过了原来的十几个。我用于解释所有这些控件及其缩写的代码并不漂亮或高效。正如我所说，HTML 元素中的自定义参数在 FireFox 中不起作用。

我当前正在控制（并希望继续控制）的内容包括：

• 字段描述（例如“家庭电话号码”）
• DB 表名称（例如“home_address”）
• DB 字段名称（例如“home_phone”）
• DB 字段类型/大小
• DB 允许 null
• 分组（例如，此特定字段是所有“主页”字段的一部分）
• 必需/可选
• 只读（对于系统提供的数据）
• 大小（呈现的表单字段大小）
• 类型（例如，文本、数字、字母、选择、邮政编码、电话、街道地址、姓名、日期等）
• 接受的输入（非空白；仅限数字；无空格；电话号码；reg exp；等）
• 扩展说明（例如，对于电话 #“如果您输入 n/a，请输入 n/a）没有家庭电话”）
• 滚动说明（例如，对于电话＃“仅输入：数字、破折号、括号、空格”）
• 行（对于选择列表 - 1 = 下拉列表）
• 行/列（对于textareas）
• 错误消息文本
• 错误指示（如何显示哪个字段包含错误，例如红色背景）
• 等等...

并且需要明确的是，我完全支持逻辑和设计元素的分离。我确实有一个单独的 CSS 文件，它是手动维护的（不是生成过程的一部分）。

我的服务器环境是经典（非.Net）ASP 和 SQL 2008。我非常擅长 HTML、CSS、JavaScript 和 ASP，并且对 SQL 也很熟悉。

我想象我想要是某种 JSON、XML 等，它们是用于生成所有内容的单一源，例如：

• 一个 SQL 脚本，它实际创建 SQL 表、
• HTML（带有 CSS 类和JavaScript 客户端验证/函数调用）
• ASP（服务器端验证）

我当前执行此操作的方法是动态的（未编译）并且非常慢，所以我可能正在寻找某种生成此内容的“编译器”一次。我实际上只有经典的 ASP、JavaScript 或 SQL 作为这个“编译器”的可用语言。

虽然我认为我可以自己创建这个系统，但我希望其他更好的开发人员已经想出类似的东西。

假设这应该扩展到至少数十个字段。 （仅供参考，我当前的表单在一页上有太多字段，但我正在单独解决该问题。）

感谢您的帮助！

Answer 1

Javascript 验证被高估了

我认为 JavaScript 验证被高估了。在服务器往返可能需要 10 秒的日子里，这很好，但现在通常只需不到 3 秒。在考虑 AJAX 提交过程时，您可以将该时间缩短至亚秒级。

作为削减往返行程的所有努力的回报，您必须处理跨浏览器支持、复杂调试、缺乏服务器端日志记录以及处理用户禁用 JS 的情况等所有各种复杂性。在一个典型的场景中，我们谈论的是大量浪费的时间和困难的调试（尝试询问一个典型的白痴他们使用什么浏览器，更不用说他们使用的版本）。

数据库作为一站式验证器

您说数据库不是一个完整的验证环境，但我认为这不再是事实。像 PostgreSQL 这样的现代数据库将允许您以几乎您选择的语言连接复杂的验证函数作为触发器，并向应用程序返回适当的错误响应。

因此，如果您按照我要进行的操作，就可以在一个地方（即数据库）进行验证，而不会出现历史缺陷。过程是：

1. 创建一个基本的HTML表单，忘记了
   HTML5 或 Javascript 验证。
2. 当表格完成后，或者作为
   需要，通过AJAX提交（如果
   可用）或标准 POST（如果没有）。
3. 或多或少通过更新/插入
   直接到你的数据库
   触发功能正常化和
   验证数据。
4. 立即返回结果和或
   错误（可能通过交易），
   并执行任何进一步的服务器
   在此阶段进行处理。如果你
   决定不保留您的数据
   可以删除新行或
   回滚事务。
5. 结论返回任何适当的
   重定向、消息或更新
   浏览器通过 JSON/AJAX 或
   重新加载清理后的数据。

这可能听起来很慢/效率低下，但我认为这忽略了当今的现实，即：

1. 现在几乎所有东西都是宽带，甚至是无线。
2. 处理能力比
   开发者时间。
3. 这几种
   更新往往受到以下限制
   用户可以快速填写表格，而你不会
   以典型的方式锤击你的数据库
   设想。
4. 您仍然必须在某个地方进行验证，那么为什么不在数据库中呢？

好处是巨大的：

1. 在大容量服务器（如交易所、twitter、提要等）上，这
   流程适合 API 控制
   通过 SOAP/AJAX/RSS/之后的任何方式
   只需要薄薄的一层
   API客户端之间传输数据
   和数据库。
2. 无论什么客户
   使用的语言或协议
   验证保持不变。
3. 即使是原始的 SQL 语句也会得到
   经验证可以防止
   编程错误、损坏
   进口或第三方提要来自
   破坏你的数据结构。
4. 触发器很容易切换，如果
   必需的。在普通代码中通常会更困难。
5. 验证始终是一致的。
6. 验证函数位于
   数据库，然后允许访问
   索引和其他行或表没有
   连接器开销、数据转换
   和网络/套接字延迟。
7. 验证函数可以运行在
   已编译的代码，即使您的网络
   服务器语言是动态的。

唯一真正的缺点是：

1. 难以升级或迁移到
   其他数据库软件。
2. 如果您的首选语言很困难
   不支持（但是 Postgres
   支持用 C 语言编写的函数，
   PL/pgSQL、Python、TCL、Perl、Java、
   R、Ruby、Scheme、Bash 和 PHP 等
   除非你被 C#/VB 困住了
   应该找到一个你可以处理的）。

上下文敏感性

对于你的问题的某些方面我根本不推荐。主要是当您尝试将 HTML 表单对象的表示形式与单个位置的数据联系起来时。

这个想法很快就会适得其反，因为您会发现在典型的应用程序中，信息的呈现对上下文（特别是目标受众）高度敏感。

例如，在订购系统上，您可能拥有客户输入的数据，然后管理员可以访问这些数据。客户对数据的视图可能更加有限，可能需要不同的标题和描述，最好显示为复选框，而管理员可以获得更紧凑的视图。您甚至可能向不同类型的客户（零售与批发）提供相同的数据。

简而言之，数据的呈现通常需要比验证更加流畅，因此在某些时候您应该真正划清界限 - 即使这意味着一些重复。

Answer 2

我在工作中一直在解决完全相同的问题。我无法忍受重复自己，特别是因为我知道，当我在几个月后必须更改某些内容时，我将永远不会记住所有分散的冗余部分。答案必须考虑以下事实：

• 数据库应该尽可能合理地验证自身。这是基本的数据完整性；如果您尝试在其中放入无效数据，数据库应该会异常。

• 数据库无法验证自身。添加对唯一性、格式或外键的约束很容易，而且从技术上讲，SQL 可以走得更远，但如果您在数据库级别强制执行地址/邮政编码对应，那么您会后悔的。验证逻辑的某些部分必须存在于服务器端代码中。对于您和我的情况，这意味着 ASP。

• 如果您想要客户端验证，这意味着 Javascript。

此时，我们已经讨论了三种语言的验证约束，并且它们之间的阻抗不匹配可能很重要。您不能总是将验证因素归咎于其中之一。你所能做的就是尽可能地将逻辑保持在一起。

您建议的解决方案有一个巨大的优势——所有逻辑都集中在一处。这一优点被几个缺点所平衡：

• 如果不与数据库通信，您根本无法进行任何验证。

• 为了将元数据从数据库获取到 ASP，您必须有特殊的代码来解释元数据迷你语言。这比接受某种程度的冗余要复杂得多。

• 您的元数据将前端显示代码放入数据库中。这意味着如果您想更改文本，则必须编辑数据库模型。这是一个相当严格的要求，它将您的数据库模型与表示逻辑联系起来。此外，国际化实际上是不可能的。

• 因为您的元数据和用户之间存在如此多的转换层，所以对元数据空间的任何扩展都将需要修改多层紧密耦合的代码。

为了尝试在您的解决方案和旨在避免的冗余之间找到中间立场，我建议如下：

• 在数据库中放置基本验证约束。

• 在 ASP 中创建一个系统，用于指定具有任意内容和验证约束的行为数据模型。当您使用此语法定义模型时，您将仅复制数据库中的基本约束。

• 在 ASP 中创建一个系统，以 HTML 形式在页面上显示表单字段。表单字段声明将引用适当的数据模型，并另外包括显示代码，例如标签和描述性文本。 HTML 生成代码可以使用从数据模型派生的合理默认值。唯一重复的数据应该是字段的名称，它用作将显示的字段绑定到适当的数据模型的键。

• 创建或查找 Javascript 验证库。让上述 HTML 生成代码根据关联的数据模型在生成的标记中自动插入对此库的挂钩。

因此，您有一个系统，其中有关字段的信息可能存储在几个位置，具体取决于最合适的位置，但几乎不会重复。验证信息在 ASP 数据模型中声明。显示信息只能在页面字段声明中找到。字段名称在整个堆栈中用作将它们链接在一起的关键，并且关注点的层次结构允许您根据需要覆盖在较低级别上所做的假设。

我仍在致力于此设计的实现，但如果您感兴趣，我可以发布一些示例代码。

Answer 3

在我看来，这违背了逻辑和设计元素分离的每一个原则。我知道，在我从事的较大项目中，实际的 SDLC 要求规定一种类型的工程师可以接触文件的一个级别，而 UI 工程师可以接触另一个文件级别，而“代码猴子”只能接触其中的一个子集。你能想象在那种情况下会发生什么混乱吗？代码猴子必须获得 UI 工程师的许可，而 UI 工程师又必须与必须参加集成电话会议的工程师进行协调，而工程师必须联系技术支持人员，然后技术支持人员会搁置项目，直到业务要求法律许可为止。 ....

开个玩笑，我不认为你的方法不好。

我确实相信按照本机处理的方式处理事情，即构建表单文本字段可能更有效地由 html 本地处理，而不是通过数据库调用，然后通过一系列脚本构建 html。你的“编译”方法让我想知道它是否会抵消在各自文件中缓存常见 javascript 和 css 元素的好处。

有一些框架，如 Zend、CodeIgniter 和 Symfony（在 PHP 方面），它们通过内置功能越来越接近您提到的内容……尽管它们还没有实现。 Zend 特别使用编程功能来构建、验证和设计表单，一旦您弄清楚了它的细微差别，它就会非常强大。也许它可以作为你终极追求的典范。虽然看起来你是一个典型的 asp 家伙......但这不是你要找的。我离题了。

Answer 4

我认为这个问题超出了我的知识范围，但我认为尝试提供帮助并没有什么坏处。

我正在开发我的第一个 PHP 网站，从一开始，由于我无法预测该网站的许多因素，而且我只是一个人，所以我从一开始就决定每个页面上的每个设计元素都可以通过一个页面进行维护。这是一次学习经历，所以我不太担心没有太多计划，但有些事情只是磨练我的齿轮，比如命名约定，但通过我的方法，我总是能够轻松地进行站点范围内的更改。

我制作的每个页面的结构如下：

<?php require_once 'constants.php'; ?>
<?php $pageTitle = 'Home Page'; ?>
<?php require_once REF_LAYOUT_TOP; ?>

<h1>Hello!</h1>

<p>World</p>

<?php require_once REF_LAYOUT_BOTTOM; ?>

在常量中，我几乎为所有内容都有常量。 CSS 颜色（用于一致的布局）、目录位置、数据库连接、链接、某些页面的常量（这样我可以修改文件名而不会让它们损坏任何东西），以及各种各样的东西。

顶部包含导航、错误处理 JavaScript 脚本、任何类型的动态创建的内容、导航等。

这样，如果我想实现新的东西，它就可以在任何地方实现。我尝试了 jQuery，它只需要一个链接。

可能的解决方案

如果您尝试从一个位置调整许多内容，我强烈建议您学习一点 PHP 知识。由于 PHP 只是一个服务器脚本，因此它的唯一输出是文本。换句话说，您可以将 PHP 插入 JavaScript、HTML 以及几乎任何地方。您可以通过这种方式为各种悬停弹出窗口设置相同的文本。我不知道ASP是否会阻止你这样做（我对它的了解为零）。

我认为这就是大多数网站必须构建的方式。一定是……否则他们怎么能维持数百页呢？我认为这是最符合逻辑和语义的。

Answer 5

我对 ASP 不熟悉，所以我会更笼统地讲，但不知道它们是如何实现的。

通常，表单表示创建、编辑或删除实体所需的信息。所以我从实体类开始。在其他架构中，这通常称为模型（如模型-视图-控制器）。实体类确定它需要什么信息，并负责数据库查询。

可以通过这种方式直接从实体构建表单。实体为您提供了更直接的控制，例如，您可能在数据库中有一个整数字段，尽管您真正想要的值在 0 到 255 之间。实体可以知道这个更具体的约束，即使数据库不知道t。

接下来，您可以创建某种表单类，该类将使用实体来生成其界面。它将处理所有 HTML、Javascript 以及您需要的任何其他内容。

该实体可以有多种类型。可以有效分离数据库中的表示。假设一个帖子可以有很多标签。在数据库中，您可能会保留两个表，一个用于帖子，另一个用于标签。但该实体将代表一个帖子以及一个标签列表，因此它们不是分开的。

表单类可以处理它的外观，而您只需担心语义。例如，如果实体需要字符串列表，则表单可以通过使用 JavaScript 创建扩展的文本字段列表来实现该列表，然后表单负责将此数据正确提交给实体。

这种形式也会在多个领域一起工作或解析方面产生影响。例如，如果表单看到一个可能为 null 的类型，它会提供一个解释：“如果您没有电话号码，请键入 n/a”，如果它看到该字符串，则正确返回 null。

Type 类可以是验证表单数据的接口。如果所有类型的所有 validate() 方法都返回 true，则提交表单。每种类型还负责解析其值（如“n/a”解析），以便提交正确的内容。

其中一点是表格与表格不同。表中的 id 字段不应显示在表单中，并且某些数据可能在另一个表中连接到它，因此请根据其建模的“实体”而不是表来考虑表单。它只是一个适配器。

Answer 6

我在 XML 文件中为每个表定义架构。然后我编写了一组可以对任何 XML 模式进行操作的 CRUD 方法（作为请求参数传入）。除了 CRUD 之外，它还可以创建和删除表、将内容导出到 CSV 以及导入 CSV 文件。我所要做的就是在我的模式目录中放置一个新的模式文件，并且我对这个新表有完整的 CRUD。如果字段是外键，则在插入或更新期间，输入框旁边会自动出现一个链接，单击该链接时，会弹出一个窗口以查找外键。如果该字段是日期，则会自动出现弹出日历的链接。
我使用 Java EE 和 jsp 完成了此操作。但我确信它也可以用 php 来完成。

<schema>
  <tableName>xtblPersonnel</tableName>
  <tableTitle>Personnel</tableTitle>
  <tableConstraints></tableConstraints>
<!-- COLUMNS ====================================== -->
<column>
  <name>PID</name> 
  <type>VARCHAR2</type> 
  <size>9</size> 
  <label>Badge ID</label>
</column> 
<column>
  <name>PCLASS</name> 
  <type>VARCHAR2</type> 
  <size>329</size> 
  <label>Classification</label>
</column> 
<column>
  <name>PFOREMAN</name> 
  <type>VARCHAR2</type> 
  <size>9</size> 
  <label>Foreman Badge</label>
</column> 
<column>
  <name>REGDATE</name> 
  <type>DATE</type> 
  <size>10</size> 
  <label>Registration Date</label>
</column> 
<column>
  <name>PISEDITOR</name>
  <type>VARCHAR2</type> 
  <size>3</size> 
  <label>Is Editor?</label>
  <help>0=No</help>
  <help>1=Yes</help>
</column> 
<column>
  <name>PHOME</name> 
  <type>VARCHAR2</type> 
  <size>9</size> 
  <label>Home?</label>
</column> 
<column>
  <name>PNOTE</name>
  <type>VARCHAR2</type> 
  <size>35</size> 
  <label>Employee Notes</label>
</column> 
<!-- Primary Keys ====================================== -->
<!-- The Primary Key type can be timestamp, enter, or a sequence name) -->
<primaryKey>
  <name>PID</name>
  <type>enter</type>
</primaryKey>  
<!-- FOREIGN KEYS ====================================== -->
<!-- The Foreign Key table is the lookup table using the Key to retreive the Label -->
<foreignKey>
  <name>PID</name>
  <table>phonebook</table>
  <key>badge</key>
  <label>lname</label>
</foreignKey>
</schema>

Answer 7

太棒了！你的想法很好，方向也正确，而且已经有多家公司在做了。这就是最初的“RAD”（快速应用程序开发）概念。

这个想法是将每个字段的属性保存在数据库中，也称为“元数据存储库”或“数据字典”。这不仅是一个好主意，而且是一个最佳实践，因此所有字段在类型、长度、描述等方面都是一致的。数据字典不仅应该与用户界面一起使用，还应该与数据库创建一起使用。更进一步，通过这种方法，您可以轻松处理多个区域设置。

不幸的是，RAD 工具现在并不常见。它们价格昂贵，而且在某些情况下不灵活且具有限制性。程序员热爱编程，并且鄙视那些工具。但是，谁知道呢？似乎每天都有一个新的开源项目开始！

不幸的是，您的“工具集”非常有限，并且创建 RAD 工具并非易事：它涉及意想不到的复杂程度。您可能需要学习 .NET、Java 或任何其他强大的语言。

最好的方法是创建一个工具，根据存储在数据库中的数据字典生成 ASP 或任何所需的 HTML，从而提高性能。如果字典或表单发生变化，您只需运行生成器，瞧！您的新页面就准备好了。

如果需要，您还需要能够允许“覆盖”字典。例如，在某些情况下，“电话”一词对于某些形式来说太长。此外，您还需要有一个足够好的代码生成器，这样您就不必手动修改生成的代码，并且如果您需要这样做，您的工具将足够智能来记住这些更改。

不幸的是，我无法在这方面为您提供更多帮助。我的建议是：(1) 提高你的技能，(2) 寻找满足你需要的开源项目，(3) 如果愿意，帮助该项目，(4) 让每个人都比其他人更快地生成应用程序。 ;)