Best way to aggregate JSP page just like we build LEGO

Question

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.

Have you checked JSP's successor Facelets? It's XML based and offers magnificient templating possibilities. Here's an entry point to several examples: http://stackoverflow.com/questions/6822000/when-to-use-uiinclude-tag-files-composite-components-and-or-custom-componen/6822269#6822269 Obtaining data from different sources should only be delegated to backing beans. — BalusC, Dec 19 '11 at 20:56
@BalusC - should I? There's no irony in my words, not at all! You are a person who know really a lot about java development, so should I? Is it worth trying to learn Facelets and always use them instead of jsp? — shabunc, Dec 19 '11 at 21:16
In JSP your best "XML bet" would be using [JSPX](http://docs.oracle.com/javaee/5/tutorial/doc/bnajq.html) (also called "JSP Document") and/or the [JSTL](http://stackoverflow.com/tags/jstl/info) [XML taglib](http://docs.oracle.com/javaee/5/jstl/1.1/docs/tlddocs/x/tld-summary.html). JSPX isn't really as great as Facelets and JSTL XML taglib is discouraged for other purposes than prototyping because it tight-couples controller with the view. — BalusC, Dec 19 '11 at 21:24

score 0 · Answer 1 · answered Dec 19 '11 at 21:25

0

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.

answered Dec 19 '11 at 21:25

Dave Newton

158,873
26
254
302

can you name you favorite framework, and I'll try to find out what approach is used there? – shabunc Dec 19 '11 at 21:59
@shabunc I'm pretty framework-neutral; relatively recently I've used Grails, Rails, Spring, Struts 2, and Front Man. (And a little JSF.) Grails, Spring, and Struts 2 are all pretty similar--data is aggregated from one or more services and exposed as request or session attributes. Except Front Man (*very* light-weight) they all support type conversion in one way or another. – Dave Newton Dec 19 '11 at 22:05

score 0 · Answer 2 · answered Mar 09 '12 at 20:57

This is the way we are building layout in when we are thinking in xslt [.....] so, that was the approach I've constantly tried to implement in servlets/jsp world

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.

Best way to aggregate JSP page just like we build LEGO

2 Answers2