Raymond Gillespie wrote:I thought I could just right [sic] a class and store the data in an object and then return the object back to the servlet
After thinking about it, I am not sure that would work anyway.
If I am using while(rs.next()), wouldn't it just replace the first row of data with the second row, so on and so forth, if there were more than one row return? I think using JavaBeans would be the solution but I don't quite understand it or how it works.
Bear Bibeault wrote:Let's say your bean is of class Something. To create a list of somethings:
To add a something to the list:
You would create an instance of Something for each row in the result set and add it to the list.
This is all pretty basic Java; is it new to you? (It helps us help you to know where you are on the learning curve.)
Bear Bibeault wrote:Yup, pretty much. Though the class should be named Flight, not Flights. An instance only represents one flight, correct?
Raymond Gillespie wrote:Yes, an instance only represents one flight. Of course when the user searches, there could be more than one instance in the database that meets the search criteria.
To better phrase my last question. I am not sure how to handle/accept what is returned to the servlet from the database class.
This is the bit of code that is calling the database method to do the search and return.
Bear Bibeault wrote:
Raymond Gillespie wrote:Yes, an instance only represents one flight. Of course when the user searches, there could be more than one instance in the database that meets the search criteria.
Right. That's what the list if for.
To better phrase my last question. I am not sure how to handle/accept what is returned to the servlet from the database class.
What do you want to do with it?
Bear Bibeault wrote:
This is the bit of code that is calling the database method to do the search and return.
Is that in the servlet?You should not be handling SQLExceptions in the servlet. That should have been handled by the lower-level code.
Raymond Gillespie wrote:
This is the method call. What do I do to accept what this returns?
Yes it is in the servlet. I removed the try catch. At some point Eclipse was showing an error and that made it go away.
When I loop through the ArrayList, it only gives me:
airline.javas.Flights@6f454f66
airline.javas.Flights@2f5fea9c
What am I doing wrong here?
Bear Bibeault wrote:
Raymond Gillespie wrote:
This is the method call. What do I do to accept what this returns?
If the method returns the list of Flight instances:
Yes it is in the servlet. I removed the try catch. At some point Eclipse was showing an error and that made it go away.
Yes, you need to deal with the SQLExceptions, but they should be dealt with at a lower level, perhaps throwing a less specific exception if need be. You servlet should never ever have to import anything from the SQL packages.
When I loop through the ArrayList, it only gives me:
airline.javas.Flights@6f454f66
airline.javas.Flights@2f5fea9c
What am I doing wrong here?
Nothing. Those are the two flight instances. What you are seeing is the output created by the default implementation of toString().
Please take this as constructive, but there is a lot of basic Java here that it is assumed you have under your belt before diving off into servlets; which is rather an advanced topic. Unless you have to be doing this for your job, I recommend you get a better handle on basic Java prior to tackllng servlets and JDBC.
Nothing. Those are the two flight instances. What you are seeing is the output created by the default implementation of toString().
Bear Bibeault wrote:Ah, so you've been thrown into the swamp of alligators, eh? Yeah, been there.
![]()
You'd only override toString() if you have a need to. That need could be for important business reasons, or just to have readable logging (which is what you seems to be doing here).
So yes, it's fine to override toString() (be sure to use @Override) to emit what makes the most sense for the class.
Raymond Gillespie wrote:
Bear Bibeault wrote:One thing at a time: what is the following doing in the JSP?
![]()
![]()
![]()
No scriptlets in a JSP! Ever! (And certainly not in one where the JSTL is also being used).
Bear Bibeault wrote:
Raymond Gillespie wrote:
You don't show in the above what flightList is declared as, so it's hard to know if: is correct. But I'm betting it's not.
Raymond Gillespie wrote:I thought I needed that to retrieve the flightList but I guess not huh.
Raymond Gillespie wrote:This is in the servlet.
<c:forEach var="list" items="${flightList.list}">
So, why did you think you needed this? It's important to understand what you were thinking.
OK, another "what were you thinking?" question. Why the .list suffix? What, under heaven and earth, would make you add .list to the name of the scoped variable?
Raymond Gillespie wrote:The reason I thought that I needed that is because looking at the book I have it showed it that way, although when I looked closer, it was comparing JSP code with JSTL with scripting using scriptlets.
Plus it sort of made sense to use it to me.
Again looking at the example in the book it shows:
<c:forEach var="list" list="${flightList}">
Raymond Gillespie wrote:I don't know what's next. I just do not understand how the for each loop works or what each part of it means. I realize that this should be a very simple concept but I just can't seem to grasp how it works.
Bear Bibeault wrote:I actually order the forEach tag slightly differently, which I find makes it more readable:Now it reads like: "for each item in flightList create a var named flight".
The body of the forEach is repeated once for each time in the List. Each time, the current item (in your case, a Flight instance) is referenced by the scoped variable flight.
So if the List had three items, the body would repeat three times, once for each flight.
So far, so good?
Raymond Gillespie wrote:
<td><c:out value="${flight.departure_city}"/></td>
Bear Bibeault wrote:
Raymond Gillespie wrote:
<td><c:out value="${flight.departure_city}"/></td>
Here's we get into "bean theory".
The EL operates on beans. And naming by convention is an important part of beans. So "departure_city" isn;t going to cut it. Your bean should have a getter such as "getDepartureCity()" defined -- and yes, this is mandatory. Not optional. Not maybe. Mandatory. Each property you want to access must have a getter. Must.
Then the rule is that the property name represented by the getter is formed by dropping the "get" and lowercasing the first letter of what is left. In this case, the property name would be departureCity. Again, this is the rule. A hard and fast one. No getting around it.
So, we end up with:
Head explode yet?
Bear Bibeault wrote:P.S. Same for variable names, but it's less critical there. Java convention is to use camel case, not underscores. Your code becomes surprisingly unreadable when you fail to follow expected naming conventions. But, again, with beans, it's mandatory, not a simple matter of style.
Raymond Gillespie wrote:So are you saying that it is mandatory for variables to be camel case and not underscores for Beans also?
one empty table row. It's like the for loop isn't even running the two time it should run.
Bear Bibeault wrote:Not seeing anything awry at first inspection...
So can I assume that the logging output from the servlet shows the expected data is in the list? (Btw, you ought to investigate real logging with java.util.logging or Log4J).
And you have looked at the HTML sent to the browser (View Source), not just what's being displayed?
Another "by the way": your for-loop in the servlet should be using the more modern version of the for loop:
It has much simpler (hence, easier to read) syntax, doesn't require a get() from the list, and note its resemblance to the JSTL forEach tag?
Bear Bibeault wrote:
You did include the directive in the JSP that imports the JSTL, right?
And placed the JSTL jar files in WEB-INF/lib?
If I had asked people what they wanted, they would have said faster horses - Ford. Tiny ad:
New web page for Paul's Rocket Mass Heaters movies
https://coderanch.com/t/785239/web-page-Paul-Rocket-Mass
|