就像我们搭建乐高一样聚合 JSP 页面的最佳方式
经过多年基于 XML/XSLT 的开发，我来到了 Java 世界，并且我逐渐变得越来越怀疑 - 看起来我错过了 Java Web 应用程序构建思想中真正重要的东西。
当我们以 xslt 方式思考时，这就是我们构建布局的方式：我们将所需的所有数据聚合在一个 XML 文件中，该文件可以转换为 html 布局。
在某些说明性的基于伪 XML 的语言中，它可能看起来像这样：
<data xmlns:x="..." xmlns:xi="...">
<x:get url="http://ourrestapi.net/rrrrrest" xpath="/rest/rest/rest[2]">
<x:param name="sortBy" value="desc" />
</x:get>
<x:get url="http://ourrestapi.net/userdata">
<x:guard test="authorized">
<x:param name="login" value="john" />
</x:guard>
</x:get>
<xi:include href="common.xml" />
</data>
我想这足以说明这个想法。 这就是我不断尝试在 servlet/jsp 世界中实现的方法。 毫不奇怪，问题归结为一个问题，我相信这是一个经典的 jsp 新手问题：“如何在 jsp 页面包含 servlet 输出？”
正确的答案是（如果我错了请纠正我）——我不应该。我应该使用请求链。据我了解（如果我混淆了事实，请再次纠正我），这意味着我应该调用 servletA，它将适当的数据放入当前请求，然后将其转发到 servletB，依此类推。最后，我们重定向到填充了所有属性的页面。
对于我来说，我至少可以指出这种方法的两个主要困难：
- 我应该在某个地方保留重定向的顺序。 servletA 现在是否应该重定向到 servletB，或者某些不知道监督对象应该完成这项工作。
- 如果我们将所有内容存储在请求属性中（作为字符串），以防万一我们需要根据 servletA 中获取的数据对 servletB 调用进行参数化，我们必须提供一些繁琐的序列化/反序列化工作。
所以，我的问题是 - 从多个不同来源向 JSP 页面添加数据的最佳方法是什么。
如果这些问题对于经验丰富的 JSP 开发人员来说听起来很愚蠢，请原谅，事实是 Java 世界确实非常庞大且成熟，因此找出真相并不总是那么容易。
I came to java world after many years of XML/XSLT based development, and I'm gradually getting more and more suspicious - it looks like I'm missing something really important in java web app building ideology.
This is the way we are building layout in when we are thinking in xslt way: we aggregating all the data we needed in one XML file, which can be transformed into html layout.
In some illustrative pseudo XML-based language it can look something like this:
<data xmlns:x="..." xmlns:xi="...">
<x:get url="http://ourrestapi.net/rrrrrest" xpath="/rest/rest/rest[2]">
<x:param name="sortBy" value="desc" />
</x:get>
<x:get url="http://ourrestapi.net/userdata">
<x:guard test="authorized">
<x:param name="login" value="john" />
</x:guard>
</x:get>
<xi:include href="common.xml" />
</data>
I guess it is enough to illustrate the idea.
So, that was the approach I've constantly tried to implement in servlets/jsp world.
No surprises, the issue boiled down to the question, which, I believe, is a classical jsp newbie question: "How can I include servlet output at jsp page?"
The correct answer is (correct me if I'm wrong) - I shouldn't. I should use request chaining. As far as I understand (once again, correct me if I'm confusing facts) that means I should call servletA, which put appropriate data to the current request and then forwards it so servletB, and so on. At the end we a redirected to the page with all attributes filled.
As for me, I can name at lest two major difficulties with this approach:
- I should keep somewhere the order of redirects. Whether servletA should now it should redirect to servletB, or some, don't know supervising object should do the job.
- If we are storing everything in request attributes, as Strings, in case we need to parametrize servletB call regarding to data we've get in servletA, we have to provide some tedious serializing/deserializing work.
So, my question is - what is the best approach to add data to JSP page from several different sources.
Excuse me if these questions sound stupid to seasoned JSP developer, the fact is java world is really, really huge and mature, so it is not always easy to find out the truth.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我不认为 servlet 链接是一种非常流行的填充请求数据的方法，特别是使用重定向，因为这会清空您的请求。
一般来说，无论使用什么后端框架（通常也不再是 servlet）都会公开来自一项或多项服务的数据。
是什么让您认为请求属性需要是字符串？它们可以是您想要的任何类型。请求参数、来自 JSP 的数据将是字符串，并且必须使用某种形式的类型转换来从请求参数创建域对象。大多数框架都以一种或另一种形式内置了此功能。
I don't think servlet chaining is a very popular way to populate request data, particularly using redirects, since that would empty your request.
Generally whatever back-end framework being used (not usually servlets anymore, either) will expose data from one or more services.
What makes you think request attributes need to be strings? They can be any type you want. Request parameters, data coming from the JSP, will be strings, and some form of type conversion must be used to create domain objects from request parameters. Most frameworks have this functionality built in in one form or another.
为什么？ Java 和 XSLT 是不同的东西。您这样做是因为您的应用程序是以 XML 为中心的，并且 XSLT 为您提供了处理它的能力，还是仅仅因为您的大脑固定在 XSLT 思维模式中？
如果您的应用程序的核心是 XML 并且您的方法是合理的，那么也许可以看看 Apache Cocoon 谁应该能够处理 XML 管道。评论中还提到了一些其他框架，所以我将指出 Spring 的一个方面：它有 XSLT 视图。
如果您的数据不容易转换为 XML，但您这样做是为了可以使用 XSLT 处理它，只是因为您比 JSP 更熟悉 XSLT，那么您就错了。
至于从多个来源收集数据，servlet/JSP 链接并不是一个好主意。这些是低级组件，（正如您自己注意到的）需要外部协调来创建应用程序工作流程。通常，Servlet/JSP 由构建在它们之上的 Web 框架进行协调。
Java Web 框架主要是 MVC，因此在 MVC 中，您将在模型中收集数据（模型包含业务逻辑和协调以类似于数据），然后将其发送到控制器，控制器将选择适当的视图来呈现数据。如果您的数据确实是 XML（或可以轻松转换为 XML），那么此时 XSLT 视图可能会有所帮助（JSP 并不是真正设计用于处理 XML）。
正如您自己所说，Java 世界“非常非常庞大且成熟”，因此您可以通过多种方式解决这个问题（即有多种方法可以剥猫皮）。最终需要合并 JSP 片段吗？ Sitemesh怎么样，Apache Tiles，自定义 JSP 标签，甚至 Portlet....您可以使用许多框架、库等。
但无论您最终选择什么解决方案，只要确保使用 Java 思维方式来实现它即可。
Why? Java and XSLT are different beasts. Are you doing this because your application is XML centric and XSLT gives you the power to process it or is it just because your brain is fixed in the XSLT mindset?
If your application has XML at its core and your approach is justified, then maybe have a look at Apache Cocoon who should be able to handle XML pipelines. There were also some other frameworks mentioned in the comments so I'll point one aspect of Spring: it has XSLT views.
If your data is not easy to transform into XML but you are doing it so you can process it with XSLT just because XSLT is more familiar to you than JSPs are, then you are doing it wrong.
As for collecting data from multiple sources, servlet/JSP chaining isn't such a great idea. Those are low level components and (as you noticed yourself) need external coordination to create the application workflow. Usually Servlets/JSPs are coordinated by web frameworks built on top of them.
Java web frameworks are mostly MVC, so in MVC you would be doing the data collecting in the Model (model contains the business logic and coordination to resemble the data), send it then to the Controlller who will select the appropriate View for rendering the data. If your data is indeed XML (or easily convertable to XML) then at this point an XSLT view could help (JSPs weren't really designed to handle XML).
As you said it yourself, the Java world is "really, really huge and mature" so you can tackle this problem in many ways (i.e. there are many ways to skin a cat). Need to eventually merge JSP fragments? How about Sitemesh, Apache Tiles, custom JSP tags, heck even Portlets.... lots of frameworks, libraries, etc that you could use.
But whatever solution you eventually choose, just make sure you use a Java mindset to implement it.