Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

JSP Design Pattern  RSS feed

 
Aaron Roberts
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm very young in the ways of developing web applications. I've used Struts awhile back and found that it just made sense. Now I'm trying to get back into some web work and am getting lost.
My goal is to keep presentation seperated as much as possible from the underpinnings of the application. For example, it 'appears' that there are all kinds of things I could do with XML/XSLT and other great tricks. Everytime I try and understand a highlevel overview, I just get lost. There are also lots of large 'all-in-one' environments that can even dynamically generate the database tables based on the java classes.
The thing I keep seeing is the jsp page no longer looking anything like a jsp at all. In fact some of it appears to be nothing but XML or custom tags.
Since I don't know HTML like a guru, but I can program well, I want to produce a generic jsp page and let someone who is good at graphics design and HTML work their magic without having to understand all kinds of new things.
In short -
- What would be on a well designed, maintainable JSP?
-- EL syntax
-- Lots of custom tags
-- XML
-- Standard HTML tags linked to 1 or maybe 2 CSS
I'd love to ask about frameworks, but I'm sure that is more than enough to chew on for now!
Please help before my head pops from too much information!
Regards,
Aaron R>
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65825
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What would be on a well designed, maintainable JSP?

All or any of the above; though I don't understand the restriction on the number of CSS links. I use as many as make sense (which usually is one or two, but if I need more, I use more).
I'd add JSTL to the head of the list of custom actions: use the standard before inventing your own (or that someone else invented).
IMHO, what won't be on such a page:
- Loads of Java scriptlets
- Loads of Java scriptlet expressions
- Custom tags that are wrappers around processing that should be in a controller (including any database access)
- Beans that are wrappers around processing that should be in a controller (including any database access)
- Anything that has nothing to do with presentation
- Anything that has to do with processing
[ April 19, 2004: Message edited by: Bear Bibeault ]
 
wei wu
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
jsp helper bean is a good design pattern. It makes your jsp focus on presentation while helper bean focus on some logic. It can minimize the amount of scriptlet in your jsp file.
 
Aaron Roberts
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear,
Thanks so much for the info!
I've come across some advocating the use of a JSP containing almost all tags and little to no html. What are your thoughts?
The one thing that I'm still perplexed about is what level the web-designer should be able to program. For example, if I have a simple page like a user profile. A programmer could get it operational and then let a non-programmer beautify it. Move things around, etc. When you start doing things like generating a set of things that need display and iterating, you start approaching 'programming'. A result of a search for example would need to be iterated over on a page. Where does the programmer meet the html-designer?
Regards,
Aaron R>
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65825
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've come across some advocating the use of a JSP containing almost all tags and little to no html. What are your thoughts?

I think that's pretty silly, at least on the face of it. Why obfuscate the HTML in the page where not necessary? I do tend to use a lot of custom actions -- but not to replace HTML markup unless there's a good reason to.
For example, I use my own custom actions (formerly known as custom tags) for form and form element tags because there's a lot of extra functionality I've added to them (automatically setting default values and so on). If all these custom action were going to do were to spit out their HTML counterparts without doing a lot of extra work for me, I wouldn't do it. Why would you?
A result of a search for example would need to be iterated over on a page. Where does the programmer meet the html-designer?

One of the main benefits of the JSTL is that the most common "programming actions" like iteration and conditional execution are captured in tags that any markup-savvy person should be able to adopt, whether that's a developer or page designer. If there's more complicated action necessary on the page, chances are that the controller didn't do enough to set things up properly on behalf of the page.
A small iteration example:

Although this uses nested loops, there's not much in the way of "scary programming" here.
One of the reasons that the above can be so simple is that the page and the controller are acting as follows:
Controller: Hey page! I've got the data all ready for you to display. You'll find it in scoped variables named according to our agreement.
JSP page: Cool!
[ April 20, 2004: Message edited by: Bear Bibeault ]
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65825
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ignore the smilie in <c ut/>, of course. A bug in UBB is making the post hard to edit, so I'm going to leave the smilie.
[Edit: ok I went back and fixed it -- no smilie]
[ April 20, 2004: Message edited by: Bear Bibeault ]
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65825
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
jsp helper bean is a good design pattern. It makes your jsp focus on presentation while helper bean focus on some logic. It can minimize the amount of scriptlet in your jsp file.

While this is true, be aware that that way lie dragons!
Factoring Java out of the page and into "helper beans" might get the Java itself off the page -- which is a step in the right direction, but it leaves whatever processing/logic you've factored out still under control of the page. In other words, a "Model 1" architecture.
In this architect's opinion, a modern, properly architected web application will follow the "Model 2" pattern where the processing is done up-front by the controller. Once the page gets control, the only thing left to do is to display the data. Any processing done on-page (or under the control of the page in beans or custom actions) should be "display support" processing. Application logic and data preparation should have been handled before the page gets control.
 
Aaron Roberts
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear,
I think I understand the snippet you posted, but I wanted to clarify. For the first tag items uses a $. The second time it uses a %. Were they supposed to both be a $?
I believe that the ${xxxx} is specifying the name of the getter property of the forms bean. I am understanding?

The smilie did make the code more fun to read!
Regards,
Aaron R>
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65825
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, both are $'s. I'll fix the post.
The ${} notation invokes the EL (Expression Language) in JSTL (and in template text under JSP 2.0).
So in my example: ${searchResults} evaluates to a scoped variable named "searchResults" that (presumably) is placed in a scope (request, session or application) by the controller. This variable is a collection, so it can be iterated by the forEach action. Each collection entry is assigned to the scoped variable "resultRow", which is in turn a collection which is also iterated over. Each resultRow entry is assigned to scope variable "cellValue" which ultimately appears as the values of the table cells.
[ April 20, 2004: Message edited by: Bear Bibeault ]
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65825
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And just for furthering the example, if you wanted to omit the table completely if there are no results, you would enclose the entire example with:
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65825
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Or, if you wanted to be a tad fancier:

My point is that with a handful of JSTL tags and a controller that sets up the data in proper fashion on behalf of the page, it's easy to create pages with complex logic with zero Java on the pages.
And once you get adept at writing your own custom actions (something that's become much easier to do in JSP 2.0), there's really no need for JSP pages to be big bloated notational nightmares.
[Edit: damn smilies!}
[ April 20, 2004: Message edited by: Bear Bibeault ]
 
Jeffrey Hunter
Ranch Hand
Posts: 305
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I use my own custom actions (formerly known as custom tags) for form and form element tags because there's a lot of extra functionality I've added to them (automatically setting default values and so on).

This sounds like a pretty cool idea, Bear. I was wondering if you can elaborate on this a bit more. I'm currently using the traditional javascript logic for setting form field values and actions. How does this logic transfer to the custom actions you describe?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65825
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since my custom actions emit the HTML for the form element, if it knowns what it wants the default to be (either because it was submitted as a form element previously, or because the controller knows what it wants, or its populating from a database value object, and so on), it sets up the value attribute as appropriate.
For example:
The on page action:

could end up on the HTML page as:

The point is that since the HTML is bening generated on the back end where the data is, its easy to set up the HTML any way you want. The above example could have resulted because a login failure occured and we were being sent back to the login page -- the default of "bear" being picked up from the previous submission.
(Btw, the controller 'communicates' the default form value to the custom actions on the page using a contract similar to that which I've alluded to earlier via scoped variables.)
[ April 20, 2004: Message edited by: Bear Bibeault ]
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!