tags:

views:

140

answers:

5

I'm a big fan of keeping application logic in the servlet, and keeping the JSP as simple as possible. One of the reasons for this is that any good web designer should be able to expand upon his HTML knowledge to build in a few JSTL tags to do simple iteration, access beans, etc. We also keep the more complex/ajax/js components behind a tag library (similar to displayTag but for our own components).

Most of the time everything works out ok - The servlet does any SQL it needs to, and stores the results in beans for the JSP to access. Where we have a problem is when the records we wish to access are specified by the design.

The clearest example would be the home page - it needs to be eye-catching and effective. It doesn't need to be uniform like rest of the site. There are lots of one-offs or "special cases" here, where we want to query a particular product record, or whatever.

What the designer really wants is a way to get a product bean by the product id so he can access the properties as normal. We obviously don't want to query for all products, and I don't want to query in the presentation.

I'm pretty sure I'm asking the impossible here and that I have to give something up. My question is what?

EDIT

Am I wrong in thinking that all application logic should be complete before calling the JSP? I was under the impression it was considered best practice to do all querying/calculating/processing in the servlet then pass (fairly) dumb beans to a (very) dumb JSP.

There are a couple of methods whereby the actual complexity of the query can be encapsulated in another class (custom tag or bean), and the JSP can call it. This keeps the JSP simple (goal 1) but the JSP is still "triggering" the query - quite late in the process.

  • Have I got this totally wrong and it's fine to do this.
  • Is it a general rule, but perfectly ok to do this in this instance.
  • Might I run into problems?

EDIT - Example

I'm hoping this example will help:

The home page isn't a "template" like the category/search pages - it is custom designed to work very well with say a marketing image and a couple of specific product images. It does however have information about those two products which should be obtained dynamically (so the name, and importantly price) stay in sync with the db.

The servlet can't know which products these will be, because if the designer wants to change them/remove them/add more, he should only have to edit the JSP (and possibly XML as one answer suggested).

A: 

I am not sure what is the question. I f you want to have sql statements out of your jsp pages then you can put them in a property file and just read the property file from the jsp page.

Luixv
Even if I put the SQL itself in a property file, the logic would still be in the wrong place. The querying should be done from the servlet (or helper) before the JSP is called.
Draemon
+1  A: 

It sounds like you need better separation between the display and database code. You should have separate classes that just deal with interacting with the database, and know nothing about display.

Then you just create a method that will look up the product by id and return that bean so the display can pull out the attributes it wants.

James Black
I already have classes which deal solely with the DB, then the servlets simply do whatever "Actions" are required and forward the results to the JSP for display. The problem is it's the JSP that "knnows" the product id, but I don't want it calling the DB classes because the JSP is "too late" in the process.
Draemon
Then you can just write a controller class that is an abstraction between the db class and the jsp, and the jsp will just call the controller, and the controller will determine what to do to get the information neeed, even if that means calling several db methods.
James Black
+1  A: 

You need to create a custom bean which will perform your queries for the front end. Actually, it's probably more like a few beans to get the data for you, according to what you say here.

There's no problem with doing that from a design perspective; it's just that the specific design of the home page has more heterogenous requirements than the rest of your site. Make sure your designer knows that he needs to communicate his needs well to the development team to create the BO for your homepage (or whatever) and thing should go fine.

McWafflestix
Hmm...sounds interesting. Let me see if I have this right. I pass a bean (or a few) from the servlet to the JSP and this bean has home-page specific methods which (eg) take a product id and return a product bean.That's fine, but it means the JSP is still *triggering* the query, which I thought was a no-no. I was under the impression that All the application logic should be done by the time the JSP is called?
Draemon
I'm not really sure where you got that impression that the app logic all needs to be done by the time the JSP is called; that seems a little odd to me. And in any event, is there any reason why your bean cannot have "default" query parameters built into it for your home page display?
McWafflestix
Making a request for data using bean accessors ('triggering') is not the same thing as implementing the data access logic. McWafflestix has given you the answer.
+1  A: 

If I understand correctly, you have logic in the JSP that wants a particular product, but at this point you don't want to query from the DB, and its too late for the servlet to be aware of it.

(A side note, while I respect your will to maintain separation of concerns, the fact that this is an issue clearly shows that your framework has too much logic in the presentation tier...but since we probably can't fix that...moving on).

My recommendation is that your designer creates a configuration XML file that contains whatever special cases it needs for the frontend, and yours servlet can read that, then pass dumb beans back to the JSP.

OR...you break things down into multiple requests using XMLHTTPRequest and call back to the servlet for each individual query, then assemble the page on the client.

FlySwat
On your first sentence: Yes, exactly.Could you explain why you think I have too much logic in the presentation tier? It's pre-launch, and quite small, so if there really is an issue I'd like to fix it. I don't *think* there is, but I'd like to confirm it.The real issue is that the choice of products (in this one isolated case) are part of the presentation. I like the xml idea - the designer can control that and the JSP. I'll weight it up against just having a custom bean.Ps. AJAX would be madness!
Draemon
I'm picturing a homepage that has some kind of logic that picks like "3 featured products" and displays them. Let me know if thats way off. In that case, I'd have logic in a servlet that does this, and passes a container (Bean I guess, I'm not a big java guy) to the frontend. All the frontend would do is bind its data to it.
FlySwat
You're right, but the designer is the one who choses these products. They're not "featured" in a generic sense, but will have specific images (not in the db) tied in very closely with the design of the home page, so I don't think it makes sense to have the servlet "know" these product ids.
Draemon
+1  A: 

You are not wrong in thinking that all application logic should be complete before rendering the JSP.

If there is a need to fetch more stuff for displaying in your JSP, it would be another request to the server and another Page cycle. If you are looking for 'interactive' loading experience, you could use AJAX.

In a single page life-cycle, I find it hard to understand why do you have to invoke database calls from a JSP. Hasn't the page been previously posted with all the required form variables to help you find the data in Servlet/Helper classes?

If you could give an example of a case, it would be helpful.

[Edit] Looking at your example, yes your designer (or the admin of the site) should set that information as a configuration, not a part of JSP. Or, you could have a small app/admin page to maintain the information in a database so that it could be changed on the go. When you show your homepage, read the configs and load the appropriate data.

Chetan Sastry