我正在用Perl编写一个Web应用程序。它有一个包含联系信息的表单,目前的布局如下:
$form_htm = <<EOF
<input value="$in{firstname}" name="firstname">
<input value="$in{surname}" name="surname">
...etc...
EOF
稍后我打印$form_htm
(以及其他内容)以显示网页。
以上对我有用,字段按预期进行插值。
但是,我希望使用此应用程序的不同组织能够为其字段设置不同的布局。有些字段不适用于某些组织,有些组织希望字段(在网页上)的大小不同于其他组织。
所以,我以为我会将表单的HTML存储在数据库中(不同组织的不同记录中的不同版本)。
但由于HTML没有存储在脚本中,因此字段(如$in{firstname}
)不会被插值,因此变量名称本身最终会出现在网页上(这不是我所追求的外观)
关于如何在这种情况下评估这些变量的任何建议? (我想到的第一件事是eval()
,但这似乎是为了评估表达式,而不是与许多其他文本混合的变量。)
或者,您是否可以建议一种更好的方法来为不同的组织提供不同的表单布局?
编辑:我也在Perl Monks上发布了此问题,但希望得到其他意见。
答案 0 :(得分:2)
这里有一些糟糕的方法和一些很好的方法来解决这个问题。
my $form_htm = <<EOF
<input value="$in{firstname}" name="firstname">
<input value="$in{surname}" name="surname">
...etc...
EOF
这是一件很常见的事情。它有重大问题。首先,它将程序的逻辑与显示的内容结合在一起。只有一种方法可以显示它,或者您的代码变得越来越复杂,试图允许多种方式来显示它。你遇到了这个问题。
其次,这意味着为了改变它的外观,你需要一个开发人员参与其中。您不能让单独的UX人员处理HTML和CSS布局,他们还需要了解Perl或让Perl开发人员参与其中。这使得进行简单的HTML更改非常昂贵且速度很慢。
第三,使用生成散布在其周围的HTML的代码使得很难弄清楚每个页面是如何形成的。如果您想更改页面中的表单,则必须在代码中搜索以查找其生成方式。
第四,它很慢。每个页面都必须由服务器生成。<%class>
has 'amount';
has 'name';
</%class>
Dear <% $.name %>,
We are pleased to inform you that you have won $<% sprintf("%.2f", $.amount) %>!
Sincerely,
The Lottery Commission
<%init>
die "amount must be a positive value!" unless $.amount > 0;
</%init>
这就是PHP和Mason所做的。它比你的代码中的HTML更好 ,但它仍然存在重大问题。 可以使用得很好,但它鼓励你将太多的逻辑放入模板中。这分散了逻辑,使得很难理解发生了什么。模板中的代码很难记录和测试。它还将代码混合到模板中,这再次模糊了UX人员和开发人员之间的界限。
模型 - 视图 - 控制器在数据和逻辑(&#34;模型&#34;)及其显示方式(&#34;视图&#34;)之间提供了清晰的描述。它们与一些代码相关联,以从模型中获取数据并将其作为变量发送到视图(&#34;控制器&#34;)。
这是整合网站最成功的方法之一。 Ruby On Rails和Catalyst是围绕这个构建的。
我建议Dancer。它比Catalyst更小,更容易理解。由于它提供的更少,因此更容易调整现有程序来使用它。它提供视图和控制器,模型由您决定。
有两种很好的方法来组合观点。
通常的方法是将整个HTML页面放在模板中,就像我们之前看到的那样,但是它没有自己的代码来获取数据,而是传递数据来使用。它操纵数据的语言有限。
在Perl中,这通常是Template Toolkit。
Dear [% name %],
It has come to our attention that your account is in
arrears to the sum of [% debt %].
Please settle your account before [% deadline %] or we
will be forced to revoke your Licence to Thrill.
The Management.
现在,UX用户可以自行管理HTML模板。他们仍然需要学习模板语言,但它至少是一个记录良好的模板语言。有限的语言不鼓励在模板中放置太多代码,在View和其余代码之间创建一种防火墙。
但是,格式化模板的所有工作仍然必须在服务器端完成。 UX用户仍然需要学习一种特殊的模板语言。这带给我们最好的方式。
在这种模式下,HTML不是在服务器端处理模板并在其中插入变量,而是使用Javascript来请求所需的数据并在其认为合适时显示它。这有很大的优势。
它完全将视图与其余代码分开。这使UX用户可以很好地控制应用程序的行为方式。他们决定每个页面需要哪些数据。他们决定如何操纵和显示它。开发人员可以专注于提供数据。
另一个优点是使用Javascript。 Javascript已经成为网页设计师必须知道的事实编程语言。 UX用户不需要学习特殊的模板语言,他们使用的是他们一直使用的相同的HTML,CSS和Javascript。
最后,这意味着大部分格式化工作在客户端完成,减少了服务器的负担。
主要缺点是这需要对现有系统进行重大的重构。现在,您的服务器代码不会生成HTML页面,而是生成JSON,以便Javascript通过REST requests进行操作。
现有系统的良好混合使用模板,但不使用特殊的模板语言,而是使用Javascript。名称和金额等简单标量变量仍可作为模板变量提供,但列表和散列等较大单位将作为JSON注入模板。
例如,这个模板......
var people = [% people %]
将随people = encode_json(\@people)'
提供,可能会扩展为:
var people = ["Jack", "Jill", "Jane", "Joe"]
然后,UX用户可以使用此Javascript people
数组执行任何操作。
在缺点方面,这仍然让开发人员过多地控制网站的工作方式,因为他们决定使用哪些模板以及他们给出了哪些数据,这仍然意味着模板必须扩展到服务器端。
从好的方面来说,它允许UX人员以他们熟悉的方式操纵数据,它强制实现视图与其余代码之间的明确分离,并且您可以将现有代码转换为使用这些类型的模板一次一件。