Joshua Fix

Ranch Hand
+ Follow
since Sep 18, 2007
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Joshua Fix

I've been battling this for a couple hours... I should have waited 2 more minutes before posting! <h:outputLabel> did the trick!
15 years ago
JSF
I have a javascript that displays a tool tip when a link is moused over. The link doesn't really point to anything, however... it's just the mouse-over effect that I'm after. If I create an <a> tag without an href, the link is not clickable... this is what I'm really after. JSF ALWAYS sticks in a blank href="" tag though, making the link clickable, and thus making my whole page reload if somebody clicks it.

I tried just using standard html and creating the tag myself, but apparently JSF doesn't process tags the same way JSTL does, and it won't render the value unless the #{bean.field} tag is inside a JSF tag...

Any ideas on how to create a non-clickable link that my onmouseover JavaScript function will work on?
15 years ago
JSF
Jens, do you keep your socket connection open for the entire client session, or do you open and close a session with each transaction? Does anybody else have any comments on doing one way vs. the other?
I'm using sockets for my network connection. I open a new socket for each transaction and then shut it down. Is this acceptable? Is this what other people are doing, or should I persist the session until the client is shut down?
In case anybody is interested.... I couldn't bring myself to leave the lock method outside of the try block, so here's what I ended up doing:

I think it makes sense to javadoc all public methods, even if they seem obvious and there isn't much going on with the implementation. Some get methods may have very complex implementations and may need explaining as to what it's returning and how/why. Blank javadoc for a public method leaves it all up to the reader's imagination

I struggled with the javadoc section a lot because I'm REALLY lazy and I hate documentation (when I have to write it!). I finally ended up deciding to javadoc EVERYTHING, even private stuff, with the hopes that maybe it makes it easier for the grader and I get a faster turn-around time. It was a dreadful experience, but I'm glad I did it
I don't mean to hijack this thread, but I would like to add on to the question by asking if file corruption checking is something that should be included and within the scope of the assignment.
It sounds to me like it's interpreting them as operators and not as enclosing braces for generics. I've never seen a generic type have spaces before or after <>.
B&S. You sound like me... I finished 99% of the project in about 2 weeks working 6-7 hours a day. I've spent about another month on details and tweaking so far. The biggest hang ups for me have been concurrency, logging, and exception handling.

I'm freaked out from reading threads where people got failed because of seemingly minuscule and debatable threading issues, so I've been extensively testing the concurrency of my server. I'm convinced my synchronization for the database file access is solid, but trying to play out all of the possible threading issues for the logical record lock manager has been difficult. Also wrapping my head around class instantiation: where to assume there may be multiple threads running through a single class instance and where to force single class instances (ie singletons), etc.

I wasn't going to implement logging at all because it's not required, but then I decided to go with an extremely minimal approach and log fatal/unexpected errors.

I also think I've over-generalized my exceptions and they need to be slightly more robust... namely I've decided to change some of my checked exceptions to runtime exceptions.
Here is some pseudo code for how I have my "book" method:

Here is my problem. I would like to throw a runtime exception in the lock method if an InterruptedException is thrown. If this happens, the record is never locked. In my unlock method, I immediately perform two checks: 1 to see if the recNo is locked and 1 to see if the current thread is the owner of the lock on the recNo. If not, I throw a RecordNotFoundException.

I don't expect an InterruptedException to ever occur, but if it does, it will basically get destroyed by the RecordNotFoundException. The client then gets notified that it's trying to unbook a method that doesn't exist/it doesn't own, which isn't what I really want to report.

The VERY last line of my lock method is putting the recNo in my HashMap. So I think it's safe to say that if the method returns without throwing an exception, it was successful. So is it OK to have my the code to book ordered like this:

This way, any exception thrown in the lock method continues to bubble up and I am sure that the unbook method is only called after a successful lock?
Yes... update and read are the only methods my adapter class will ever end up calling (besides lock/unlock of course). But you still have to provide a full working implementation of the DBMain interface, even if your code never ends up calling it.
A lot of people including myself took a "3-tier" approach. Instead of advertising the DBMain interface directly, wrap it with another business layer class that implements an interface that is defined by your client requirements. This class can contain the logic necessary to "adapt" the requests to the DBMain specs. Write your protocol around this interface and have your client instantiate it for your connector. Now your client has direct access to the methods it needs and nothing else.
I've finally wrapped my head around the concept of using JSP for the view, a servlet for the controller, and POJOs for the model. I find myself routinely falling back into this pattern for my controller, which I totally fabricated in my head and I have no idea if it is good/bad/otherwise.

I basically define an enum in my servlet class called Action that contains values I expect to receive as a parameter. I attempt to match the request parameter stored in "action" to one of the enums. Then I enter a switch statement that switches on the enum values. Each case does whatever it needs to to the model and sets the url string for the dispatcher. At the end of the switch statement, I forward the request using the dispatcher.

Is this how a controller should work? Are there any good resources available on controller design/patterns/etc?
15 years ago
I'm struggling with the appearance of the code in the class for my GUI client that extends JFrame. In general, the methods of the class handle building text fields, buttons, labels, etc. and get the values to display from a controller class. However, at least half of the file is composed of about 12 inner classes that implement some sort of listener. I've written listeners to set default buttons based on focus, activate/deactivate buttons based on what is selected, and all kinds of other little things that make the GUI experience a little smoother. The inner listener classes need access to the member variables of the enclosing class to be able to manipulate them as described, so I can't think of any other way to make this work and to not make my code look (in my opinion) very ugly. I've never had to rely on such overuse of inner classes in any other application I've ever written.

Is this just what you have to do with swing, or is there a cleaner way? Maybe making the target member variables static protected, extending my ClientWindow class and implementing the listener interface... then I could create separate class files for each listener, but that seems like a sloppy work-around in itself.
What is the benefit to using Singletons on the server? I was reading another post and somebody had multiple calling classes as Singletons. While it reduces object creation, wouldn't you have to synchronize a lot of the code, creating a whole bunch of synchronized bottle necks?

I can justify having the class that accesses the database file a singleton since it's already all synced up, but what about any front end facade/adapter classes?