that suxors... i believe chrisi had some of the groundworks done though.. or was it somebody else.

Quang: How lazy are you when the data is handed to you on a silver platter. Just take a look at the code, 337 occurences of '<a class="challenge" href='... I wonder how many challenges there are at the moment.

<tr style="background-color:#383850;" onMouseover="Challs_RowMOver(this, 0)" onMouseout="Challs_RowMOut(this, 0)">
<td class="name" style="padding-bottom:0px;padding-top:0px;"><a class="challenge" href="/challenges/crypto34/index.php">
30: Amsco</a> [made by <a class="creator" href="/userstats.php?username=Caesum">Caesum</a>]</td>
<td class="vote" style="padding-bottom:0px;padding-top:0px;"><span title="25 members ranked this challenge.">25</span><a href="challvote.php?challid=125"><img src="/files/images/icons/vote_stat.gif" width="16" height="16" alt="vote-icon" title="Rate this challenge!" /></a></td>
<td class="v">7.7</td><td class="v">7.4</td><td class="v">7.6</td><td class="v">6.7</td>
<td class="doneby" onClick="window.location='/challengestats.php?challengeid=125'" onMouseover="Challs_StatsMOver(this, 'FF8800')" onMouseout="Challs_StatsMOut(this, 'FF8800')" style="color:#FF8800;padding-bottom:0px;padding-top:0px;">90</td>
<td class="done" style="padding-bottom:0px;padding-top:0px;"><div>Done</div></td></tr>

As everything is nicely wrapped with classnames it won't get any easier. Locate the anchor assigned with "challenge" as the class-attribute, strip off all the rest and you'll end up with exactly what you need.

Greetz BaRa

Well that's your point of view I myself look at things in an object-oriented point of view. Therefore I want my code to be reusable and extendable.
At the moment to get the data, let's say we just need to grab some anchor throw away something. But who knows when the site design is changed whether the result will be the same? If we use persistence format like plaintext or xml, there's no need to worry about this. If you read a little about the Model-View-Controller architecture, you'll see that it's better to watch the Model than the View.
And what about, say, after finishing this I want to extend it for other challenge sites (hackquest, netforce, etc.)? Surely you will want the same code to work for all of them Oh and I believe they wouldn't want their challenge pages to show up the same way as tbs. The idea of a common format will solve the problem nicely
Oops I think I'm saying too much Because atm I still need some enlightenment to create my first Firefox extension. I have read many tutorials about this but they seem to be very basic and there's still many more things needed for this specific problem. What I need for now is a complete XUL/Javascript reference (Google search returns quite a lot, but looking at them you'll see that many things are missing - Why wouldn't anyone make them as complete as the Java API reference or the Php manual? ) If you have any recommendation please let me know.

Hi quangntenemy.

Here's my opinion.

1. I myself look at things in an object-oriented point of view
I don't see how dataparsing affects your ability to implement your program in an object-oriented way. Parsing an (x)html file is just as easy as parsing an xml file. The extracted data can be stored in object instances no matter where it was extracted from.

2. Therefore I want my code to be reusable and extendable.
Reusability and extendability are very important, especially in very large softwareprojects. Why don't you whip out your GoF patterns bible while your are at it. I think you are forgetting that you are going to work on a small plugin. By use of pluggable parsing modules for every site you want to reap you can solve both issues.

3. But who knows when the site design is changed whether the result will be the same?
Design changes are done by altering style sheets and tags. I don't see how this would be any problem for a parser with variable keys.

4. If you read a little about the Model-View-Controller architecture, you'll see that it's better to watch the Model than the View.
As you probably know yourself, the MVC architecture, just as any other software architecture basically is nothing more than a set of guidelines!!!
I've participated in a few softwareprojects and one problem surfaced again and again. Very intelligent persons that know every software development book by heart but because of that were unable to see the big picture. They raise theoretical based arguments to every suggested solution. This inflexible behavior always resulted in temporarily blocking the progress of the project. Some people are just not able to let go of the theory and find the golden path in the forrest of hard defined technical rules.

5. And what about, say, after finishing this I want to extend it for other challenge sites (hackquest, netforce, etc.)?
Thanks for burning my solution with information that wasn't stated in previous messages. I appreciate that.

6. Oh and I believe they wouldn't want their challenge pages to show up the same way as tbs.
This makes no sense... 'Looking the same' is a design issue, I think they all need reference anchors to go to the challengepages.

7. The idea of a common format will solve the problem nicely
This is the first thing you said that makes sense. Indeed it will solve the problem nicely but unfortunately we don't live in a perfect world. Sometimes you got to work with what you got. If life hands you lemons, you can have a very sour drink. ...or you could whip out the tequila and salt.

To conclude. Reading your post I see someone throwing with technical terms to create the illusion of an argument. This might work for other people, but this will not work for me. An uniform data format for all challenge sites would be easier, true, but I suggested "a" solution that was feasible for the stated problem as it currently is. Too bad you didn't like it and decided to burn it to the ground. Have a nice day,
BaRa

geez, guys. If you had teamed up and used the time you spend on debating the plugin would have been finished already...

Bara is failing to see the forest for the trees: Writing a Firefox extension does nothing to speed up the s.....l.....o....w loading of the challenge list. Writing a firefox extension does not help people who don't use Firefox. Writing a Firefox extension if a big fscking kludge, unless TBS posts an API.

Quangntenemy posted a sensible suggestion that would be useful for a lot of people, then decided to use weak arguments to oppose writing a FF extension when he should have just said it would be easier, more useful, and better performing if implemented on the server side.

No offense, but sometimes very clever guys don't seem so clever.

I agree with BaRa, seems like he have worked with the same people I did.

Of course doing it on the server side is much better and is the only way to optimize the speed, but they both were talking about a client side solution.

I think quangntenemy wants to live in a non-existent perfect world and BaRa offers "a" solution, I have lived that many times, 95% of time wasted in convincing some people that perfect solutions are only doable in the theory, and 5% of time developing "a" solution.

On the other hand I don't know why people that like Object Oriented programming think that Non-object-oriented code is not reusable, for me the point of view for designing this project shouldn't be different if you are making OO-code or not.

And about FF extensions... I agree with unime. why not an IE plugin?

O boy i hope i don't get blamed for this one too.

Great! Right when I finished writing my 1000-word essay about this, my cookies expired and resulted in an access denied. After logging in and try reposting from the browser history I got a bad request, and when I tried to copy the post content from livehttpheaders to a text file my Winblowz BSODed.

A short summary:
- A pure server side approach is no better than the current challenge list because not many people remember a challenge by its index.
- A pure client side approach sure has some problem with parsing html (mostly because of the crazy combination of tags, a general solution would be huge and a compact solution would be dependent of the html page)
- A mixed solution is the best: server provides the data in a standard format (plaintext/xml) and the client helps reduce the traffic greatly by caching since the page only changes once in a while.
- Just like the others I don't live in that perfect world but I believe this approach should be very doable. And if we don't like a browser-specific solution then a Java desktop application might be better
- Forget what I said about OO. What I meant was reusablility, extendability and ease of maintenance.
- Don't blame me for burning down your solution. I appreciate it but I only adopt the good points. And if you benefit from my new proposal then there'll be no big lost

I knew you were able to give a well argumented answer. Is there any chance we will get that 1000-word essay anyway, because I would have loved to read it.
Greetz BaRa