Paul Clapham

+ Follow
since Oct 14, 2005
Paul likes ...
Eclipse IDE Firefox Browser MySQL Database
Vancouver, Canada
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Paul Clapham

Sam Parson wrote:However it looks like I won't be able to directly test private methods. I can only write a testcase using a protected method that calls that private method in the same class.

There's a lot of people who would say you shouldn't need to test private methods anyway. You ought only to be testing methods which are exposed to the world, i.e. methods which are part of the class's documented API. Private methods are just implementation details, and testing shouldn't be concerned with implementation details.

Of course like anything else there are people who wouldn't agree with that. I'm not going to argue with them either, but I would still suggest that if you want to test private methods it may be that you're looking at the code too much and not looking at the documentation enough. In other words, there should documentation for the class which says "If you call this method in such a way then these things should happen and the returned value should be such and such". The documentation shouldn't mention private methods -- look at the documentation for the standard Java API and you'll see it doesn't.
19 hours ago
I don't know if this is part of your confusion, but the Membership class is entirely unnecessary. All of that code would be much simpler if the MembershipType enum itself had the attributes for member fee, join fee, and comp fee. Have a look at Oracle's enum tutorial and scroll down to the Planet example to see how to do that.

On the other hand if what I just said contradicts what you're supposed to be doing, then just disregard me.
1 day ago
And don't get hung up on the idea that the property is always represented by a private variable of the class. That's often the case, but not always. Consider this (trivial) example:

(In real life there are obviously more realistic examples.)

salvin francis wrote:You could consider "has", "can", "contains" etc..
I hope my post does not raise a lot of eyebrows

You could do that... but there are products like JSTL which just expect the name of the property (e.g. "vegetarian") and under the covers look for methods named "isVegetarian" or "getVegetarian" to access those properties. However your examples show that the JavaBeans conventions don't always work nicely with boolean properties.
Oops... I just noticed I didn't swap the smilies when I swapped the two lines which print the verdict.
1 day ago
It's working code, anyway. That's always the first goal. But this code could be improved on, a bit:

You have the boolean expression "checkout == false"; fortunately you correctly used the == operator there. If you had accidentally or carelessly used only "=" you would still have code which compiled successfully, but not code which worked correctly. That boolean expression would always be false, which is an error. So we recommend using "! checkout" instead, meaning in English "not checkout". (If you find "not checkout" hard to understand, that's because your choice of name "checkout" for "does the alphabet contain the entry" isn't especially meaningful. But I digress...)

Now, many people find "If (not X) then A else B" hard to grasp, so for those people (there's a lot of them) it's better to write "If X then B else A" instead:

And you remember what I said about "checkout" being a name which isn't all that helpful? In this case we didn't need a variable at all, we could just use the result of the "contains" method from the previous line:

This is shorter (often, but not always, a good thing) and it's easier to understand.

Anyway, keep up the good work!
1 day ago
JavaBean naming conventions are in Wikipedia, here:

By the way, static variables are irrelevant to JavaBeans. A JavaBean is an object which can be passed around to various users and it has various properties, which clearly can't be static.
One of the important features of the WEB-INF directory is that everything in it, and everything in the directory tree below it, is not visible to code on the client side. So your tag in the browser can't refer to anything in and under the WEB-INF folder.

So putting your images elsewhere, which is what you did, is the way to fix your problem.
2 days ago

HuaMin chen wrote:I mean GridBagLayout can't cut the screen into two areas.

Yes, that's not one of the design features of GridBagLayout.
2 days ago

Luanrkiran kumar wrote: Is this because they both are in the same class which is class One?

You could test that idea by making A and B top-level classes, couldn't you?

Nicholas Mercurio wrote:I have heard that it is outdated, unfortunately, my JavaEE class requires it.

You're kidding! That's pretty close to professional malpractice in my book.

If I have the session.getAttribute() tags in their respective if statements, won't they not run if the particular if isn't entered? For example, if itemExists(rs) returns true, the else if will not run, thus not setting the invalidCode attribute? I do see what you're speaking of within the JSP, but not sure how else I would validate the 2nd else if statement checking if invalidCode is true or false if I don't getAttribute before running the elseif.

I didn't really follow all of that, but the fix you need is to always set the invalidCode attribute in the servlet regardless of what path you take through the code. Setting it to false at the beginning would be one way. And by the way, why are you using a session attribute for that? To me it doesn't seem like the kind of data which needs to be preserved from one request to the next.
3 days ago
Hi Nicholas, welcome to the Ranch!

The session.getAttribute() method will return an Object representing the attribute referred to in the parameter, or null if there is no such attribute. It's quite likely that "no such attribute" will happen in the code you posted. And when you try to cast null to a boolean primitive value, you get... a NullPointerException!

You asked for alternatives. Let me point out that JSP scriptlets have been obsolete for well over a decade now, so I'd suggest you rewrite that code to use the EL. It's actually a lot easier to use than scriptlets, too.

And in your servlet, don't declare productsList as an instance variable. In real systems it's possible for two requests to be using the servlet simultaneously, which would cause products chosen by both requests to be mixed up together and sent to both clients. You also don't ever clear the list, which means the second request, no matter who sent it, is going to get its products along with the products from the first request, no matter who sent it. And the third request will get its products along with all of the others. But declaring it as a local variable in the method which fills the list takes care of both of those problems.
3 days ago

Philippe Ponceblanc wrote:I put <servlet-api.jar> a little by all in the path and it still does not work.

No, put it in the classpath, not the path.
3 days ago
The alternative is to not use any static variables. Here's what your code ought  to look like:

3 days ago
It looks to me like you want a directory chooser, not a file chooser. No? To make a JFileChooser display only directories you need a line of code like this:

3 days ago