简介面向 Delphi Web 开发者的 Intraweb 与 EasyUI 整合资源重点解决服务端逻辑与现代化前端界面如何协同工作的问题。压缩包约 4.22MB内含 EasyUI 1.4 版本 API 中文文档以及 IW 与 EasyUI 集成的示例或教程能帮助读者理解前端组件与后端逻辑如何通过 JSON/AJAX 衔接已有 474 人学习/下载。Intraweb 的组件模型让熟悉桌面开发的 Delphi 程序员可以迁移技能服务端控件负责 HTTP 处理和数据库操作EasyUI 则以配置化组件提供数据网格、下拉树、日期选择器等界面二者结合后可在页面不刷新的情况下完成数据排序、过滤与编辑。API 中文文档适合查阅组件属性、方法及使用细节集成示例则展示了从 IW 端输出数据到 EasyUI 展示、交互的完整链路。无论初学者想了解 IW 开发模式还是老手希望在现有项目中引入 EasyUI这份资料都能缩短前后端联调的上手周期。 我最早在 Intraweb 项目里硬啃前端就是因为受不了默认控件那套“能用但不好看”的交互。表格要排序得自己写、弹窗要拖拽得自己配、布局想自适应更是费劲。后来在一个后台管理项目里尝试引入 EasyUI算是给这套老框架续上了现代化的操作体验。今天就把完整的集成思路、资源处理方式、前后端数据对接模式以及我在真实项目里踩过的坑挨个说清楚。1. 为什么 Intraweb 老项目需要 EasyUI 这类前端框架1.1 Intraweb 默认 UI 的能力边界很多用 Delphi 做 Web 开发的人最初都是被 Intraweb 的“类 VCL”开发体验吸引过来的。设计期拖控件、写事件、跑起来就是网页这套流程确实让习惯了 WinForms 开发的老程序员上手极快。但真正把项目推到用户面前就会发现默认控件在视觉和交互上很难让客户满意尤其是做后台管理系统客户往往会拿一些成熟产品界面对比。表格分页样式生硬、弹窗没有遮罩和拖拽、树形结构看不出层级这些都是 Intraweb 默认控件被吐槽最多的点。Intraweb 的核心逻辑是把服务端状态和页面渲染绑定在一起每次操作都会走一遍页面生命周期。这意味着你在前端做的任何增强都必须搞清楚它和这套生命周期如何共存。直接输出 HTML 服务器端生成没问题但想引入第三方 JavaScript UI 框架就要重新考虑数据交互的方式。这也是很多人绕了一圈后选择 EasyUI 的原因——它不需要重型的前端工程化体系一个静态资源目录加几行初始化代码就能跑起来。1.2 EasyUI 能补齐哪些短板EasyUI 不是 React、Vue 那种需要完整构建链路的框架它本质上是基于 jQuery 的组件库核心优势有几点表格datagrid功能完整排序、分页、行选择、列菜单开箱即用弹窗window、dialog自带拖拽、缩放、遮罩表单form、validatebox校验规则丰富布局layout、tabs、accordion能快速搭出后台框架主题固定但清晰适合管理系统场景和 Intraweb 结合时最舒服的一点是 EasyUI 的组件数据源可以直接对接 URL返回 JSON 就能渲染而 Intraweb 完全有能力在服务端输出 JSON 响应。这意味着你不需要在 Intraweb 里强行渲染复杂 HTML只需要提供数据接口页面展示全部交给 EasyUI 来完成。1.3 集成的总体思路核心就一句话把 Intraweb 当作后端服务框架把 EasyUI 当作纯前端展示层中间通过 JSON 通信。Intraweb 继续负责会话管理、业务逻辑、数据库操作EasyUI 负责表格渲染、表单校验、弹窗交互和局部的异步刷新。这套模式不破坏 Intraweb 的既有架构也可以逐步替换不需要一次性推翻重来特别适合老项目渐进式改造。2. 让 Intraweb 正确加载 EasyUI 静态资源2.1 资源放置的常见误区很多人第一步就卡住了。直接把 EasyUI 的文件扔到项目目录下指望 Intraweb 像普通 Web 服务器那样自动映射路径结果页面打开 404。Intraweb 的 URL 路由规则和传统 Web 框架完全不同不是所有物理文件都能直接访问而是有着明确的映射规则。在老版本的 Intraweb 中更推荐的方式是使用自带的服务端资源机制通过TIWAppContext.AddToInitProc或页面模板把 EasyUI 的样式表和脚本输出到页面头部。最新版本对静态资源的支持更友好但如果你还在维护老项目用模板字符串拼接link和script标签仍然是最稳妥的方案。2.2 推荐两种可行的引入方式第一种方式是把 EasyUI 的静态文件放到wwwroot或 Web 应用的根目录下然后用相对路径在页面的Header区域引入。这种方式适合 Intraweb 版本较新、支持静态资源映射的情况。link relstylesheet typetext/css href/easyui/themes/default/easyui.css link relstylesheet typetext/css href/easyui/themes/icon.css script typetext/javascript src/easyui/jquery.min.js/script script typetext/javascript src/easyui/jquery.easyui.min.js/script第二种方式是用 Intraweb 的模板机制。在页面单元的HTMLTemplate里直接追加这些标签。好处是资源加载跟随页面生命周期不需要额外配置静态目录适合老版本用户。我个人的建议是如果你能控制服务器环境优先用静态目录映射因为 EasyUI 的图片资源图标、加载动画需要相对路径来解析模板方式在处理图片路径时要额外小心踩坑概率更高。2.3 版本选择与本地化处理EasyUI 官方已经停止大规模更新但稳定性和兼容性完全够用。建议锁版本不要随手拿最新版因为你不知道某个版本对 jQuery 的依赖会不会和你项目里的旧代码冲突。我项目里用的组合是 jQuery 1.12.4 加 EasyUI 1.9.x实测在 IE11、Chrome 和 Edge 下都没问题。做后台管理系统如果还要兼容旧浏览器这个组合是相对稳妥的。如果部署环境是内网没有外网 CDN 可用一定要把 EasyUI 的完整目录放到本地服务器包括 themes 目录下的图片。很多人只拷了 JS 和 CSS打开页面发现 datagrid 的排序箭头、树形展开小图标全部丢失排查半天才发现是主题图片路径缺失。3. 核心对接模式一个 datagrid 从数据到渲染的完整链路3.1 服务端 JSON 输出接口EasyUI 的 datagrid 默认请求 URL 后需要返回特定格式的 JSON分页场景下格式大致如下{ total: 256, rows: [ { id: 1, name: 张三, status: 启用 }, { id: 2, name: 李四, status: 停用 } ] }在 Intraweb 中要让这个接口正常工作不能走普通页面生命周期。有两种做法第一种是使用 Intraweb 的独立响应机制在页面类里写一个专门的方法把响应类型改为 JSON。具体是通过操作WebApplication的响应对象清空默认输出然后直接写入 JSON 字符串最后把ShowVersion之类的重定向行为完全关掉。关键代码如下procedure TMyForm.OutputJson(AJson: string); begin WebApplication.Response.ContentType : application/json; charsetutf-8; WebApplication.Response.Write(AJson); WebApplication.Terminate(); // 阻止 Intraweb 继续进行页面渲染 end;这里Terminate()的用法需要特别注意。通常Terminate用于结束会话但传入空字符串且不标记重定向时它可以阻止 Intraweb 继续执行后续的页面生命周期让 HTTP 响应直接返回你已经写好的内容。这也是 Intraweb 输出 JSON 的关键。第二种做法是使用独立的应用层接口配置特定的控制器来响应数据请求。这种方式的隔离性更好不会干扰页面状态的正常流转但配置成本略高。如果项目本身已经重度使用 Intraweb我建议直接采用第一种做法简单直接也容易被团队其他人看懂。3.2 前端初始化与数据加载EasyUI 表格的初始化有两种方式。一种是用 HTML 表格结构加classeasyui-datagrid声明初始化一种是通过 JavaScript 动态初始化。在和 Intraweb 配合时我更推荐用 JavaScript 动态初始化因为服务端有时需要根据条件决定是初始化表格还是显示提示信息动态初始化更灵活。在页面加载完成后写入如下脚本$(#dg).datagrid({ url: /myapp/DataGridData, method: get, rownumbers: true, singleSelect: true, pagination: true, pageSize: 20, columns: [[ { field: id, title: 编号, width: 80 }, { field: name, title: 姓名, width: 120 }, { field: status, title: 状态, width: 80 } ]] });注意 URL 的写法。Intraweb 内部的页面地址通常带appid之类的参数如果你的 JSON 输出方法定义在同一个页面类里URL 需要写成能直接命中的完整形式。比如/$myform/DataGridData这类格式实际路径取决于你的 Intraweb 版本和路由配置。这里最容易踩坑建议先在浏览器开发者工具里打开 Network 面板确认请求 URL 是否正确再看返回的数据格式是否合法。3.3 把 Intraweb 页面参数传给前端后台管理系统中表格数据经常要依赖页面上的筛选条件。比如用户选择了一个客户分类表格要按分类过滤。这时候需要把 Intraweb 服务端的值传到前端 JavaScript 中。最常用的方式是在模板或脚本里用服务端变量拼出 JSON 配置var filterCategory #{CategoryId};这是 Intraweb 模板变量替换的写法服务端渲染时会把CategoryId替换成实际值。拼好之后前端点击查询按钮时发起一次表格 reloadfunction doSearch() { $(#dg).datagrid(load, { categoryId: filterCategory }); }这样 datagrid 发请求时会自动带上categoryId参数Intraweb 服务端在Request.QueryFields.Values[categoryId]或相关参数集合中读取即可。整个过程不需要刷新页面用户体验和纯前端项目几乎没有区别。4. 实战中的坑我从「表单页 弹窗」踩出来的经验4.1 弹窗提交与页面不刷新的实现后台管理系统绕不开“点击新增弹出表单、提交后刷新表格”的场景。EasyUI 的 dialog 封装好了弹窗容器但表单提交有两种路线一种是 EasyUI 的 form 组件直接submit到一个 URL一种是前端收集数据后通过 Ajax 提交。在 Intraweb 项目里我强烈建议用 Ajax 方式明确把 JSON 提交到服务端接口然后由服务端返回成功或失败的状态码。原因有两点EasyUI form submit 依赖标准表单请求Intraweb 在服务端接收参数时要处理多个来源不如纯 JSON 直观Ajax 方式可以更灵活地在返回结果里携带额外的业务信息比如新的会话令牌、提示消息内容一个典型的 Ajax 提交实现如下$.ajax({ url: /myapp/SaveRecord, type: post, dataType: json, data: $(#ff).serialize(), success: function(data) { if (data.success) { $.messager.show({ title: 提示, msg: 保存成功 }); $(#dlg).dialog(close); $(#dg).datagrid(reload); } else { $.messager.alert(保存失败, data.message); } } });此时 Intraweb 服务端的保存方法返回 JSONprocedure TMyForm.SaveRecord; begin // 从 Request 或相关参数集合中读取字段 // 执行业务保存逻辑 if 保存成功 then OutputJson({success: true}) else OutputJson({success: false, message: 数据库写入超时}); end;4.2 中文乱码与编码处理这个问题在中文项目里几乎是必踩的。EasyUI 发送 Ajax 请求时默认按页面编码处理而 Intraweb 服务端如果没有统一编码设置容易出现中文乱码。处理分三层Intraweb 应用层把字符集设置为 UTF-8服务端输出 JSON 时明确设置charsetutf-8前端页面模板在 meta 标签中声明 UTF-8单独设置任何一层都不够三层必须一致。我在项目里曾只改了服务端编码但页面 meta 和 Intraweb 全局设置没动结果表单提交的中文正常URL 参数中的中文又乱码排查了大半天。建议动手之前先把你期望的字符流走一遍在浏览器开发者工具中观察请求头和响应头确认每一层都是 UTF-8。4.3 Intraweb 页面生命周期对前端资源的影响这是另一个高频深坑。Intraweb 的页面有一定的生命周期管理页面卸载或跳转时可能触发清理逻辑导致已加载的 JS 脚本被移除。当你在 EasyUI 弹窗里绑定事件、在关闭弹窗时做一些 DOM 操作偶尔会报xxx is undefined或者jQuery is not defined的错误多半不是代码写错而是 Intraweb 重新刷了页面局部内容。解决思路不要依赖页面局部刷新后的脚本执行时机而是在事件绑定前判断 jQuery 与 EasyUI 是否已加载完成。function ensureEasyUI(callback) { if (window.jQuery $.fn.datagrid) { callback(); } else { setTimeout(function() { ensureEasyUI(callback); }, 100); } }我在项目中把这段代码封装成公共函数所有 EasyUI 相关初始化都通过它来启动没有再出现过因页面生命周期导致脚本丢失的偶发错误。这也是做 Intraweb 前端增强时最值得养成的习惯不要假设脚本一定会按顺序加载完成。5. 进阶优化把 EasyUI 封装成 Intraweb 自定义控件5.1 封装思路与实际收益如果项目里到处都要用 datagrid每次都复制模板脚本、初始化代码维护成本会越来越高。做得更规范一点可以把 EasyUI 的 datagrid 封装成一个 Intraweb 自定义控件。设计思路是控件继承TIWCustomControl在渲染阶段输出一个table id...容器在页面初始化脚本阶段输出针对性的初始化代码暴露一些设计期属性比如数据 URL、列定义、是否分页、页面大小这样在 Intraweb 的设计界面你可以像拖普通控件一样拖出一个TIWEasyGrid在对象监视器里配好列运行后自动渲染出带分页的 EasyUI 表格。封装之后的收益非常明显。新页面要加一个表格耗时从“拷贝代码 修改列定义 调试”的 20 分钟压缩到“拖控件 配置属性”的 2 分钟而且列定义、事件回调、初始化脚本的生成逻辑统一出问题的概率大大降低。这个经验我认为是这个方案中最值得投入时间做的事。5.2 事件回传的处理方式自定义控件的另一个优势是可以封装事件回传。比如 datagrid 的“双击行”事件在纯前端场景下需要自己写 Ajax 调用而封装成 Intraweb 控件之后可以把这个行为映射为控件的OnDblClickRow事件在 Delphi 代码里直接写业务逻辑。实现方式是在前端脚本里拦截 EasyUI 的onDblClickRow回调然后调用 Intraweb 的异步回传机制把行的主键值传回服务端触发服务端事件。你不需要在页面类里手动拼接参数控件内部统一处理。这里不再展开具体实现但思路很清楚所有前端交互能统一收敛到服务端事件项目的可维护性会上一个台阶。5.3 不建议封装的场景不过要泼一盆冷水。如果你的表格列是用户可配置的、需要动态生成表头或者一个页面上有多个结构差异极大的表格封装成控件的方案反而会变得复杂。这种情况下前期直接用模板脚本反而更灵活。封装与否的边界在于组件是否负责固定的交互模式。固定的、重复的场景封装收益大高度变化的场景封装成本高。另外如果团队里前端能力比较强选择纯前端渲染数据后端只提供 JSON 接口不依赖 Intraweb 的页面生命周期也是一个值得考虑的方向。这个模式下的 Intraweb 更像一个 API 服务框架前端完全自由但代价是需要另建前端工程来维护页面复杂度会转移到前端一侧。两种路线我都实践过没有绝对的优劣关键看团队的技术构成和项目对维护性的要求。从我实际经历来看Intraweb 和 EasyUI 的组合并不算最前卫的技术栈但它真的能解决 Delphi Web 开发中长期存在的“够用但不好用”问题。如果你手头有一套老系统因为界面交互被客户反复吐槽与其推倒重来不如考虑把 EasyUI 逐步引入到新功能页面里。先跑通一个 datagrid再逐步扩展到弹窗、表单和布局整个改造过程是平滑且低风险的。这套组合我用了两年多线上项目一直很稳维护起来也没觉得比纯前端项目费劲多少。本文还有配套的精品资源点击获取
