跨多个离散Web应用程序的UI呈现控制

时间:2010-07-03 23:44:30

标签: web-applications

我们公司目前有7个独立的面向互联网的大型网络应用程序 他们都有以下

  • 具有不同的外观和感觉,代表了它们构建时的品牌风格
  • 根据构建时间有不同的UI和后端框架
  • 支持和开发每个
  • 的独立团队
  • 建立在不同的时间轴上 - 有些长达10年以上

这会出现以下问题

  • 新的品牌变化需要单独应用 - 这是非常昂贵的,通常不会发生
  • 辅助功能问题或其他广泛的错误存在同样的问题
  • 新样式和互动指南需要单独应用 - 同样问题

我正在寻找其他人在类似环境中使用的技术,以便新的应用程序可以单独构建和维护,客户端UI仍然可以集中管理而不会成为瓶颈。 我正在考虑采用与白色标签相同的方法,其中生成和版本化主HTML / CSS / Javascript模板。然后由每个团队在可用时采用更新版本并在构建期间合并。它永远不会被更新的风险仍然存在。 我猜这对大公司来说并不是一个不寻常的情况(我们在金融领域)。你能和我分享一下你用过的技术和技术框架吗?

也对该主题的任何文献(书籍或网站/博客)感兴趣。

2 个答案:

答案 0 :(得分:0)

你认为没错,掌握Javascript / CSS资源是可行的方法。它们可以很容易地更新,并且您不必重新键入常用函数等。如果您有一种类型的脚本,例如script.aculo.us或jQuery,那么经常使用的函数可以在保存带宽的同时保持最新。

例如,基于视图的应用程序(例如游戏,复杂程序)加载并显示可能包含交互式HTML,图像等的不同“视图”。在视图之间转换,显示和转换的操作几乎是通用的,只需要声明一次。这也使得更容易开发和关注内容而不是重复的基本编码。另一种方便的技术是在整个应用程序中加入一个共同的“结构”;像图标,声音和视图之类的东西可以在包/目录中具有预定的“位置”,这是简单的拖放。根据我的经验,在处理简单的javascript文件时,瓶颈并不是真正的问题。 300KB。

当涉及服务器端操作时,唯一的麻烦就存在了。它们是绝对必要的,特别是对于金融,游戏(登录,帐户,高分)。但是,尝试创建方便的通用服务器端脚本并不是一个好主意。当服务器必须过滤几千个分数(或帐户)并具有其他功能(也同时请求)时,它们会变慢并导致瓶颈,从而减慢一切。这里的诀窍是有许多低功能脚本可以有效地执行任务,这仍然是多用途的。

基本上,创建和维护大量应用程序需要大量组织 - 但仅限于一开始。一旦你有了一些可以继续发展的东西,你就可以了。

答案 1 :(得分:0)

我认为Sitemesh将是一个很好的工具供您查看。这允许您可以从单个Sitemesh Web应用程序控制多个站点的白色标记。

请参阅此链接http://www.opensymphony.com/sitemesh/

上的可视示例图