User Interface

we started talkin about ui in that things to get done topic so ill just move the conversation here

lol changing the cursor was a lot easier than i expected while frantically searching thru the design view for how to switch cursor during the program
so ya thats done (source code ftw)

The UI also catches a bunch of exceptions and should not crash unless it runs into another exception. I doubt that there are anymore exceptions to worry about but if you find one just write a catcher (if thats wat its called) with the rest of them.

now onto the result display...

we might wanna change our method of displaying results
we got a java.awt.List but it wont allow individual results to be displayed on more than one line.

so wat do u guys think we should change it to if we should?
i think daniel knows a site for this stuff but i forgot wat its called

it's not a site specifically for UIs, it's for everything java: www.java2s.com

btw guys, on a side note related to UIs, how do we display previous searches? I will be writing an XML thing that saves the paragraph content and the results. but how do we allow the user to choose a previous search?

For the previous results...
mmn, a save/load thing?
But that seems to be complicating things a bit.

+ The "loading from past results" is not a /requirement/, right?
So, if we don't get enough time, I think it'll be fine if we don't implement it.

--

Steven mentioned something about displaying the results in a drop-down menu..

- shrug -

I was talking to Sadia on our way to Sheridan about the case in which we validate the input URL, instead of parsing through all of the URLs.

nested try catch is legal, HOWEVER, it's not recommended in term of style, especially when it is part of the functionality of the program.

The reason for this is the following. Whenever/everytime an error is caught, the program creates a dump file (a file containing the entire state of the program) for debugging purposes. Normally, this wouldn't affect us, since our dump file is less than a few KB big. however when we program bigger programs, like photoshop big, it can get up to 500MB. This accumulates in the computer, and the user will not be happy lol. Furthermore, it prints a stack trace to the console, which overshadows all of the console output we may output.

The way we can validate invalid URLs (by invalid we mean malformed, no connection etc), is to do the following:

In the FMLinkFinder, I noticed that the constructor does the following:

Code:


Document mainPage = Jsoup.connect(currURL).get();
link = mainpage.select("a[href]");


what we can do is this:

1. Create a global private Connection conn; in FMLinkFinder.
2. modify the constructor to the following:

Code:


conn = Jsoup.connect(currURL);
if (conn != null) { // We need to find out if indeed, Jsoup.connect(URL) returns null IF no connection can be made
    Document mainPage = conn.get();
    link = mainpage.select("a[href]");
}


Create a GET method for the connection object:

Code:


public Connection getConnection() {
    return conn;
}


in the UI:

instead of the try catch block, try this:

Code:


if (fm.getConnection() == null) {
    statusText.setText("[error message]");
} else {
//do whatever is currently coded



We can apply this exact concept to all of the errors Lenard wrote, in order to prevent error.

=)

ill get right onto makin those changes right now

fmlinkfinder isnt handled in the ui but ill see where it comes in and use the getConnection from there

couldnt find a way to raise the error without using throwables (only way to do it meant that the front end would have to know more than it should about the back end) so i made an Error and catcher. ya i know this might b less efficient but i wanted to keep front/back end stuff separate plus a lot of our design would have to change i believe

Oh I see what you're saying. Ok let's keep it the way it is then, and maybe if we have time we can revisit... this is just a styling matter, and irrelevant to the actual usability of the program..

about the cancel button..
i think it kind of acts more like an "exit button" now.
since it closes the whole program.

and that's not what the user really wants.

is there a way to fix this?

daniel; maybe, you could just leave it as you said it was before (or something), where the UI looks like the program "cancelled" [ but it still keeps processing in the background ]?

i guess we could rename it to "close"?

Or, "exit"..?