如何使我的 JSP 项目更易于设计人员使用
我有一个 Java/Spring MVC/JSP/JSTL 网络应用程序。我们有一位设计师为我们提供了一些开始的页面，但他已经落后了，所以我们必须自己创建一些页面，显然随着项目的进展，其他 UI 内容也发生了变化。我认为他落后的原因之一是他很难与该网站合作。
我们还没有为他设置开发环境，因为他的盒子上包括数据库、Eclipse 和 Tomcat，我担心我们会花费过多的时间来支持他的开发环境，而他仍然一事无成。另一方面，他基本上已经有了糟糕的经历，我花了时间接受他的更改（查看源代码、更改、通过电子邮件发送给我）并尝试找出更改的内容并将它们复制回 JSP 文件中。
我想明天晚上我会硬着头皮看看能否为他安装一个环境，但一定有更好的方法......它是什么？
I have a Java/Spring MVC/JSP/JSTL webapp. We have a designer that gave us some pages to start with, but he's quite behind so we had to create some pages on our own, and obviously as the project has progressed other UI stuff has changed. I think one reason he's behind is because it's hard for him to work with the site.
We haven't setup a development environment for him because that would include a database, Eclipse and Tomcat on his box and I worry that we would then spend an inordinate amount of time supporting his development environment and he would still get nothing done. On the other hand, he's basically already had a bad experience and I've spent time taking his changes (view source, change, email to me) and trying to figure out what changed and copy them back into the JSP files.
I think tomorrow night I'm going to bite the bullet and see if we can get an environment installed for him, but there's got to be a better way... What is it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果设计者没有Java经验，我认为他不应该首先制作实体页面。设计师应该负责页面布局和功能流程，后端开发人员将其用作指南（Web 应用程序如何组合在一起以及每个页面如何工作的故事板）。即设计师需要负责需求的视觉实现。
开发人员应该生成包含所有所需数据的快速脏页。擅长布局的设计师应该将这些页面制作成成品。这样就可以很好地划分责任。设计人员有时需要与开发人员密切合作，以获取可行格式的数据，但一旦这么多东西已经就位，作为一对工作（设计人员/开发人员结对编程）有时会变得相当经济。
如果这种类型的开发将成为常态，那么设计人员应该学习 Web 应用程序前端，因为设计人员应该了解站点网格等工具，并熟悉一些 JSP 标记库。
如果您要使用 REST/ajax 重型应用程序：那么您可以更好地分离关注点，因为设计人员可以在开发人员提供服务时创建页面。这可以减少对完整开发环境的需求，但我不认为否定它。设计人员需要能够阅读底层代码，了解 JSP 所暴露的内容才能最有效地工作。
If the designer has no Java experience, I don't think he should be making solid pages first. The designer should be in charge of page layout and functional flow, which the back end developers use as a guide (a story board of how the web application fits together and how each page works). That is the designer needs to be responsible for the visual implementation of the requirements.
The developers should produce quick and dirty pages with all the required data. The designer who's strength is in layout should then make those pages into the finished product. This way there is a good division of responsibility. The designer will need to work closely with the developers at times to get data in a format that is workable but once so much is already in place, working as a pair (designer/developer pair programing) at times becomes reasonably economical.
If this type of development will be the norm then the designer should learn the web application front end since the designer aught to know about tools such as site mesh and become fluent with a few JSP tag libraries.
If you are going with REST/ajax heavy applications: Then you can get greater separation of concerns as the designer can create pages as the developers make services available. This could reduce the need for a full development environment but I don't think negate it. The designer will need to be able to read the underlying code to know what is exposed to the JSPs to work most effectively.
我发现设计人员最好基本上生活在 HTML 中，而让 JSP 留在 JSP 中，而 JSP 开发人员则负责保持页面与设计人员保持同步。
这基本上意味着设计者负责用纯 HTML 创建完整的、功能性的页面。理想情况下，设计人员在 JSP 编码人员方面拥有良好的开端。设计人员已经解决了导航问题等。
如果页面上有动态元素，那么设计人员需要为 JSP 编码人员提供所有正确的表现形式。这可能需要“相同”页面的多个副本，但每个副本都具有不同的动态视图。
设计者应该做笔记或使用一些其他约定来识别他认为是动态的页面元素（可能不仅仅是 INPUT 标记的内容，还可以是快捷方式 id 等其他内容）。
理想情况下，设计人员将识别并坚持使用逻辑代码块（如导航区域、侧边栏和其他镶边）。这使得 JSP 人员可以更轻松地使用包含或标记文件或其他内容重构他们的页面。
然后，JSP 人员获取这些功能性但静态的 HTML 页面，并负责添加动态元素而不破坏页面。如果他们遇到破坏布局的问题（比如某个列变得很大）并且需要解决，他们可以将生成的 HTML 发送给设计人员，以便他们可以更正它，而无需设置他们的拥有服务器或了解该生命周期。
额外的好处是确保您拥有两个组都可以访问的共享测试服务器。该服务器应该托管 HTML 和 JSP 页面，它有助于确保您在正确的位置拥有外部资源，使用正确的名称等。
例如，如果编码器进行了破坏页面的更改，他可以将生成的 HTML 文件上传到此服务器，它应该像 JSP 页面一样呈现。这让每个人都能“就地”看到它。设计者甚至可以修复生成的 HTML 文件（如果他们认为这是最简单的）。原始编码人员需要保留旧副本，以便他们可以在必要时执行比较以找到更改。通常，假设设计者正确地传达了他们的变更，那么这些变更是相当明显的。
另一方面是基本上确保您遵循真正良好的 HTML 实践，特别是语义标记、大量 CSS 等。
这是因为如今，HTML 页面的许多问题与其说是在标记中，不如说是在CSS。 JSP 人员通常不需要使用 CSS 文件。这使得设计人员可以就地进行更改，以便更轻松地进行修复。它还使标记尽可能整洁和稀疏，这再次允许 JSP 人们更容易地捕获文档中的更改。
如果您经常使用 Ajax，那么设计人员应该使用可以轻松替换为“远程”数据源的“本地”数据源。这使页面代码保持不变，并且要求 JSP 编码人员简单地交换数据源实现以访问其服务器而不是静态数据。
设计师在最初的页面上走得越远越好。该游戏将负担留给了设计师，让他们即使只使用静态文本来创建功能性的、“功能完整”的页面。这使得设计人员可以驱动项目，而 JSP 人员只需将其自动化即可。尝试确保主要的设计变动在页面开始影响 JSP 编码人员之前就由设计师和项目所有者尽早完成，只是为了将更改保持在沉闷的轰鸣声中，让 JSP 人员在设计师后面前进，自动化和边走边填空。
I found that it's best that the designer basically live within HTML and let the JSP stay in JSP, with the JSP developers picking up the labor tab for keeping their pages up to date with the designer.
That basically means that the designer is responsible for creating complete, functioning pages in pure HTML. Ideally, the designer has a solid head start on the JSP coders. That the designer has worked through navigation issues, etc.
If there are dynamic elements on the page, then the designer needs to present all of the proper renditions for the JSP coders. This may require as much as several copies of the "same" pages, but each with a different dynamic view.
The designer should make notes or use some other convention to identify in the page elements that he feels are dynamic (could be not just the contents of an INPUT tag, but also other things like shortcut id's and such).
Ideally, the designer will identify, and STICK WITH, logical blocks of code (like navigation areas, side bars, and other chrome). This lets the JSP guys more easily refactor their pages using includes or tag files or whatever.
The JSP folks then take these functional, yet static, HTML pages, and are responsible for adding the dynamic elements and not breaking the pages. If they run in to issues that break the layout (say a column goes to big of something like that) and it needs to be addressed, they can send the generated HTML to the designer so they can correct it without having to ever set up their own server or understand that lifecycle.
An added bonus is to make sure that you have a shared test server that both groups can access. This server should host both the HTML and the JSP pages, and it helps ensure that you have the external resources in the right places, using the right names, etc.
For example, if a coder does a change that breaks a page, he can upload the generated HTML file to this server, and it should just render like their JSP page would. This allows everyone to see it "in place". The designer could even fix the generated HTML file if that's what they feel is easiest. The original coder would need to keep the old copy around so they could perform a diff if they had to in order to locate the change. Usually the changes are reasonably obvious assuming the designer communicates their change properly.
Another aspect is to basically make sure you're following really good HTML practices, notably semantic markup, lots of CSS, etc.
This is because nowadays, much of the issues with HTML pages are not so much in the mark up as they are in the CSS. The JSP folks generally don't need to work with the CSS files. This allows the designer to make changes in place in order to make fixes much more easily. It also keeps the markup as neat and sparse as practical, again this allows the JSP folks to more easily catch changes in documents.
If you're Ajax heavy, then the designer should be using "local" data sources that can be readily swapped out with "remote" data sources. This keeps the page code the same, and requires the JSP coders to simply swap out data source implementations to hit their servers rather than static data.
The farther along the designer is with their initial pages the better. The game is leaving the burden to the designer to create functional, "feature complete" pages even with just static text. This lets the designer drive the project while the JSP guys are simply automating it. Try to ensure that the major design swings are done early solely by the designer and project owners before the pages start hitting the JSP coders just to keep the changes down to a dull roar and just let the JSP guys march along behind the designer, automating and filling in the blanks as they go.