Topic: Collaboration (questions and answers)

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

InI: You've got a good grasp of what is going on backend so its probably best, as you say, that you feed the information to the front end people (although while things are stil skeletal the distinction wouldn't need to be that strong).

Some thoughts:

I had envisioned the match table just containing something like:
match_id
player1_id
player2_id
match_type

This can then grab the players names from the user details and build the match name from that. Other tables would then bolt on like the table for storing the votes with the other return details:
match_id
return_number
vote_1
vote_2
vote_3
vote_4
vote_5
date/time
return_comment

If a scheme is used for naming the uploaded images like the match with match_id=1 would have volleys numbered 1_1.jpg, 1_2.jpg which should keep things simpler.

This may be all done or just me stating the obvious but I thought I'd throw it in.

[edit: rereading InI's post I see the bit about the array and that would clearly be better than what I said]

Emps



You're my wife now Dave

[This message has been edited by Emperor (edited 12-06-2001).]

Actually as I prefer to do that update count (as would be used in the vote) in one go I might favour the way I laid it out. As an example the vote might go through to a page with the URL:

pspong.com/vote.php?match_id=1&return_id=3&vote=3

and after a quick check to see if the call to the page came from PSPong.com or not, a quick check to see if the (I've already voted before cookie/session exists) and a quick run through is_numeric (and, of course, a connection to the DB) I'd do something like:

$current_vote = vote_ . $vote;



$sql = "UPDATE match_details

             SET $current_vote = $current_vote + 1

             WHERE match_id = '$match_id'

             AND return_id = '$return_id'";

$match_vote_result = mysql_query ($sql) 

                                     or die ("Couldn't execute the match vote increment");

As I've not tested that I suspect there are a number of things wrong with the code and suggesting code to InI is a little like trying to teach ones' grandmother to suck eggs but I thought I'd clarify my position on that. I would imagine grabbing the vote array using PHP to update it and sticking the data back again would be more time consuming than tthis method but the difference may be so small as to not be worth bothering and I'm sure InI has bigger and better ideas.

Emps


You're my wife now Dave

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

What about making some guides on how to name variables?
Example: table votes, field id should probably be votes_id (or vot_id, if we're too lazy to type the whole thing...). So we can see imediatly what comes from where.
(same with passed variables: passed_varname. This would also make us more aware not to trust these variables (not that we can trust any variable we haven't set...)

Edit: Maybe we should also keep a list of the 'handlers' somewhere, so that the clientside guys can see what the can use. (Because, after all, PHP does output just nothing when an empty variable is passed with <?= ..., doesn't it?)

What do you guys think?

Tyberius Prime

[This message has been edited by Tyberius Prime (edited 12-07-2001).]

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

InI: I think we'd all like to see what you can do server side (if that is OK with you, of course) and we others can throw ideas in as you see fit - just let us know what we can do, like work up the code for certain sections. I think the variable names/naming conventions have to be defined by the server side people or all sorts of problems could develop. As there are going to be a number of people looking through the code and pos. different people upgrading it in years to come I'd keep the names long and descriptive (as in my example above) the client side work can fit around this.

Emps

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

ok, since we haven't any one in chief of sside things yet, let's get working anyway.

Let's define what tables we're going to probably need:
then we can fill in the data structure

Players
Matches
comments (eventully seperated into 'peanut gallery posts' and 'player posts'. but that could be just a tag in the db. InI? all in one could be better for searching..., but slower otherwise.)

Did I miss one?

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

OK I feel we are going somewhere. I'm a big fan of multiple tables but whatever everyone thinks is a good idea.

I wouldn't be very enthusiastic about giving a lot of people access to the main site if I was in charge and I understand InI wanting to keep things separate from Wapod. I believe I have an unused account with Portland.co.uk and so I could dig out the details, instal PHPMyAdmin and give a number of people access their so that the initial kicking around of ideas can take place with a larger number of people.

I think we should spin of a PSPong server side thread for this and leave this thread for questions about collaborating the server and client side people.

One small rule nothing gets changed without inI's approval as I believe he has a good overview of the project.

Emps


You're my wife now Dave

OK I've spun of a new thread for discussion of purely server side matters:
www.ozoneasylum.com/Forum13/HTML/000045.html

Emps

ping 201.62.83.34

Flash Myself