aspose file tools*
The moose likes JSP and the fly likes Debugging JSP/JSF Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » JSP
Bookmark "Debugging JSP/JSF" Watch "Debugging JSP/JSF" New topic
Author

Debugging JSP/JSF

Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
I've been debugging JSF lately and I think this gif sums things up well:



Here's a more articulate blog by Adam Winer on JSF Usability.

If I had to reduce it to one complaint, I guess I don't like the whole idea of writing JSP documents. I'd rather write Java code. I like the static type checking, rather than having to touch each link to see if the EL expression parses correctly. (Is this testinglaziness on my part? What do folks in this forum use to unit test their JSPs? Cactus? If so, what do your recommend?)

Again, stop and ask yourself if JSP documents still make sense. If you are writing an international app, your text is in a resource bundle, and thanks to JSF's components you aren't directly writing many HTML tags. In my short-handed shop, there are no separate web-page designers, so the same people write Java and JSP pages, thus the division of lab argument is moot. Putting all that together, I don't see the advantage to writing JSPs. I'm using WSAD 5, and it's not that smart an editor -- the Java editor is much smarter and spots many, many more mistakes. Also, there are so many things you can do in code that you can't do easily on a JSP page, like do the equivalent of writing a subroutine to share common code!

Sigh. I wish this gif were me instead of that monkey:
[ March 29, 2006: Message edited by: Jeff Albertson ]

There is no emoticon for what I am feeling!
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60046
    
  65

While I can't speak to JSF (which I find just too cumbersome to use), I find the exact opposite is true of JSP pages in the JSP 2.0 environment.

Since with JSP 2.0 it is now possible to write completely scriptless JSP pages, I find that the pages -- which are now pure template markup rather than a mish-mash of processing and markup -- require little to no debugging. And that debugging is usually in the HTML and Javascript areas rather than the JSP portions of the page.

The EL is straight-forward and easy to get a handle on. If you structure the data that is being sent to the JSP as appropriate for EL consumption, there's little that can go wrong.

Since all of the "heavy lifting" is done in the servlet controller in Java code, the JSPs have beceome pure view elements.

This greatly facilitates testing. All the proceesing is done in Java code in the servlet controllers and its delegates, where unit testing is a well-established paradigm. The JSPs, which have no processing on them, expect a "contract" consisting of the scoped variables it is expecting to be passed to it. It becomes a fairly simple matter to test such pages by mocking those scoped variables.

So, yes, to answer your question. JSP pages make more sense than ever.

The thought of reverting to building up complex pages full of HTML, Javascript, Ajax handling, CSS and the rest of that goo in Java string buffers is enough to make me drop to the floor in despair.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60046
    
  65

Also, there are so many things you can do in code that you can't do easily on a JSP page, like do the equivalent of writing a subroutine to share common code!


This statement tells me two things. 1) You are still trying to do too much on the JSPs. Do the "heavy lifting" in the servlet controllers. When thinking of JSPs, the term "code" shouldn't even be coming to mind. And 2) you don't yet have a good grasp of the facilities that JSP offers. The custom action mechanism is a strong means to share "common code" across pages.
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
Originally posted by Bear Bibeault:


This statement tells me two things. 1) You are still trying to do too much on the JSPs. Do the "heavy lifting" in the servlet controllers. When thinking of JSPs, the term "code" shouldn't even be coming to mind. And 2) you don't yet have a good grasp of the facilities that JSP offers. The custom action mechanism is a strong means to share "common code" across pages.


I see your points, the "code" I'm thinking about is all on the presentation layer, so not in the ambit of the servlet.

Here's an example of what I meant:

This represents a row in a two-column form. The first column is a label
and the second column's content depends on the readonly state of the bean.
In read-only mode the second column is just the text value of property foo, but
in writable mode the second column is a text field with perhaps a error
message (because of input validation errrors).

