web调用本地应用程序
您访问的绝大多数网站都可以访问Internet,但是许多公司已经发现Intranet开发是有其用途的。 但是,您可以更进一步-可以开发功能完善的Web应用程序,这些应用程序永远不会通过网络接口发送这么多的数据包。 当一个简单的CGI脚本可以很好地满足他们的需求时,经验丰富的Web开发人员有时会发现自己在努力学习GUI工具包。
如果有的话,仅本地的Web应用程序比面向一般用途的Web应用程序要简单得多。 您可以轻松设置浏览器要求,并且服务器性能不太可能成为问题。 使用标准CGI表单窗口小部件等的简单应用程序可以在开发独立应用程序所需的时间的一小部分内编写。 围绕表单或数据处理构建的应用程序通常是将其实现为普通Web服务的绝佳候选者。
在许多情况下,像这样的自定义应用程序可以为非常具体的问题提供优雅而简单的解决方案。 我曾经写过图片浏览器,除了浏览相机中充满文件的单个目录外,什么也不做,让我将图片分类。 这可能要花20行Perl,并且结果要比更通用的解决方案快得多,更不用说编写GUI应用程序完成相同操作需要多长时间了。
无论如何,Web浏览器为我们做了什么?
您可能会很合理地问,为什么有人会打扰? Web浏览器做什么,而另一个应用程序做不到? 答案很明显:什么都没有。 但是,那么,您在机器代码中不能做什么高级语言呢? 真的没什么。 使用Web浏览器作为界面的优势在于,所有硬代码都已经被编写。 您不必四处寻找调整大小事件,窗口暴露事件或菜单事件。 您要做的只是读取表示请求的数据块并进行处理。
基于Web的开发的潜在弱点是对外观的控制不足。 这并不是一个很大的弱点。 如果您想快速开发应用程序,那么最后要做的就是花很多时间弄乱外观。 无论您使用哪种平台,Web浏览器的本机按钮和文本小部件都将为用户所熟悉。 确实,这是一个功能。
Web浏览器还有另外一件非常有用的事情:它为您提供了一些不需要您自己维护的首选项设置。 字体大小可以由用户即时更改。 同样,如果您可以用一种漂亮,简单HTML格式生成输出,则可以轻松,快速地打印输出。 为您实现了您可能必须实现的许多功能(将输出保存到文件,打印输出和调整窗口大小只是一些示例)。
单用户架构
尽管似乎单用户环境完全消除了许多应用程序开发方面的考虑,但事实并非如此。 我最近写了一个文档归档系统作为Web应用程序。 因为我是为最多同时使用一个用户而设计的,所以我可以省去很多本来可能需要的文件锁定代码。 我错了。 用户界面使用框架,如果另一个程序在运行时修改了数据库,则我的显示程序执行的完整性检查之一可能会灾难性地失败。 浏览器通常最终会同时运行两个查询。
本地服务器意味着网络带宽不是问题。 即使在以太网上可能会出现问题的地方,在本地主机上也不是问题,尽管巨大的文件仍然会降低浏览器的速度或使浏览器崩溃。
网络安全
如果要开发要在本地Web服务器上运行的应用程序,请考虑以下问题:当其他人通过网络访问该应用程序时会发生什么。 理想情况下,请确保只能在本地网络接口上访问本地应用程序。 如果无法做到这一点,则将需要某种安全性。 仅仅让您的应用程序拒绝127.0.0.1以外的所有连接就足够了,这比基于密码的安全性要安全得多。
仅选择一个备用端口号可能是合理的,这样您就可以为应用程序配备专用服务器。 在UNIX®类型的盒子上,在端口8880上设置Apache的个人副本将花费几分钟,并使您可以完全控制服务器功能和设置。 它还可以确保您的应用程序后端以您通常的特权运行,因此您不必使关键文件在世界范围内都可写,这是一大优势。
数据管理
对于传统的Web应用程序,在后端使用数据库服务器极大地简化了开发,因为数据库引擎(仅作为单个服务器)就提供了所需的大部分序列化和锁定,并且可以轻松获得更多。 对于将要在单台计算机上运行的单用户应用程序,这可能是过大的选择,可能不值得为此烦恼。 本地应用程序可能不需要这样做,并且可能会受益于使用简单易行的数据文件。 每当我去任何地方时,我都会在笔记本电脑和台式计算机之间移动文档归档应用程序。 这很简单,因为它仅使用了Berkeley DB文件。
Berkeley DB格式提供了一个相当简单的解决方案,可以轻松地从多种语言中进行访问。 因为不涉及数据库服务器,所以对于同时有许多用户的应用程序来说,这是一个糟糕的选择。 为了安全起见,您必须锁定数据库,执行操作,然后再将其解锁。 另一方面,由于不涉及数据库服务器,因此对于同时用户很少的程序来说,这是一个不错的选择。
这是附加到Berkeley DB数据库的示例Perl代码,并带有锁定功能:
清单1:附加数据库
my %db;
open(DBFILE, '+file.db');
flock(DBFILE, LOCK_EX);
$dbhandle = tie %db, 'DB_File', 'file.db', O_CREAT|O_RDWR, 0666, $DB_HASH;
运行此代码后,您可以作为标准Perl哈希直接访问数据库:
清单2:使用数据库
$db{user} = "me";
print "<p>User: $db{user}</p>\n";
您还可以使用dbhandle
对象对数据库执行操作:
清单3:使用数据库句柄
$dbhandle->del("user");
完成后,就完成了-也就是说,当程序退出时,该锁会自动删除。 flock()
锁定纯粹是建议性的-如果其他程序不使用它,它不会阻止其他程序将其写入文件。 如果您的程序是作为许多相关程序实现的,请将锁定代码放入所有这些程序中,或者更好的是,将其放入共享模块中。 这样,纯粹的咨询锁定仍然可以为您提供所需的信息:可靠的保证,一次仅一个程序正在修改数据文件。
某些应用程序可以很好地处理纯文件,例如CSV文件或纯文本文件。 有些可能需要完整SQL数据库。 不要为小型应用程序而采用“企业级”解决方案,而这些应用程序旨在快速而轻松地完成工作。 节省精力以实现良好的错误恢复和便捷的功能。 就是说,如果您需要一个关系数据库,请使用一个。
界面小部件
使用其中包含许多按钮的表单,可能可以很好地解决应用程序。 如果您有需要从一页传递到另一页的元数据或上下文,请继续使用隐藏的表单字段; 在这种情况下,您可能会遇到的安全问题(用户可以覆盖它们)不是问题。 您可以将图像按钮用于多种用途,尽管它们确实需要您开发图像。 如果要绕过此操作,请创建一个带有替代文本和无效URL的图像按钮:
清单4:没有GUI小部件的纯文本按钮:
print $q->image_button(-name => "sort",
-value => "$name",
-src => "/nonexistant",
-alt => $label);
与仅使用超链接的更简单替代方法相比,这似乎很荒谬,但是在较大的形式中,相应的href=...
链接可能会很大,并且如果按钮提交表单,则实际上无法进行预先计算。 这是一个丑陋的骇客,但确实有效。
一次性申请
如果您编写了几个小型的本地主机Web应用程序,您会很快注意到:它们即使编写也常常足够快,甚至具有调试功能,比手动执行常见任务要有效得多。 简化冗长或繁琐的过程所获得的效率提高可能很容易地偿还可能仅需几分钟即可开发的应用程序的开发时间。
Perl的标准CGI库提供了许多有用的基本工具。 经过几个小时的试用,并习惯了其极其灵活和丰富的功能集,您可以轻松编写各种应用程序。 就像简单的脚本系统可以使一次性命令行脚本实用且具有成本效益一样,简单的CGI脚本可以使各种图形程序实用且具有成本效益。 如果您花了一个下午玩这些游戏,您会很快发现,希望某人编写程序的许多任务很容易掌握。
扩大
令人不安的常见经验是编写一个小型,简单,一次性的应用程序,很可能只供本地使用,然后发现有一个令人信服的理由将其扩展到更大的受众。
即使仅在本地使用应用程序,也要编写干净的代码,并具有大量的检测和调试输出。 良好的代码以及对调试的良好支持会很快收回维护成本。 当您增加了需要为更大的(复数!)观众重新编写应用程序的可能性时,它会带来更大的回报。
重构可能需要大量工作,但是还没有您想像的那么糟糕。 在大多数情况下,这将意味着扩展实际的后端数据库或文件操作,以实现更好,更智能的锁定。 如果您的程序执行文件操作,则可以考虑编写一个小型服务器,以原子方式处理这些操作,从而保证序列化。 只要单个脚本快速运行,这样的服务器一次只处理一个客户端就很有意义。
您需要注意的主要事情是一个假设内部状态有关的程序。 例如,在文档分类程序中,显而易见的事情是向用户显示“下一个文件”,然后对其进行适当归档。 对于拥有两个用户的用户,您需要跟踪每个用户正在处理的文件,以及某种处理极端情况的方法-如果有人打开应用程序,然后在某个时候徘徊,您将需要让其他人查看其中的文件。题。 有时,这可能涉及对后端的大量返工,但通常很容易保持用户可见的前端稳定。
翻译自: https://www.ibm.com/developerworks/opensource/library/wa-localwebsrv/index.html
web调用本地应用程序