在开发现代 Web 应用程序时，将 GUI 设计与服务器端开发分离的最佳实践是什么？
我们目前正在开发一些网络应用程序，并让我们的设计师将签名的纸质原型转换为静态网页。除了页面之间有超链接之外，设计人员还开始添加 jquery 调用，通过从静态 json 文件获取数据来更新页面上的元素。一旦设计师完成并移交完成的网页、CSS 和 JavaScript 文件；然后，服务器端开发人员编辑页面，并将对本地静态 json 文档的引用替换为对返回相同 json 数据结构的实时 json url 的引用。
我的问题： 有哪些有效方法可以将 GUI 设计与服务器端开发分离并减少集成时间和工作量？一些示例：
- 您是否让开发人员手动更改设计人员原型网页中的每个 json 引用？
- 您是否在某处添加了全局变量，以使设计人员的页面能够在使用静态和动态数据之间轻松地来回切换？
- 您是否使网页能够自我感知何时从网络服务器运行或只是从某个文件夹提供服务？
We are currently developing a few web applications and are letting our designers convert signed off paper prototypes into static web pages. In addition to having hyperlinks between pages the designers have started adding jquery calls to update elements on the pages by fetching data from static json files. Once the designers are finished and handoff the completed web pages, CSS, and JavaScript files; the server-side developers then edit the pages and replace the references to the local static json documents with references to live json urls that return the same json data structures.
My question:
What are efficient ways to decouple GUI design from serverside dev and reduce the integration time and effort? Some examples:
- Do you have the developers manually change every json reference in the designers' prototype web pages?
- Do you add a global variable somewhere to enable the designers' pages to be easily switched back and forth between using static and dynamic data?
- Do you make the web pages self-aware of when they are running from a web server or just being served from a folder somewhere?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这取决于您的应用程序需要管理多少状态信息。您给出的示例仅提到来自服务器的读取操作。有写的吗？读取和写入操作都可能会失败。您的设计师是否会处理这些情况，或者服务器端团队稍后会介入并修补 GUI？
我认为最好为设计者提供服务的模拟服务器端实现。服务器模拟可以模拟现实生活中的行为，例如抛出超出快乐路径的错误和异常。如今，安装一个简单的 Web 服务器和一个充当模拟服务的脚本确实比尝试创建用于以后集成的流程要简单得多。
It depends on how much state information does your application need to manage. The examples you have given mention only read operations from the server. Are there any writes? Both read and write operations can potentially fail. Do your designers take care of those cases, or the server-side team jumps in and patches up the GUI later on?
I think it's best to provide a mock server-side implementation of your services for the designers. The server mock could simulate real life behavior as in throw errors and exceptions beyond just the happy path. It really is much less of a hassle to install a simple web server nowadays and a single script that acts as a mock service, rather than trying to create processes for later integration.
我所看到的解决整个“url/path”问题（开发、测试、生产等）相当成功的方法之一是为“proto”项目创建一个子域（因此 proto.mycoolapp.company.int）并将其作为应用程序中任何位置使用的所有 url 的基础。
最重要的是，无论您使用什么框架，都可以设置全局页面处理程序来识别所有数据文件的部分/页面/函数+[url 数据]（即 json 调用等）。
这使您可以将应用程序分成几个部分并随时构建功能，并允许 UI 团队和开发团队为其他团队提供提示。
例如，假设我有一个包含三个部分（登录、帐户管理、预览）的应用程序，我将在 proto.mycoolapp.company.int/frontend/login/securelogin?user=GrayWizardX 上有一个登录 URL 服务（数据、文件等） 。 UI 团队可以在确定需要数据时添加这些内容，并且您的应用程序开发团队可以查看正在请求哪些功能（通过服务器日志等）并确保一切都匹配。
好的部分是，当您转向生产时，唯一的变化就是找到“原型”并替换它。如果这是在您的全局变量中，那么这是一个快速而简单的更改。
One of the things I have seen work fairly successfully for the whole "url/path" problem (dev vs test vs production, etc) is to create a subdomain for your project of "proto" (so proto.mycoolapp.company.int) and have that be the basis for all urls used anywhere in the app.
On top of that using whatever framework you are using set up global page handlers to identify section/page/function+[url data] for all of your data files (i.e. json calls etc).
This allows you to segregate your app into sections and build up functionality as you go and allows both the UI team and the dev team to work on hints for the other team.
For example say I have an app with three sections (login, account management, preview) I would have a login url service (data, files, whatever) at proto.mycoolapp.company.int/frontend/login/securelogin?user=GrayWizardX. The UI team can add these as they identify a need for data and your app dev team can see what functions are being requested (through server logs, etc) and make sure everything is matching up.
The good part is that when you move to production, the only change is to find "proto" and replace it. If that is in your global var, then its a quick and simple change.
目前尚不清楚您的环境到底是什么（仅纯 html？或类似 php 之类的东西？），所以这有点盲目...
如果它是纯旧的 HTML + javascript，您可能可以使用 javascript include在每个页面上获取正确的地址集。当包含所有此环境特定信息（即使用本地或使用服务器）的包含文件保留在相同的相对位置时，您无需担心修改实际页面。只需告诉 GUI 人员始终使用同一组变量作为地址信息，并在该包含文件中定义地址信息即可。无论您是从本地获取还是从服务器获取，变量名称都不会改变，只会改变存储在变量中的值。
我的维生素咖啡含量很低，所以希望这是有道理的。
It's not real clear what exactly your environment is (plain html only? or something like php?), so this is a bit of a shot in the dark...
If it's plain old HTML + javascript, you could probably use a javascript include on each page to get the right set of addresses. When the include file with all this environment specific information (i.e. use local or use server) remains in the same relative place, you don't need to worry about modifying the actual page. Just tell the GUI guys to always use this same set of variables for the address information and define the address information in that include file. The variable names don't change whether your getting locally or from the server, just the values stored in the variables.
I'm low on Vitamin Coffee, so hopefully that makes sense.