I've got dozens of such rows, and I'd like to be able to write a common
subroutine to spit out the presentation, but I don't know how to create
a "composite" tag.
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
>Bear Bibeault writes:
> Since with JSP 2.0 it is now possible to write completely scriptless JSP >pages, I find that the pages -- which are now pure template markup rather >than a mish-mash of processing and markup -- require little to no >debugging. And that debugging is usually in the HTML and Javascript areas >rather than the JSP portions of the page.

My JSP, too, has no scriplets embedded in them, but I'm still not happy with them.

>The EL is straight-forward and easy to get a handle on. If you structure >the data that is being sent to the JSP as appropriate for EL consumption, >there's little that can go wrong.

I miss strong typing. When I write "#{bean.prop}" (or you write the JSTL equivalent), it isn't until that expression is evaluated at runtime that I find out if that bean has methods set/getProp. And because my pages are very dynamic I have to test them in several states before I've touched every EL expression.

>Since all of the "heavy lifting" is done in the servlet controller in Java >code, the JSPs have beceome pure view elements.

That's true for me, too, but for some applications a large slice of the code is devoted to the view.

>It becomes a fairly simple matter to test such pages by mocking those >scoped variables.

I have to test all the links/buttons on a page, and for mock objects in several different states (readonly, entering a new record, editting an
existing one, various input entry errors). I guess I need to use a testing
framework that would simulate entering form data and clicking on various buttons/links. Right now, I do that manually *shudder*.

>The thought of reverting to building up complex pages full of HTML, >Javascript, Ajax handling, CSS and the rest of that goo in Java string >buffers is enough to make me drop to the floor in despair.

For me the goo already exists on the JSP page. In JSF anyway, the JavaScript for a dynamic component is generated by the component itself -- I typically write little more that "submit();". File like .js files and .css files would continue to exist as always. I still think a document-based approach isn't making like easier for me.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60046
    
  65

It seems like the majority of your concerns are actually with JSF. I'm not going to try and defend it -- I don't care for it and don't use it.
Stefan Evans
Bartender

Joined: Jul 06, 2005
Posts: 1016
I can agree one point at least
- strong typing and compile time checking. EL doesn't have any facility for this. You only find out at runtime if you misspelled a property.
Of course the power/flexibility of EL is that it is so dynamic. But that doesn't stop me wanting to have my cake and eat it too ;-)

Looking at your code I can see why it would be frustrating.
I don't know if this idea would work, but it might be worth a try
Write a custom tag
<my:textOrInput id="foo" value="#{bean.foo}" converter="trim" size="25" textOnly="#{bean.readOnly}"/>

This tag would extend the standard <h:inputText> tag, and add the extra attribute - textOnly.
If textOnly evaluates to true, you can render it as text.
If textOnly evaluates to false, let it call the standard render for the object.

You ARE writing quite complex pages. Given that most of these issues are presentation I don't see that you could write them in Java code easier/better than in JSP.

Sorry, can't probide much more hope like that.
Maybe it is more appropriate in the JSF forum?
Gerardo Tasistro
Ranch Hand

Joined: Feb 08, 2005
Posts: 362
Originally posted by Jeff Albertson:

If I had to reduce it to one complaint, I guess I don't like the whole idea of writing JSP documents. I'd rather write Java code. I like the static type checking, rather than having to touch each link to see if the EL expression parses correctly. (Is this testinglaziness on my part? What do folks in this forum use to unit test their JSPs? Cactus? If so, what do your recommend?)


Whenever I get and idea like that I just jump into the work directory in the Tomcat install. Look for the java code that is generated from my jsp and jsf. See what hell I'd be into if I wrote it myself and get back to JSF knowing it is the lesser of two evils.
 
Consider Paul's rocket mass heater.
 
subject: Debugging JSP/JSF
 
Similar Threads
ANNOUNCE: Stan Silvert on Testing JSF Applications with JSFUnit
inheritence
using jsp in the background
reading a private method within a class
benefit of taglibs