 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / May 2005How to re-use existing classes in JSP/JavaBeans/Servlets
OK, this is somewhat of a neophyte question but I don't know where else to ask it. What is the best way to integrate existing Java classes into a web page? These are purely domain logic classes... no presentation or anything. I looked into JavaBeans, but this technique seems to have some serious problems... it seems that JavaBeans cannot be anything except data objects, as they must conform to a rigid getter/setter paradigm. Servlets seem like the way to go, but it seems I lose the ability to mix HTML with the code. How do I do this with Java? It doesn't seem to have any easily accessible way to reuse classes in web pages, at least as far as I can tell. > What is the best way to integrate existing Java classes into a web > page? These are purely domain logic classes... no presentation or [quoted text clipped - 5 lines] > Servlets seem like the way to go, but it seems I lose the ability to > mix HTML with the code. You can use both Servlets and JSP. Do the processing including calling those Java classes in the Servlet, place objects (these might be 'beans') into the request (or session), then forward to a JSP to display the results of the processing. You might want to take advantage of an existing 'framework' such as Spring or Struts.  SignatureWendy But is the servlet itself not also a "bean?" I guess I don't get how to call servlets from JSP. If I can instantiate a servlet from JSP, then why can't I just call my classes natively from JSP? JSP's are servlets. They're just code generated from HTML plus some special tags. Buy a book. > But is the servlet itself not also a "bean?" I guess I don't get how > to call servlets from JSP. If I can instantiate a servlet from JSP, > then why can't I just call my classes natively from JSP? "thecrow" <carltonbrown@hotmail.com> wrote in message > But is the servlet itself not also a "bean?" I guess I don't get how > to call servlets from JSP. If I can instantiate a servlet from JSP, > then why can't I just call my classes natively from JSP? Keep in mind that I subscribe to a particular world view in which processing is done in Servlets and JSPs are strictly used to display things, with very little logic. So the request comes directly into a Servlet, it looks at the request parameters, instantiates objects and calls methods on them, stores some information in the request/session, then forwards to a JSP. You don't instantiate Servlets, the Servlet container does that. Neither do you 'call' Servlets from JSP. A "bean" can be nothing more than a plain old Java class that follows some naming conventions. [IMO, the marketing department at Sun got a bit out of hand with the whole JavaBeans(tm) thing.] So no, the Servlet isn't a bean. As you noted, they're mostly data objects, with get/set methods to expose the properties. You *can* call your classes natively from the JSP. (*I* wouldn't, but nothing's stopping you.) A JSP gets converted to Servlet code behind the scenes, so you can put anything you want in it. Just enclose the Java code in <% %> (I think...) and it will get picked up and compiled. Can you describe the problem you're trying to solve? Talking about actual code rather than generalities might be helpful at this point. SignatureWendy The problem I am trying to solve is fairly simple... I have classes that encapsulate domain logic and have no presentation. I want to use them in a web app by creating a JSP/servlet presentation for these classes. My question is, using best practices in an architecturally sound design, where and how would I instantiate and call these classes? I do not like the look of JavaBeans but I also do not want to call a thousand print statements from a servlet. As a basic analogy for what I'm doing, consider a pre-existing TarotDeck class which contains a collection of TarotCard objects along with a DeckIterator. I want to instantiate them and have the instance accessible to other servlets/jsp's called from the same session... do not want to re-instantiate them every page. The presentation will have buttons to navigate forward and backward within the deck. There will be more than one page involved... perhaps another page will have the ability to edit the stack and add or remove cards. I've read docs on the subject but there are a lot of ways of doing it... I just need to hash it out in an actual conversation with someone with some experience in the area. "thecrow" <carltonbrown@hotmail.com> said: >The problem I am trying to solve is fairly simple... I have classes >that encapsulate domain logic and have no presentation. I want to use [quoted text clipped - 8 lines] >with a DeckIterator. I want to instantiate them and have the instance >accessible to other servlets/jsp's called from the same session... Ok, so the lifecycle is that of the client session. One more data point. >do not want to re-instantiate them every page. The presentation will >have buttons to navigate forward and backward within the deck. There >will be more than one page involved... perhaps another page will have >the ability to edit the stack and add or remove cards. Then, when a session starts, you create an instance of your processing logic. That you store as a session attribute (which will be available to all servlets and JSPs called during the same session). Process all data that comes in a HTTP request within a servlet -- they're well suited for that. Then, when the data is converted into something you can feed to your processing logic, just let your processing logic handle the data. Note that beans can be just interface-deep, so the data can come from other classes -- f.ex. from your domain logic. Beans are a good match with JSPs, and JSPs are good for creating HTML views. So, when your servlet has handed the to-be-processed data into your domain logic, you forward the request (internal forward within the servlet engine) to a JSP, which provides the new data view, calling bean-like objects to provide the actual data. Or, implement a set of custom tags (building a tag library) to handle the presentation of your data within the JSP document. SignatureWolf a.k.a. Juha Laiho Espoo, Finland (GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++ "...cancel my subscription to the resurrection!" (Jim Morrison) Thanks for that previous reply... I just have one more question: in the architecture you've described above, where is the responsibility for presenting forms? Would the form be presented in a JSP with a submit action that goes to the servlet? Dude, your getting sloppy advice. Buy a book, really. Theres alot of ways to do this wrong. You dont have a good understanding of beans, custom tags or JSP's and servlets. Read up on it. > Thanks for that previous reply... I just have one more question: in > the architecture you've described above, where is the responsibility > for presenting forms? Would the form be presented in a JSP with a > submit action that goes to the servlet? "thecrow" <carltonbrown@hotmail.com> said: >Thanks for that previous reply... I just have one more question: in >the architecture you've described above, where is the responsibility >for presenting forms? Would the form be presented in a JSP with a >submit action that goes to the servlet? Yep; all HTML in your JSP. JSP is the place to manage how data is presented to the user. SignatureWolf a.k.a. Juha Laiho Espoo, Finland (GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++ "...cancel my subscription to the resurrection!" (Jim Morrison) The issue here is your use of terms "like" and "want" juxtaposed with "best practices". Why ask someone else's opinion when you are strongly opinionated and poorly informed? I write HTML documents with my own tags in them using square brackets, and filter these through a servlet. Crude, but I have a body of methods already written and I can develop in HTML and hack in my tags where the interactive data goes. I strongly echo "buy a book", and recommend van der Linden christop...@dailycrossword.com wrote: > The issue here is your use of terms "like" and "want" juxtaposed with > "best practices". Why ask someone else's opinion when you are strongly > opinionated and poorly informed? Perhaps I acknowledge my own limitations and seek the input of others? > I write HTML documents with my own tags in them using square brackets, > and filter these through a servlet. Crude, but I have a body of > methods already written and I can develop in HTML and hack in my tags > where the interactive data goes. So you've introduced your own macro language, so to speak? > I strongly echo "buy a book", and recommend van der Linden At the moment I am not in a place where I can readily get English-language books, otherwise I would do so. Is this not the internet age? Are there no suitable web sites? > At the moment I am not in a place where I can readily get > English-language books, otherwise I would do so. Is this not the > internet age? Are there no suitable web sites? Lots, but authors need to eat, too. If you can't get to "real" books, there's http://safari.oreilly.com/ where you can 'subscribe' to books and read them online. Given how fast tech books go out of date, this is a great service. Also, the J2EE tutorial from Sun: http://java.sun.com/j2ee/1.4/docs/tutorial/doc/ Pick and choose, you don't need all of it, but chapters 11 and 12 should sort out Servlets and JSP for you. You might want to read the JavaBeans Specification also, I don't quite understand why you dislike them so much, and they're VERY useful. For the most part, it's just a set of naming conventions. http://java.sun.com/products/javabeans/docs/spec.html SignatureWendy > You might want to read the JavaBeans Specification also, I don't quite > understand why you dislike them so much, and they're VERY useful. OK, help me with this. My dislike is just a knee-jerk first response against the fact that they seem to be data-only objects, restricted to getters and setters, devoid of any logic whatsoever. I don't "get" why using a traditional JavaBean would ever be preferable to just accessing the object directly. It seems like an extra layer added with no benefit. Maybe it's good for delegating interface development to people who don't know Java? Thanks for the safari reference BTW... I subscribed to it and I'm beginning to read up on the subject. I understand the "what" a lot better now, but I am just not getting the "why", specifically about using JavaBeans in a web app. > You might want to read the JavaBeans Specification also, I don't quite > understand why you dislike them so much, and they're VERY useful. OK, help me with this. My dislike is just a knee-jerk first response against the fact that they seem to be data-only objects, restricted to getters and setters, devoid of any logic whatsoever. I don't "get" why using a traditional JavaBean would ever be preferable to just accessing the object directly. It seems like an extra layer added with no benefit. Maybe it's good for delegating interface development to people who don't know Java? Thanks for the safari reference BTW... I subscribed to it and I'm beginning to read up on the subject. I understand the "what" a lot better now, but I am just not getting the "why", specifically about using JavaBeans in a web app. Beans are nice because its easy to set breakpoints, or insert print statements, reflective tools like them, and the compiler will optimize away the getters and setters. Beans used by JSP's are a place to hide your biz logic. If you werent also adverse to reading, you might find this out. >>You might want to read the JavaBeans Specification also, I don't > [quoted text clipped - 14 lines] > better now, but I am just not getting the "why", specifically about > using JavaBeans in a web app. > OK, help me with this. My dislike is just a knee-jerk first response > against the fact that they seem to be data-only objects, restricted to > getters and setters, devoid of any logic whatsoever. Then your dislike is totally unfounded, because JavaBeans are not restricted to getters and setters, nor must they be devoid of logic. > I don't "get" why using a traditional JavaBean would ever be preferable to > just accessing > the object directly. It seems like an extra layer added with no benefit. Okay, I'll play. Give an example of an object you'd rather just access directly, in order to display information on a JSP. No scriptlets allowed, only JSTL 1.0. SignatureWendy > > I don't "get" why using a traditional JavaBean would ever be preferable to > > just accessing [quoted text clipped - 3 lines] > directly, in order to display information on a JSP. No scriptlets allowed, > only JSTL 1.0. Well, of course "no scriptlets allowed" means "JavaBeans required". It's no surprise that an artificial restriction requires an artificial solution. Why did you introduce that restriction, do you encounter many cases where there is a real restriction against using scriptlets? > Well, of course "no scriptlets allowed" means "JavaBeans required". > It's no surprise that an artificial restriction requires an artificial > solution. Why did you introduce that restriction, do you encounter > many cases where there is a real restriction against using scriptlets? Ahhhh, now I get it! You think JavaBeans have no benefits, and I think scriptlets are ugly and difficult to maintain. It's a religious debate, we'll just have to agree to disagree, and end it here. SignatureWendy Smoak > > Well, of course "no scriptlets allowed" means "JavaBeans required". > > It's no surprise that an artificial restriction requires an artificial [quoted text clipped - 4 lines] > scriptlets are ugly and difficult to maintain. It's a religious debate, > we'll just have to agree to disagree, and end it here. So it's based on nothing but personal preference then? Nothing objective about it? That's a disappointment. I found a satisfactory answer for anyone approaching this question from the same angle as me. My basic issue with JavaBeans was that the practice "smells of accessors". I don't subscribe to the "accessor methods are evil" belief, not in the literal sense anyway, but I do think that having too many accessors could be a sign of a flawed design. And in the case of JavaBeans, if you want to delegate to your interface designers, you have to specify a lot of setters and getters... to a certain naming convention, no less, which I found to be a big red flag. This article explained it very well: http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html. Written by Allen Holub, it about the pitfalls of abusing getter and setter methods. I found his comment interesting, that accessors exist mainly for the purpose of hooks into higher level automation and testing tools. It's important to note that this title is not intended to be taken literally, it is just a way to start a conversation. So the rest of this post quotes from that article, entitled "Why getter and setter methods are evil.": You might object by saying, "But what about JavaBeans?" What about them? You can certainly build JavaBeans without getters and setters. The BeanCustomizer, BeanInfo, and BeanDescriptor classes all exist for exactly this purpose. The JavaBean spec designers threw the getter/setter idiom into the picture because they thought it would be an easy way to quickly make a bean-something you can do while you're learning how to do it right. Unfortunately, nobody did that. Accessors were created solely as a way to tag certain properties so a UI-builder program or equivalent could identify them. You aren't supposed to call these methods yourself. They exist for an automated tool to use. This tool uses the introspection APIs in the Class class to find the methods and extrapolate the existence of certain properties from the method names. In practice, this introspection-based idiom hasn't worked out. It's made the code vastly too complicated and procedural. Programmers who don't understand data abstraction actually call the accessors, and as a consequence, the code is less maintainable. For this reason, a metadata feature will be incorporated into Java 1.5 (due in mid 2004). So instead of: > This article explained it very well: > http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html. > Written by Allen Holub, it about the pitfalls of abusing getter and > setter methods. Ugh! I read that a while back, and I did not think he made much sense. I suspect that is because he is using different definitions of "accessor", "getter", and "setter" than I do (and the JavaBeans specification does). In any case, since those terms are critical to his thesis, he should have defined them. Holub says: Getter and setter methods (also known as accessors) are dangerous for the same reason that public fields are dangerous: They provide external access to implementation details. This is not true, assuming my (and the JavaBeans) definition of accessor. Accessors provide external access to the *properties* of a component, not its *fields*. In some (and perhaps many) cases, a property is implemented using a field, but that is just an implementation detail that is subject to change. SignatureRegards, John McGrath > > This article explained it very well: > > http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html. [quoted text clipped - 18 lines] > using a field, but that is just an implementation detail that is subject > to change. As they are most often used, getters and setters are nothing but pass-throughs to properties implemented as fields. The article was directed mainly against that practice, and if you read the rest of the article you can see that he mainly writing against the abuse of getters. > As they are most often used, getters and setters are nothing but > pass-throughs to properties implemented as fields. The article was > directed mainly against that practice, and if you read the rest of the > article you can see that he mainly writing against the abuse of getters. That is the way he frames the argument, which is very misguided, IMO. There is nothing at all wrong with using accessors, and there is also nothing wrong with writing accessors that simply set or get the value of a field. The real issue is how we design an appropriate public interface for an object. It is true that some people tend to design an interface by thinking about the implementation, and then expose those details as properties. That is certainly not the right way to do it. But given that they have done that, there is nothing wrong with writing accessors for those properties. The error was choosing those properties in the first place, not in creating accessors. And if you design an interface with a reasonable choice of properties, there is nothing wrong with writing accessors for those properties. In short, there is nothing wrong with accessors. Holub has chosen the wrong villain. SignatureRegards, John McGrath Theres alot of good template engines out there. I used freemarker and liked it. They are all easier to use than JSP's and probably will do what you want. > The issue here is your use of terms "like" and "want" juxtaposed with > "best practices". Why ask someone else's opinion when you are strongly [quoted text clipped - 6 lines] > > I strongly echo "buy a book", and recommend van der Linden > OK, this is somewhat of a neophyte question but I don't know where else > to ask it. [quoted text clipped - 12 lines] > accessible way to reuse classes in web pages, at least as far as I can > tell. Be pragmatic and just use the classes from within the JSP. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.